Agentic AI · Part 7 of 7
AI Agents in Production
Running agents in production: authorization, confirmation, auditing, limits, and sandboxing.
The loop in The Agent Loop runs any tool the model requests. What has to surround it before it's safe to point at production is authorization, confirmation, auditing, limits, and sandboxing.
The loop and its authorization step
flowchart TD
A[User request] --> B[Model reasoning]
B --> C[Tool selection]
C --> D{Authorization}
D -- allowed --> E[Execution]
D -- denied --> B
E --> F[Observation]
F --> B
B --> G[Result]
Every box in that loop except authorization is the model or plumbing that carries its output along. Authorization is the one box that must not be the model. A model can request that an action happen; whether it's allowed to happen is a decision made by code outside the model, using rules the model doesn't get to set or override. A model approving its own request is not authorization.
Designing the authorization boundary
A few concrete practices make that boundary enforceable:
- Tool schemas. Every tool an agent can call should have an explicit schema: exact parameters, types, and allowed values. A tool that accepts a free-text SQL string is a much larger authorization surface than one that accepts a customer ID and a fixed set of operations on it.
- Least privilege. An agent's tools should be scoped to what its task needs. An agent that only ever needs to read order status shouldn't be handed a tool that can also cancel orders, even if it never happens to ask for it.
- Confirmation. For consequential actions, irreversible ones especially, the authorization step can require explicit human approval before execution instead of deciding automatically. Cheap, reversible actions can be auto-approved; a refund over a certain amount, or anything that deletes data, is a reasonable place to require a person in the loop.
- Idempotency. A tool call that gets retried, whether because of a network error or because the model asks for the same thing twice, shouldn't cause the action to happen twice. Designing tools so that calling them again with the same input is safe (charging an order once even if the charge request is sent twice) prevents a class of bugs that only shows up under retry, which agent systems do routinely.
- Audit trails. Every tool call an agent makes, what it requested, whether it was authorized, and what actually happened, should be logged somewhere a person can review after the fact. When an agent does something wrong, the audit trail is what turns "we're not sure what happened" into "here's exactly which step went wrong and why."
- Sandboxing. Where possible, point an agent's tools at an isolated environment instead of production systems: a scratch database instead of the live one, a container with no network access for running untrusted code. A mistake contained to a sandbox is a bug; the same mistake against production is an incident.
- Limits. Cap the steps, tokens, and spend an agent may use on one task, and set timeouts on tool calls. An agent that loops on a failing step otherwise runs up cost until someone notices.
All seven practices hold regardless of which orchestration framework or which model is in use. They're the same authorization boundary Identity and Access Management covers for human and service accounts, applied to a caller whose next request nobody can know in advance, because a model is the one deciding what to ask for.
Try it yourself
The Colab notebook builds each part of this series around a small open model, in the same order: the loop, structured tool calling, planning, memory, and a small team of agents you can chat with. It then rebuilds the same team in LangGraph.
This site's Roundtable project is the same supervisor-and-specialists pattern running as a live app.