An execution boundary for AI agents

An AI agent can decide that a customer deserves a refund. The dangerous part begins after that decision. Which account will receive it? Is the amount still the one a human reviewed? What happens when the network times out and the agent retries? Can the same service identity request and approve its own action? If a process crashes after the payment provider accepts the refund, does the system run it again?

Those are not prompt-engineering questions. They are transaction, authorization, and recovery questions. I built AgentBarrier to put those questions in one explicit boundary between an AI agent and a consequential tool.

Approval is not just a button

The first version of human-in-the-loop control often looks like this: pause the agent, show a message, let someone click approve, then resume. That is useful, but it leaves several guarantees unstated.

• Exact binding. Approval for a $100 refund to customer 42 must not authorize $1,000 to customer 84.
• Single execution. A retry should return the first result instead of calling the refund API again.
• Unknown outcomes. A crash after execution starts must not be treated as a clean failure that is safe to retry.
• Separation of duties. In a shared deployment, the requester should not silently become its own reviewer.
• Durable evidence. The decision and execution history should survive outside the model's conversation.

AgentBarrier treats the whole path as one state machine. Policy evaluates the request. If review is required, the exact tool name, arguments, requester, policy version, and business idempotency key are stored together. Approval binds to that stored request. Execution is claimed atomically. A completed result is recorded and replayed on retry.

agent request
    ↓
deterministic policy
    ↓
exact human approval
    ↓
atomic execution claim → consequential tool
    ↓                         ↓
stored result          unknown outcome → reconcile
    ↓
safe replay on retry

The model does not get to reinterpret any of those transitions. It can propose an action, but deterministic code decides whether that action is denied, held for review, or allowed to execute.

A refund I can test without moving money

The repository includes a credential-free refund demonstration. A new request is held before any ledger entry exists. In version 1.1, a local operator can inspect and decide the exact refund in the same terminal session:

This exact refund requires your approval:
  account_id: customer-42
  amount: 100
  request_id: refund-demo-1

[a] Approve and execute  [r] Reject  [l] Leave pending:

Approving records the reviewer and then executes once. Rejecting leaves the ledger untouched. Leaving it pending lets another reviewer handle it later. If the same request ID has already succeeded, the command returns the stored result without asking again. That behavior can look surprising during a demo, but it is the point: a retry is not a second refund.

There is also a general terminal reviewer for pending actions:

agentbarrier approvals review \
  --db agentbarrier.db \
  --decided-by alice

The menu shows the policy, requester, exact JSON arguments, request digest, idempotency key, creation time, and expiration time before offering Approve or Reject. The terminal identity is caller-supplied, so I treat this as a trusted local workflow. Production teams should use the authenticated dashboard, HTTP API, or Slack integration with real requester and reviewer identities.

What sits behind the boundary

The boundary is useful anywhere an agent can cause an external effect: payments, database writes, deployments, account changes, outbound messages, infrastructure operations, or MCP tools. AgentBarrier supports direct Python functions and transport-neutral dispatch, plus integrations for MCP, OpenAI Agents, LangGraph, PydanticAI, and Google ADK.

SQLite is enough for a local process or a trusted single host. PostgreSQL provides the shared transactional store for multiple workers. On top of approvals, the runtime includes emergency pauses and fixed-window action or value limits, so an operator can stop a tool or cap its blast radius without changing a model prompt.

Each lifecycle transition produces an integrity-linked receipt. That does not make the database magically untouchable, but it makes missing, reordered, or modified history detectable during an audit.

The limit I will not hide

AgentBarrier only protects tools routed through AgentBarrier. It does not automatically intercept an unrestricted shell, direct file edits, or credentials that an agent can use around the gateway. If an agent has the original GitHub token, payment key, or cloud credential, it can bypass a wrapper and call the provider directly.

The deployment rule is therefore simple and non-negotiable: the consequential credential and client must live behind the boundary. The agent receives access to the mediated tool, not a second unmediated path. GitHub branch rules should protect branches. Cloud IAM should restrict cloud access. AgentBarrier governs the agent action at the application boundary; it does not replace the platform's own controls.

There is one more honest edge. No distributed system can promise magical exactly-once effects after a network failure. If a worker may have completed an external action but lost the response, AgentBarrier records an unknown outcome and refuses a blind retry. An operator or downstream idempotency lookup must reconcile what actually happened.

Why I made it a package

Approval logic is easy to scatter across callbacks, framework hooks, and application code. The result works until the first retry, cancellation, worker crash, or second service. I wanted one reusable control plane with behavior that can be tested without model credentials and inspected without trusting a model's narration.

AgentBarrier is model-free at the enforcement layer, open source under Apache 2.0, typed, and tested across Python 3.10 through 3.13. The package is available on PyPI:

pip install agentbarrier

The GitHub repository includes the refund example, runtime documentation, threat model, deployment guidance, and framework integrations. If you are building an agent that can change something outside its own conversation, that is the moment to give the action a boundary of its own.

---

I'm Binaya. I co-founded Yanib and build AI features at Fluid. More at dhakalbinaya.com.np.