DEV Community: Arthur Doss

Implementing Structured Outputs and Schema Validation for LLM APIs

Arthur Doss — Fri, 16 Oct 2026 15:58:07 +0000

Large language models can generate useful answers, extract information, and automate business workflows, but their responses are not automatically reliable application data. A model might omit required fields, return unexpected values, or produce valid JSON that violates business rules. These failures become particularly important when LLM outputs feed databases, APIs, or autonomous agents.

The solution is to combine schema-constrained generation, application-side validation, and business-rule enforcement. Structured Outputs can constrain responses to a supported JSON Schema, while validation libraries such as Pydantic verify the resulting data before downstream processing. Applications must also handle refusals, incomplete generations, and authorization failures explicitly.

This article explains how to implement this approach in Python, design a secure validation pipeline, test common failure scenarios, and prepare structured-output systems for production.

What Are Structured Outputs and Schema Validation?

Structured outputs are responses generated according to a predefined data contract. Instead of asking an LLM to return an arbitrary paragraph, an application specifies the fields, data types, and permitted values expected in the response.

For example, a support-ticket classification system might require a category, priority, summary, confidence score, and evidence list. Without structural constraints, the model could return different field names or place the classification inside explanatory text.

Schema validation checks whether the resulting data conforms to the expected structure.

Structured Outputs vs. JSON Mode

JSON mode and schema-constrained generation are not interchangeable. JSON mode targets valid JSON, whereas Structured Outputs, when supported by the selected model and schema, also enforce the specified structure. Neither approach guarantees that the content is factually correct.

Prompt-based formatting merely requests a particular response format. JSON mode targets valid JSON, while Structured Outputs constrain responses to a supported schema. Local validation independently checks data against application requirements, and business-rule validation ensures that the result is appropriate for its intended use.

For production systems, these techniques work best together. Provider-side constraints reduce structural errors, local validation provides an application boundary, and business rules ensure that valid data is appropriate for its intended use.

What Can a Schema Validate?

JSON Schema can describe required fields, types, enumerated values, nested objects, arrays, and certain value constraints.

For instance, a priority field can accept only low, medium, or high. A confidence field can be restricted to a numeric range, and an evidence field can require an array of strings.

However, structural constraints have limits. A schema can verify that an evidence field contains strings, but it cannot establish that those strings genuinely appear in the source document. That requires additional application logic or evaluation.

Designing a Reliable Structured-Output Architecture

A production implementation should treat the model response as untrusted until it passes the application's acceptance process.

A typical pipeline includes six stages:

Input preparation: Validate incoming requests and establish the trusted context.
Constrained generation: Call a supported LLM endpoint with the expected output schema.

Response inspection: Check completion status, refusals, and API errors.
Local validation: Parse the response into a typed application object.
Business validation: Apply domain rules, permissions, and approval requirements.

Downstream processing: Persist, display, or route only accepted data.
Each stage serves a different purpose. An API timeout is not a schema violation, a refusal is not malformed JSON, and a structurally valid response is not necessarily an authorized action.

Keeping these failure categories separate improves debugging and makes recovery policies easier to implement.

Implementing Structured Outputs with Python

The following example uses the OpenAI Python SDK with Pydantic to classify customer-support tickets. It demonstrates the documented chat.completions.parse() pattern. The selected model and SDK version should be checked against current provider documentation before deployment.

Step 1: Define the Output Schema

First, install the required packages:

python -m pip install openai pydantic

For production deployments, pin compatible dependency versions and configure the API key through an environment variable or secrets manager.

Define the expected output using a Pydantic model:

from typing import Literal
from pydantic import BaseModel, Field, field_validator


class TicketTriage(BaseModel):
    category: Literal[
        "billing", "technical", "account", "other"
    ]
    priority: Literal["low", "medium", "high"]
    summary: str
    confidence: float = Field(ge=0.0, le=1.0)
    evidence: list[str]
    needs_human_review: bool

    @field_validator("summary")
    @classmethod
    def validate_summary(cls, value: str) -> str:
        if not value.strip():
            raise ValueError("Summary cannot be empty")
        return value.strip()

    @field_validator("evidence")
    @classmethod
    def validate_evidence(
        cls, values: list[str]
    ) -> list[str]:
        if any(not item.strip() for item in values):
            raise ValueError("Evidence cannot contain blank items")
        return values

The model defines the expected fields and restricts categories and priorities to explicit values. Pydantic's field constraints enforce the confidence range, while custom validators reject blank summaries and evidence items.

Step 2: Request a Schema-Constrained Response

The OpenAI Python SDK can derive a compatible response schema from a Pydantic model and parse the response into a typed object.

from openai import OpenAI

client = OpenAI()


def classify_ticket(ticket_text: str) -> TicketTriage:
    if not ticket_text.strip():
        raise ValueError("Ticket text cannot be empty")

    completion = client.chat.completions.parse(
        model="gpt-4o-2024-08-06",
        messages=[
            {
                "role": "system",
                "content": (
                    "Classify the support ticket using the "
                    "provided response schema. Do not invent "
                    "evidence. Flag ambiguous cases for review."
                ),
            },
            {
                "role": "user",
                "content": ticket_text,
            },
        ],
        response_format=TicketTriage,
    )

    message = completion.choices[0].message

    if message.refusal:
        raise RuntimeError("The model refused the request")

    if message.parsed is None:
        raise RuntimeError("No parsed result was returned")

    return message.parsed

The model identifier is an illustrative documented example, not a claim that it is the newest or best model available. Confirm current model availability, endpoint compatibility, and supported schema features before using it.

Step 3: Enforce Business Rules

Schema validation establishes structural correctness, but business logic requires separate checks.

Suppose high-priority tickets must always receive human review. Enforce that requirement in application code:

def validate_triage(result: TicketTriage) -> TicketTriage:
    if (
        result.priority == "high"
        and not result.needs_human_review
    ):
        raise ValueError(
            "High-priority tickets require human review"
        )

    return result

The complete workflow becomes: 

ticket = (
    "I was charged twice for the same order. "
    "Please investigate the duplicate payment."
)

result = validate_triage(classify_ticket(ticket))

print(result.model_dump())

The business rule remains enforceable even if the model ignores its instructions. In a real support system, the application could route a failed result to a review queue instead of terminating the workflow.

The broader principle is simple: prompts guide model behavior; application code enforces critical requirements.

Validating JSON from External Sources

Not every application uses a provider-specific parsing helper. Some systems receive JSON from another LLM provider, a stored record, or an internal service. In these cases, local validation provides a consistent enforcement layer.

Pydantic supports validating JSON directly against a model:

from pydantic import ValidationError


def parse_untrusted_json(raw_json: str) -> TicketTriage:
    try:
        result = TicketTriage.model_validate_json(raw_json)
    except ValidationError as exc:
        raise ValueError(
            "The supplied JSON failed validation"
        ) from exc

    return validate_triage(result)

The function rejects data that cannot be parsed or does not satisfy the model's validation rules. It then applies the same business validation used by the main workflow.

Handling Validation Failures in Production

Even with schema-constrained generation, an application must account for unsuccessful requests, refusals, incomplete responses, and business-rule violations.

Which Failures Should the Application Handle?

Different failure types require different recovery strategies.

Network timeouts: Retry within a bounded policy when appropriate.
Rate limits: Apply backoff, jitter, and concurrency controls.
Model refusals: Follow a dedicated refusal-handling path.
Incomplete responses: Reject the result and retry if recoverable.
Schema validation failures: Record the failure and reject or regenerate selectively.
Business-rule violations: Apply a safe fallback or request human review.
Authorization failures: Deny the requested action.

The application should not collapse every failure into a generic parsing exception. Doing so makes it harder to identify whether the problem originated in the network, model behavior, schema design, or application policy.

Should Invalid Outputs Be Retried Automatically?

Retries are useful for transient failures, but not every invalid result warrants another model call.

A sensible recovery strategy should classify the error, limit retry attempts, and avoid repeating requests that failed because of permanent configuration problems. Repeatedly asking the model to fix an ambiguous business decision may increase latency and cost without resolving the underlying issue.

If the application retries a request that can trigger an external action, it must also consider idempotency. A repeated model call is not necessarily safe if the workflow can issue duplicate payments, create duplicate records, or send repeated notifications.

Why Blind JSON Repair Is Risky?

Some implementations attempt to repair malformed JSON automatically. This can be useful in legacy systems that rely on unconstrained text generation, but it introduces another transformation that must be verified.

A repair process might remove an unexpected field, alter a value, or conceal missing information. If repair is necessary, validate the resulting object against the full schema and business rules again. Never assume that repaired JSON is trustworthy simply because it can now be parsed.

Securing Structured Outputs in Enterprise AI Systems

Structured outputs improve interface reliability, but they do not automatically make generated content safe.

Can Valid JSON Still Trigger an Unsafe Action?

Consider an AI agent that produces a valid object containing a customer identifier, refund amount, and approval flag. The object may conform perfectly to its schema while still proposing an unauthorized refund.

The application must independently verify identity, permissions, transaction limits, and approval status. A model-generated field such as "approved": true must never substitute for an authoritative authorization decision.

This separation is particularly important when structured outputs are used for tool calling, enterprise workflows, and autonomous agents.

Defend Against Prompt Injection

RAG applications and enterprise agents frequently process documents, emails, and retrieved content that should be treated as untrusted input.
A schema constrains the output's structure; it does not guarantee that the model followed the intended instructions or interpreted the source correctly.

Recommended controls include:

Treat retrieved documents and user-provided text as untrusted data.
Validate identifiers and resource access against authoritative systems.
Restrict available tools and operations through explicit allowlists.
Keep credentials and authorization decisions outside model-controlled content.
Require human approval for sensitive or irreversible actions.
Test prompt-injection attempts as part of security evaluations.

These controls help maintain a secure boundary between generated data and actions performed by trusted application services.

Performance, Monitoring, and Scalability

Structured-output processing introduces additional considerations, but its performance impact depends on the model, schema complexity, response length, network conditions, and application implementation. Measure these factors under representative workloads rather than relying on assumptions.

Keep Schemas Manageable

Large, deeply nested schemas can make contracts more difficult to maintain and may encounter provider-specific limitations.

To improve maintainability:

Use descriptive property names and document their meaning.
Include only fields needed by downstream consumers.
Keep schemas focused on a single, well-defined task.
Verify provider support for every schema feature.
Version contracts and test changes against existing consumers.

Monitor the Complete Request Lifecycle

Production monitoring should include:

End-to-end latency and token usage.
Provider errors, timeouts, and rate-limit responses.
Refusal and incomplete-response rates.
Local validation failures and business-rule violations.
Retry frequency and downstream rejection rates.
Human-review frequency and task-level accuracy.

Use consistent denominators when calculating rates. For example, provider failures and local validation failures should be tracked separately because they indicate different problems.

Also evaluate semantic quality. A response can satisfy every schema constraint while assigning the wrong category or inventing evidence. Structural compliance is not a substitute for measuring task accuracy.

Version Schemas Safely

A practical release process should store schemas with application code, identify their versions, test compatibility, and run regression evaluations before deployment. Introduce breaking changes deliberately, monitor the results, and maintain a rollback strategy.

Systems that use multiple models or providers should test each supported configuration independently. Identical schema definitions do not guarantee identical generation behavior across implementations.

Testing Structured Outputs Before Deployment

A successful example is not enough to establish production readiness. Tests should cover normal requests, boundary conditions, ambiguous inputs, and failure paths.

A practical test suite should include:

Valid responses: Confirm expected fields and values are accepted.
Boundary values: Test empty strings, numeric limits, empty arrays, and unexpected enum values.
Business-rule failures: Verify that structurally valid but unacceptable results are rejected.
Provider failures: Test timeouts, rate limits, refusals, and incomplete responses.
Security cases: Test prompt injection, unauthorized resource identifiers, and unsafe tool arguments.
Regression cases: Re-run representative examples after changing the model, prompt, schema, or SDK version.

Conclusion

Structured outputs and schema validation make LLM integrations more predictable by combining constrained generation, typed parsing, and business-rule enforcement. Reliable implementations also require explicit failure handling, security controls, monitoring, and regression testing. Before deployment, verify provider compatibility, test edge cases, and ensure that no unvalidated or unauthorized model output reaches consequential downstream operations.

FAQs

Are structured outputs enough to guarantee valid LLM responses?

They constrain response structure for supported models and schemas, but applications must still handle refusals, incomplete generations, business-rule violations, and incorrect information.

What is the difference between JSON Schema and Pydantic?

JSON Schema describes constraints on JSON data. Pydantic provides Python models for parsing, validation, and typed application objects, and can generate JSON Schema for compatible integrations.

Should schema validation happen inside or outside the LLM API?

Use provider-side constraints when available, then validate locally before consuming the response. Local validation provides an additional enforcement boundary for application-specific requirements.

How should applications handle schema validation failures?

Classify the failure, record safe diagnostic information, and retry only when appropriate. Reject invalid data or route unresolved cases to human review rather than passing them downstream unchecked.

Can structured outputs be used with AI agents and RAG systems?

Yes. They support structured extraction, classification, routing, and tool arguments. However, retrieved content remains untrusted, and every consequential tool action requires independent authorization.

Implementing Human Approval Gates in an LLM Tool-Calling Workflow

Arthur Doss — Thu, 15 Oct 2026 16:17:32 +0000

LLM agents can select tools, generate arguments, and initiate workflows, but a valid tool call does not guarantee that an action is safe or authorized. Human approval gates solve this problem by introducing a controlled checkpoint between an agent's decision and the execution of a consequential operation. The application evaluates the proposed action, pauses when approval is required, presents the exact action to an authorized reviewer, and executes it only after verifying the decision.

The key is to implement approval as an application-level security control rather than a prompt instruction or confirmation button. A reliable design must preserve pending state, bind approval to the intended action, enforce authorization at execution time, and prevent duplicate side effects. This approach allows AI agents to automate routine work while maintaining human oversight of sensitive operations.

What Is a Human Approval Gate in an LLM Tool?

A human approval gate is a mechanism that pauses an AI agent's tool execution until an authorized person reviews and approves a proposed action.

Consider an enterprise AI assistant that can retrieve customer information, draft emails, issue refunds, and delete records. The application might allow authorized read operations automatically, while requiring approval before sending external communications, processing large refunds, or deleting production data.

The distinction is important: an LLM can propose an action, but the application must control whether that action can execute.

Three separate controls make this possible:

Input validation: Determines whether tool arguments are correctly structured and satisfy business rules.
Human approval: Establishes whether a designated reviewer has accepted the specific proposed action.
Authorization: Determines whether the requesting identity or service is permitted to operate on the target resource.

These controls work together. A valid request may still violate access policies, and an approved request may become invalid if its arguments or the underlying resource change before execution.

Which LLM tool calls need human approval?

Not every tool call needs manual review. Requiring approval for every operation introduces unnecessary delays and can make agent workflows difficult to use.

A better approach is to classify tools by risk and define deterministic approval policies.

Search internal documentation: Allow automatic execution when access controls permit it.

Retrieve customer information: Enforce authorization and data-access restrictions.
Draft an email: Usually allow automatic execution because drafting does not send the message.
Send an external email: Require approval when disclosure or business risks warrant it.
Issue a refund: Apply threshold-based or mandatory approval.
Delete production records: Require approval and potentially dual authorization.

Deploy a production change: Combine approval with automated release checks.

These are example policies, not universal requirements. Organizations should determine approval thresholds based on their risk tolerance, regulatory obligations, data sensitivity, and operational procedures.

Why LLM Agents Need an Explicit Approval Layer?

Traditional applications usually execute predefined business logic. LLM agents introduce another decision-making component: the model determines which tool to call and generates its arguments based on conversational context, retrieved information, and instructions.

This flexibility creates several risks.
Incorrect tool selection: A model may select a destructive operation when a read-only operation would have been sufficient.

Invalid or unintended arguments: A tool call may contain the wrong customer ID, recipient, amount, or resource identifier.

Prompt injection: Instructions embedded in documents, emails, or web pages may influence the model to propose unauthorized actions.
Excessive permissions: An agent with broad access may perform operations beyond what the user's original request requires.
Unintended side effects: Once an external system processes a request, reversing it may be difficult or impossible.

Approval gates introduce a checkpoint where the application can enforce policy and a human can inspect the proposed action before it takes effect.
OWASP's guidance on excessive agency recommends limiting tool capabilities and permissions, applying least privilege, and requiring human approval for high-impact actions. Approval should complement these controls rather than replace them.

Designing the Architecture for Human Approval

A reliable approval system separates the model's decision-making process from the application's authority to execute tools. The LLM proposes an operation, a policy engine determines whether approval is necessary, and a trusted backend enforces the final decision.

Here’s a reference architecture:

User request and LLM agent
Tool validation and policy engine
Authorized human reviewer
Downstream service and audit log

Each component has a distinct responsibility:

LLM agent: Proposes an action based on the user's request and available context.
Policy engine: Applies deterministic rules to identify operations requiring approval.
Approval service: Stores pending requests, validates reviewer decisions, and tracks status transitions.
Execution layer: Enforces authorization and performs the approved operation.
Audit system: Records decisions and execution outcomes for troubleshooting and compliance.

The approval service should remain independent of the model's generated explanation. A model-generated statement such as “The user has authorized this transaction” must never be treated as proof of authorization.

How to Implement Human Approval Gates With Python?

There are two practical implementation approaches: use a framework's built-in human-in-the-loop functionality or implement an approval service that sits between the agent and sensitive tools.

Framework middleware is useful for orchestrating interruptions and resumptions. A separate backend approval service provides greater control when multiple agents, applications, or business systems must follow the same policies.

Use LangChain and LangGraph middleware

LangChain provides HumanInTheLoopMiddleware for configuring which tool calls require human intervention. LangGraph provides checkpointing and interrupt/resume capabilities to preserve workflow state while waiting for a decision.

The following example illustrates the framework integration pattern.
Install the relevant packages in a Python environment and pin the versions validated by your project:

pip install langchain langgraph langchain-openai
from langchain.tools import tool


@tool
def read_customer(customer_id: str) -> str:
    """Retrieve a customer record."""
    # Replace with an authorized read-only repository call.
    return f"Customer lookup requested: {customer_id}"


@tool
def delete_customer(customer_id: str) -> str:
    """Delete a customer record."""
    # Replace with a real, access-controlled deletion service.
    return f"Deletion requested for customer {customer_id}"

These functions are illustrative placeholders. The deletion function must not be connected to a real data store until its authorization, approval, and audit requirements have been implemented.

Configure the agent to interrupt before executing the destructive tool:

from langchain.agents import create_agent
from langchain.agents.middleware import HumanInTheLoopMiddleware
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model="openai:gpt-5.5",
    tools=[read_customer, delete_customer],
    middleware=[
        HumanInTheLoopMiddleware(
            interrupt_on={
                "read_customer": False,
                "delete_customer": {
                    "allowed_decisions": ["approve", "reject"],
                },
            },
            description_prefix="Action requires review",
        ),
    ],
    checkpointer=InMemorySaver(),
)

This configuration demonstrates three important design choices.
First, read-only customer lookups are not interrupted by this middleware. They must still enforce ordinary data-access permissions.

Second, deletion requests require explicit approval or rejection. The policy does not permit reviewers to edit the tool arguments during the approval step.

Third, InMemorySaver is appropriate for demonstrating a workflow locally, but it is not a durable production persistence layer.

The model identifier, imports, and middleware signatures are version-sensitive. Confirm that the selected model integration and framework versions support this configuration before running the example.

Invoke the agent and capture the pending approval

A workflow needs a stable identifier so that its interrupted execution can be resumed later.

from uuid import uuid4

thread_id = str(uuid4())
config = {
    "configurable": {
        "thread_id": thread_id
    }
}

result = agent.invoke(
    {
        "messages": [
            {
                "role": "user",
                "content": "Delete customer C-1042",
            }
        ]
    },
    config=config,
    version="v2",
)

if result.interrupts:
    for interrupt in result.interrupts:
        print(interrupt.value)

The interrupt contains information about the proposed operation. The application can use this information to create an approval screen that identifies the tool, target, arguments, and expected impact.

A useful approval screen should answer:

What action will be performed?
Which resource will be affected?
Who initiated the request?
Why is the action being requested?
What are the consequences?
Which identity is approving it?

For a deletion operation, showing the customer identifier alone may be insufficient. A reviewer may also need the record's display name, the scope of deletion, and whether related records will be affected.

Store an explicit approval record

A server-side approval record should contain enough information to establish what was approved and whether it can still be executed.

approval_id: Unique identifier for the approval request.
tenant_id: Prevents cross-tenant access.
requester_id: Identifies the initiating user.
tool_name: Identifies the proposed operation.
target_id: Identifies the affected resource.
arguments_hash: Binds the decision to the normalized arguments.
policy_version: Records the policy applied to the request.
reviewer_id: Identifies the person who made the decision.
status: Tracks pending, approved, rejected, expired, or executing states.
expires_at: Defines when the approval becomes invalid.
execution_id: Supports duplicate-execution prevention and reconciliation.

Compute the argument hash on the server from a canonical representation of the action and its security-relevant parameters. Include the tool name and target, not just the visible user input.

A hash alone is not an authorization mechanism. The backend must also validate the approval record, the reviewer's identity, the current permissions, and the action's integrity.

Security Risks and How to Mitigate Them

An approval gate is only as trustworthy as the system that creates, displays, and enforces the approval.

Prompt injection and misleading approval screens

Prompt injection can occur when an agent processes untrusted content that contains instructions intended to manipulate its behavior. An attacker might place instructions in an email or document that encourage the model to send confidential data or delete records.

The application should never treat a model-generated explanation as authoritative evidence that an action is safe.

Instead, construct the approval screen from validated action data and trusted application metadata. Clearly distinguish untrusted document content from system-generated information.

For example, before approving an email, a reviewer should be able to inspect the actual recipient, subject, message body, and attachments. A summary such as “Send the requested report to the team” does not provide enough information to detect an external recipient or an unintended attachment.

How to Choose the Right Implementation Approach?

The appropriate architecture depends on the number of agents involved, the sensitivity of their tools, and the durability requirements of the workflow.

Custom application middleware

Custom middleware works well when an existing application has a small number of sensitive operations and needs precise control over validation, approval, and execution. The trade-off is that the engineering team must implement persistence, workflow recovery, authorization, and concurrency handling.

LangChain and LangGraph

These frameworks are useful when the agent is already built with LangChain and LangGraph. LangGraph provides interrupt-and-resume workflows backed by checkpointing, while LangChain provides middleware for human review of tool calls.

The framework orchestrates the workflow, but the application remains responsible for reviewer authentication, business permissions, and downstream execution controls.

Pydantic AI deferred tools

Pydantic AI supports tools that always require approval through requires_approval=True and conditional approval through ApprovalRequired. This can be useful for Python applications with typed tool interfaces.
As with other frameworks, the application must establish a trusted reviewer workflow and enforce the final authorization decision.

A shared enterprise approval service

For multiple agents and applications, a centralized approval service can provide consistent reviewer roles, policy thresholds, expiration rules, and audit records.

This approach adds a service boundary and operational complexity, but it can prevent each agent team from implementing sensitive-action controls differently.

Testing Human Approval Gates Before Production

Approval logic should be tested as a security mechanism, not merely as a conversational feature. Showing an approval dialog does not prove that an unauthorized operation cannot execute.

Build a reproducible test suite. You should test the following scenarios:

A permitted read-only tool executes subject to access controls.
A protected tool pauses without producing a side effect.
An authorized reviewer can approve the exact pending action.
An unauthorized reviewer cannot approve the request.
A rejected request produces no protected side effect.
Changed arguments invalidate approval or trigger a new review.
Expired approvals cannot execute.
Concurrent workers cannot execute the same approval twice.
Fabricated approval identifiers are rejected.
Pending requests survive process restarts.
Timed-out downstream operations are reconciled before retrying.
Prompt injection cannot bypass application-level controls.

Test the actual downstream side effect. For example, verify that a database record remains unchanged before approval instead of checking only that the agent returned an interrupt.

Conclusion

Human approval gates make LLM tool execution safer by separating model decisions from consequential actions. Use risk-based approval policies, enforce authorization on the backend, bind approvals to exact tool arguments, and persist workflow state. Before production, test rejection, expiration, retries, and prompt injection. Treat approval as a security control, not a UI feature.

FAQs

Should every LLM tool call require human approval?

No. Read-only operations can run automatically when authorized. Destructive, financial, externally visible, or privileged operations may require approval based on deterministic risk policies.

Can an LLM approve its own tool call?

No. The model can propose an action and explain its reasoning, but approval must come from an authorized human or a separately defined, trusted policy mechanism.

How can developers prevent approved tool calls from being modified?

Bind the approval to the exact action and its security-relevant arguments. Revalidate them before execution and require a new review when material changes occur.

How should approval gates handle long-running workflows?

Persist the pending request and execution state, release the original HTTP request, and resume the workflow after an authenticated reviewer responds. Use durable storage rather than process-local state.

Does human approval prevent prompt injection?

No. Prompt injection can influence proposed actions and manipulate review screens. Combine approval with least-privilege tools, trusted action summaries, downstream authorization, and adversarial testing.