TL;DR
AI agent guardrails are checks that run on each action an agent takes, just before it executes, in code the model cannot override. Five actions need them most: payments, outbound email, code execution, database writes, and ticket or CRM updates. Each action gets a written spec with a check, a fail mode, an approval rule and a log field. Money and data writes fail closed, while outbound email falls back to a saved draft. Any human approval is tied to the exact payload, so a changed amount or recipient needs a fresh sign-off. LangGraph, Copilot Studio and Amazon Bedrock all offer places to run these checks, but their defaults differ, so set them yourself.
Key Takeaways Guard the action, not the prompt, because the check has to run in the tool backend right before execution. Every action spec has five fields, namely the action, its check, its fail mode, its approval rule and its log field. Payments and database writes fail closed, outbound email falls back to a draft, and code runs are killed and quarantined. An approval belongs to one exact payload, so a changed amount, recipient or row set needs a new approval. Platform defaults differ, and Copilot Studio’s external threat detection lets a tool run after one second without a decision unless an admin changes it. Release each action on its own, moving from read-only to approval-gated to autonomous within limits. Watch on YouTube
Why AI Agents Fail in Production
Kanerika’s short take on why AI agents fail in production, the risk every action spec below is written to stop.
An Agent Guardrail Works Like the Pharmacist at the Counter
A doctor writes the prescription, but the pharmacist decides whether it leaves the counter. Before handing anything over, the pharmacist checks the patient, the dose and any drug interactions. If something looks wrong, the bottle stays on the shelf and the pharmacist calls the doctor.
An agent guardrail plays the pharmacist. The model proposes an action, such as paying an invoice, and a separate check inspects that exact request before it runs. So the model can reason freely, yet nothing reaches a bank, an inbox or a database without passing the counter.
Each medicine also needs its own rules. Likewise, a refund, a code run and a CRM status change carry different risks, and each one deserves its own written spec.
Where AI Agent Guardrails Belong: At the Action, Not the Prompt
Agent incidents rarely start inside the chat window. They start when a tool call moves money, sends a message or changes a record. The AI guardrails guide covers guardrail types and general methods, so this post stays on the actions themselves.
OWASP’s entry on Excessive Agency (LLM06:2025) names three root causes. They are too much functionality, too many permissions and too much autonomy. Its fixes include user approval for high-impact actions and complete mediation, which means downstream systems decide what is allowed instead of the model.
The Five-Field Action Spec
Every guarded action needs a written spec before it gets write access. The spec has five fields, and each one answers a question an auditor or an on-call engineer will eventually ask.
Action. The single tool call being guarded, for example issue_vendor_payment.Check. The deterministic tests the request must pass, run outside the model.Fail mode. What happens when a check fails or the checker itself is down.Approval rule. When a person must sign off, and what exactly that sign-off covers.Log field. The record that lets you prove later what ran, under which policy, and who approved it.Written down, a spec is short. The example below is illustrative, so treat the limits as placeholders and keep the shape.
action: issue_vendor_payment
check: [payee_verified, bank_details_unchanged_30d,
amount_under_cap, invoice_matched, idempotency_key_present]
fail_mode: closed # also on checker error or timeout
approval: required if new_payee or amount > 5000
bound_to: sha256(payee, account, amount, currency, invoice_ref)
expires_after: 1h
log: [request_id, policy_version, args_hash, approval_ref, payment_id]Nothing in the spec asks the model to behave. Every line is a test that code runs, which is the whole point.
Enforce in the Tool Backend, Not the System Prompt
A system prompt can ask the model to behave, but it cannot stop a tool call. The check has to sit somewhere the model cannot talk its way past, and there are three such places.
Pre-call policy. A gateway or interceptor sees every tool call and allows or denies it.In-tool validation. The tool function itself rejects bad arguments before doing any work.Backend authorization. The system of record enforces permissions, row scope and limits on its own.Use at least two of the three for anything that writes. Because injected text can steer a model, as the agentic AI security guide explains, the last line of defence should never depend on it. In addition, scoped credentials from AI agent authentication limit what a hijacked agent could reach anyway.
AI Agent Guardrails by Action Type: The Spec Sheet
The table condenses the five specs into one view. Treat each row as a starting point that your risk owners then tune for their own systems.
Action Guardrail check Fail mode Approval rule Log field OWASP agentic risk Payments Verified payee, unchanged bank details, per-transaction and daily caps, invoice match, idempotency key Closed; reconcile, never resend blind New payee, changed bank details or amount over threshold; bound to the payload hash Payment ID, idempotency key, approval reference ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse Outbound email Recipient domain allowlist, recipient cap, attachment rules, PII scan of the final body Save as draft External or bulk sends; bound to exact recipients and content Message ID, recipient hash, DLP verdict ASI02, ASI03 Code execution Approved image, no network, read-only root, CPU, memory and time limits, no production secrets Kill the run, quarantine output Network egress to an allowlist for one run only Image digest, exit code, artifact hashes ASI05 Unexpected Code Execution Database writes Typed write API, writable-field allowlist, tenant scope, row cap, dry-run diff Roll back the transaction Bulk or destructive changes; never overrides tenant scope Statement ID, rows affected, diff reference ASI02, ASI03 Ticket and CRM updates Allowed fields and transitions, ownership limits, bulk cap, side-effect check, row version Reject and re-read the record Closure, reassignment or any change that notifies a customer Record ID, old and new values, triggered workflows ASI02, ASI03
Read the Fail-Mode Column First
The fail-mode column decides what happens on a bad day, when a checker times out. The risk names come from the OWASP Top 10 for Agentic Applications , published on 9 December 2025.
Approval queues carry a risk of their own: at fifty requests an hour, reviewers start clicking approve. OWASP’s ASI09 Human-Agent Trust Exploitation describes the same weak spot, where confident, polished explanations lead people to approve harmful actions. For that reason, keep approvals for the rows that truly need them, and the human-in-the-loop guide for AI agents covers how to design those queues.
Checklist
Enterprise Agentic AI Checklist
A practical checklist for taking AI agents to production, from use-case fit and data readiness to governance, approvals and monitoring.
Get the Checklist → Payment Guardrails: Payee, Amount, Duplicates and Approval
Payments are where AI agent guardrails earn their keep, because a failure costs real money the same afternoon. The FBI’s 2025 Internet Crime Report put business email compromise losses at $3,046,598,558. That figure covers human fraud rather than agents, yet it shows why a changed payee is the first thing to check.
AI Agent Guardrail Checks Before Payment Release
Run every check in the payment service, after the agent proposes the transfer and before anything reaches the bank rail.
Payee verified on the vendor master, with no recent change to its bank details. Amount under the per-transaction cap and under the agent’s daily total. Currency on an allowlist. A matching approved invoice or purchase order. An idempotency key on the request. Payment APIs such as Stripe show why the last check matters. Stripe saves the result of the first request sent with a given Idempotency-Key. A retry with that key then returns the saved response instead of charging twice.
Reusing a key with different parameters returns an error, which is exactly what you want when an agent rewrites the amount.
One more check catches hallucinated identifiers. OWASP’s LLM09 entry describes hallucination as output that seems accurate but is fabricated, and an invented invoice number looks just as real. The payment service looks up each invoice number and vendor ID the model names and rejects the call if one does not exist.
Fail Mode: Closed, and Never Retry Blind
A payment guardrail fails closed. If the payee lookup times out or the policy service is down, nothing is sent, and the request goes to a person.
Timeouts need extra care. When the bank call returns no clear answer, the payment may or may not have gone through. So the agent must not send a fresh request, and instead it checks the status with the same idempotency key.
Approval Rule Bound to the Payload
Require approval for a new beneficiary, changed bank details or any amount above your threshold. Then bind that approval to a hash of the exact payload, covering payee, account, amount, currency and invoice reference.
If the agent edits any of those fields after sign-off, the hash no longer matches and the approval is void. Also give approvals a short expiry, since a sign-off from last week should not release a payment today.
Enforcing Payment Approval with an AgentCore Temporal Policy
AWS documents this pattern for temporal policies in Amazon Bedrock AgentCore , enforced at the AgentCore Gateway outside the agent’s code. Its own example allows a disburse_payment call only after an approve_claim response for the same claimId. That response must show approved set to true and fall within the previous hour.
One operational catch applies, though. Adding or updating a temporal policy invalidates open sessions, so the next request in each of them gets an HTTP 409 conflict. Ship policy changes outside peak hours.
Outbound Email Guardrails: Recipients and Content at Send Time
Outbound email looks harmless until an agent sends a customer list to the wrong domain. So run the checks on the final rendered message, after every template and attachment is in place, because that is what actually leaves.
Checks on the Final Message
Recipient domains are on an allowlist, and any external recipient is flagged. Each message and each hour has a cap on recipients. The agent has not added a hidden BCC. Attachment types and sizes are on an allowlist. A PII and data loss prevention scan covers the body and every attachment. In practice, two kinds of check sit in that list. Recipient rules are deterministic, so they simply pass or fail. A PII scan, by contrast, is probabilistic, and it works best as a second layer.
For that second layer, Amazon Bedrock Guardrails can scan text through its standalone ApplyGuardrail API, including sensitive information filters for PII. Treat it as a content check, though, because it judges text and not whether this agent may email this customer. Microsoft shops can run the same scan with Purview data loss prevention .
Fail Mode: Save as Draft
Email is the one action where failing fully closed wastes too much work. Reject anything clearly prohibited, such as a blocked domain, and save everything else that fails a check as a draft for review.
This also matters for injection. A RAG security gap can carry hostile text from a retrieved document into an email body. The draft fallback keeps that text away from customers.
Approval Rule
Approval covers the exact combination of recipients and content. If the agent adds a recipient or edits a paragraph after sign-off, approval opens again.
Picture an approved renewal reminder for one client. Then the agent, asked to loop in finance, adds an outside address just before sending. The recipient check catches the new domain, the payload hash no longer matches, and the message drops back to draft.
In Copilot Studio, connector rules come from data policies in the Power Platform admin center. There, admins classify connectors as Business, Non-business or Blocked. They can also allow or deny specific endpoints for HTTP requests.
Code Execution Guardrails: Sandbox, Network and Output
Code execution gives an agent the widest reach of the five actions. A generated script can read files, call networks and burn compute, so the runtime should assume the code is hostile.
Runtime Config
Start from an approved base image and run as a non-root user. Then strip everything the task does not need, as in this illustrative command built from documented docker run flags .
docker run --rm \
--network none \
--read-only \
--cap-drop ALL \
--memory 512m --cpus 1 \
--user 10001:10001 \
--tmpfs /scratch:size=64m \
approved-python-runner@sha256:<digest> \
timeout 60 python /job/task.pyWith –network none , the container gets only a loopback interface. No production credentials go into its environment, and the scratch space stays small and temporary.
What to Check Before and After a Run
Before the run, check the requested packages and file paths against an allowlist. After the run, inspect the artifacts before anything downstream uses them, because a script can respect every limit and still write a harmful file.
Fail Mode and Approval
On any limit breach, kill the run first and then quarantine its output. An approval can open network egress to a named allowlist for one run, but it never removes the baseline isolation.
Be honest about the limits here. A container is not a complete boundary for untrusted code, so a microVM or a gVisor-style sandbox gives stronger isolation. Neither option stops logic that is allowed but wrong, which is why output checks still matter.
OWASP files this risk under ASI05 Unexpected Code Execution. It is also where AI supply chain security begins, since a generated script can pull an unvetted package at run time.
Database Write Guardrails: Scope, Row Limits and Rollback
Database writes fail quietly, and that makes them dangerous. A wrong UPDATE crashes nothing, so it can sit unnoticed for days.
Typed Write APIs Instead of Raw SQL
Never hand an agent raw SQL credentials for production. Instead, give it a governed write service with typed endpoints or stored procedures and an allowlist of writable fields.
If you must allow SQL, gate it. For example, LangChain’s human-in-the-loop documentation shows a when predicate that pauses any query that is not a read-only SELECT.
def is_write_query(request: ToolCallRequest) -> bool:
query = request.tool_call["args"].get("query", "")
return not query.lstrip().upper().startswith("SELECT")
HumanInTheLoopMiddleware(
interrupt_on={
"execute_sql": {
"allowed_decisions": ["approve", "reject"],
"when": is_write_query,
},
},
)Checks Inside the Transaction
Tenant scope belongs in the database itself. With PostgreSQL row-level security , enabling RLS without any policy denies every row by default. However, table owners usually bypass RLS unless you set FORCE ROW LEVEL SECURITY, so the agent’s role should never own the table.
Next, add a cap on affected rows, a dry-run diff for larger changes and a version check against concurrent edits. If any check fails, roll back the whole transaction. TRUNCATE also ignores row security, so keep it off the agent’s grants entirely.
Fail Mode and Approval: AI Agent Guardrails for Database Writes
Database writes fail closed. Bulk or destructive changes need approval of the specific diff, and no approval can widen tenant scope. For the people and services around the same data, zero-trust data security applies the same least-privilege idea.
Ticket and CRM Update Guardrails: Fields, Transitions and Side Effects
CRM and ticket updates look low-risk because they only change a few fields. Yet one status change can email a customer or start a billing run.
Permitted Mutations
Write the permitted changes as data rather than prose. List the allowed fields, the allowed transitions and the ownership limits, plus a cap on records per request.
tool: update_opportunity
allowed_fields: [next_step, notes, stage]
allowed_transitions:
stage:
"New": ["In progress"]
"In progress": ["Qualified"]
# Closed Won and Closed Lost need a person
reassign_owner: false
max_records_per_call: 5Hidden Side Effects
Before approving a change, list what it will trigger. Workflows, customer notifications, billing rules and SLA timers often hang off one status field, and the agent cannot see them through the API. So the guardrail should resolve those triggers first and include them in the decision.
Stale Records and Approval
Agents often read a record, reason for a while, then write, and a person may have changed it in the meantime. Microsoft Dataverse handles this with optimistic concurrency , where setting ConcurrencyBehavior to IfRowVersionMatches makes the update fail if the row changed after the read.
On a conflict, the agent re-reads and proposes again rather than overwriting. Approval for closures or reassignments covers the final change set, and every agent edit leaves an audit note. The customer service automation guide shows where most of these updates start.
AI Assessment
Find Out Which Agent Actions Are Ready for Write Access
Score your organization’s AI maturity across data, governance and security to see where agents can act on their own and where approval steps still belong.
Start Your AI Assessment → Configuring the Same Guardrail in LangGraph, Copilot Studio and Bedrock
Every major platform gives you a place to attach AI agent guardrails to a tool call, but the defaults differ in ways that matter. The specs above stay the same, while the wiring changes. For the products that enforce these checks across platforms, see the AI agent security tools roundup.
LangGraph and LangChain: Interrupts and the Human-in-the-Loop Middleware
In LangGraph, calling interrupt() inside a node pauses the graph and saves its state through a checkpointer. A thread_id points back to that saved state. After that, Command(resume=…) continues the run with the reviewer’s answer.
LangChain’s HumanInTheLoopMiddleware wraps this for tool calls. Its interrupt_on setting maps each tool to an approval rule, and allowed_decisions limits reviewers to approve, edit, reject or respond. Finally, a when predicate gates approval on the tool’s arguments.
The catch: on resume the when predicate runs again, and a False result runs the tool and ignores the reviewer’s answer, even a reject. Keep the predicate deterministic, because a threshold computed from a live exchange rate could flip between pause and resume. The LangChain vs LangGraph comparison explains where each library fits.
Copilot Studio: Agent Flows, Data Policies and External Threat Detection
Copilot Studio blocks user prompt injection (UPIA) and cross-domain prompt injection (XPIA) at runtime. For approvals, agent flows support multistage approvals, AI approval stages and conditions between stages, all still in preview as of November 2026.
External threat detection adds a pre-call check. The agent calls your security provider every time it plans to run a tool, and the provider answers allow or block. It applies only to agents that use generative orchestration.
As of November 2026, the default fails open: with no decision within one second, the tool runs unless an admin changes the error behavior. For payment and send tools, change that setting so a missing decision blocks the call. Our Copilot Studio guide covers the rest of the platform.
Amazon Bedrock: User Confirmation, Return of Control and AgentCore Policy
Bedrock Agents offer user confirmation for each action-group function. With requireConfirmation set to ENABLED, the end user must confirm or deny before the function runs.
That is consent from the person in the chat, not a separate approver. For payments, use return of control instead. Setting customControl to RETURN_CONTROL hands the action and its parameters back to your application, which then runs or refuses it in its own systems.
Policy in Amazon Bedrock AgentCore sits at the Gateway and checks each request against Cedar policies before tool access. It denies by default , and rules can read the call’s input parameters. Bedrock Guardrails, by contrast, filter content and do not authorize actions.
Kanerika Service
Agentic AI Services
Kanerika designs, builds and runs AI agents on Azure AI, Copilot Studio and Power Platform that escalate to your people at approval steps.
Explore Agentic AI Services Guardrail Defaults Compared Across LangGraph, Copilot Studio and Bedrock
Aspect LangGraph and LangChain Copilot Studio Amazon Bedrock Interception point interrupt() in a node; middleware on tool calls External threat detection before each tool call; agent flow approvals requireConfirmation; RETURN_CONTROL; AgentCore Gateway policy Where business checks run Node or tool code you write The flow, plus your threat-detection provider Your application, or Cedar policy at the Gateway Approval persistence Checkpointer state keyed by thread_id Approval stages in the agent flow (preview) Temporal policies over session events Default with no decision Waits at the interrupt until resumed Tool runs after one second without a decision, unless changed AgentCore Policy denies unless a permit applies Gap to cover A when predicate that changes on resume Classic agents without generative orchestration requireConfirmation is end-user consent, not separate approval
Testing AI Agent Guardrails Before Granting Write Access
A guardrail nobody has tried to break is only a hope. Build a negative test for each action before it gets write access, and run the suite on every policy change.
Action Negative test Expected result Payments The bank call times out and the agent retries One payment; status checked with the same idempotency key Outbound email A recipient is added after approval Approval void; message saved as draft Code execution The script tries to reach the internet Connection fails; output quarantined if limits break Database writes An update touches another tenant’s rows Zero rows changed; transaction rolled back Ticket and CRM updates A status change would email a customer Change held for approval with the side effect listed
Three approval rules apply to every row. A changed payload needs fresh approval, an expired approval cannot execute, and a retry can never duplicate the action.
Track four numbers: prohibited actions that ran, legitimate actions blocked, approval bypasses and added latency, with the first and third held at zero. For the general method, see the evaluation section of our AI guardrails guide and the AI agent evaluation post. AI red teaming then adds adversarial tests.
Keep sensitive payloads out of the logs and store a hash instead, then use AI agent observability to trace those records across runs.
Release Each Action Separately: Read-Only, Approval-Gated, Autonomous
AI agent guardrails also control how fast an agent gains write access, and it should never get all of it at once. Each action climbs its own ladder, and each step up needs evidence from the tests above.
Read-only. The agent proposes the action, and a person executes it.Approval-gated. The agent executes after sign-off on the exact payload.Autonomous within limits. The agent executes under caps, with sampled reviews and alerts.Give each action a named owner and its own kill switch. That way, when the email action misbehaves, you stop email without stopping payments. A permission model such as the agentic AI permission control framework decides who holds those switches.
To decide how far up the ladder each action may go, an AI risk assessment template gives you a scored starting point. The agentic AI risks overview lists what each step can go wrong on.
Regulation points the same way: Article 14 of the EU AI Act requires effective human oversight of high-risk systems. Regulation (EU) 2026/1744 moved Annex III obligations to 2 December 2027.
Most of these five actions are not high-risk on their own, so treat the ladder as good practice. The EU AI Act compliance guide and the wider AI governance hub cover the policy side.
How Kanerika Builds Guardrails into Production AI Agents
Kanerika’s agentic AI services build agents that escalate “to your people at key approval steps.” Every engagement follows the IMPACT methodology. Agent development starts with a process audit to find tasks suited to autonomous execution, then moves to agent architecture design.
Agents are tested in controlled environments before production rollout. Clients then get documented agent logic, integration specifications and governance controls that satisfy security and compliance review. As a Microsoft Solutions Partner for Data and AI, Kanerika builds on Azure AI, Copilot Studio and Power Platform.
Guardrail policy also sits within Kanerika’s AI governance services . They cover technical guardrails with content filtering, plus defined escalation procedures with periodic review. In addition, Kanerika holds ISO 27001 and ISO 27701:2019 certifications, SOC 2 Type II compliance and a CMMI Level 3 appraisal.
A Review Step Before the System of Record
One accounts payable project shows the review step at work. A US fuel distributor keyed more than 1,000 PDF invoices a month, from 50+ vendors, into NetSuite by hand. Kanerika implemented UiPath with AI and ML extraction, added manual review in UiPath Action Center, and automated the NetSuite entries.
The result was 400+ manual hours saved per month after the first three months, with zero errors. In that design, the review queue sat exactly where a payment guardrail belongs, between extraction and the write to the system of record. The accounts payable automation guide explains that pattern in more depth.
Case Study
400+ Manual Hours Saved a Month in Accounts Payable with UiPath
Kanerika added manual review in UiPath Action Center before NetSuite entries for a US fuel distributor, saving 400+ manual hours a month with zero errors.
Read the Case Study → If you want a second pair of eyes on your own agents’ specs before they go live, you can talk to Kanerika’s team .
Five Actions, Five Specs, One Rule
AI agent guardrails go on each action that changes a real system, checked in code just before it runs. Payments and database writes fail closed, email falls back to a draft, code runs without a network, and CRM changes surface their side effects. Write the five specs, set every platform default yourself, and release one action at a time.
Frequently Asked Questions
How do I implement guardrails for AI agents?
Write a five-field spec for every action that changes a real system, covering the action, its check, its fail mode, its approval rule and its log field. Then enforce the checks in a gateway, inside the tool, and in the backend system itself. Test each action with negative cases before granting write access.
Which agent actions need human approval?
Approval belongs on actions that are costly or hard to reverse. Typical triggers are a new payee or changed bank details, payments above a threshold, external or bulk email, bulk or destructive database changes, and CRM closures or reassignments. Routine low-value actions can run autonomously within caps, with sampled reviews and alerts.
Should an agent guardrail fail open or fail closed?
Payments and database writes should fail closed, so nothing executes when a check fails or the checker is down. Outbound email can fall back to a saved draft for review. Code execution should kill the run and quarantine its output. Fail open only for read-only actions where a missed check cannot cause harm.
Do Amazon Bedrock Guardrails stop an agent from making an unauthorized payment?
No. Bedrock Guardrails filter content such as harmful text and personal data in prompts and responses. They do not decide whether an agent may pay a vendor. For that, use return of control so your own payment service runs the checks, or a deny-by-default Cedar policy in Amazon Bedrock AgentCore.
How do I require approval before a LangGraph agent calls a tool?
Add LangChain’s HumanInTheLoopMiddleware with an interrupt_on entry for the tool, set allowed_decisions, and attach a checkpointer. The agent pauses at the call, and your reviewer resumes it with approve, edit, reject or respond. If you add a when predicate, keep it deterministic, because it runs again on resume.
Does an approval stay valid if the agent changes the tool arguments?
No. Bind each approval to a hash of the exact payload, such as payee, account, amount, currency and invoice reference. If the agent edits any of those fields after sign-off, the hash no longer matches and the approval is void. Short expiry windows close the same gap over time.
How do I stop an AI agent from sending the same payment twice?
Put an idempotency key on every payment request, so a retry with the same key returns the saved result instead of charging again. Also, when the bank call times out, the agent should check the payment status with that key rather than send a fresh request.
What does Copilot Studio do if its external threat detection does not respond?
By default, if no allow or block decision arrives within one second, the agent proceeds and the tool runs. Admins can change this error behavior so a missing decision blocks the tool. That change matters for payment and send tools, where a fail-open default could let a risky action through.
