Authorization sits after agent identity and before a tool or API changes anything. A model may propose an action, but policy code evaluates the requested operation, resource, user delegation, environment, and limit. That makes the control testable. It also means a prompt injection cannot grant itself access simply by producing plausible text.
What does a useful authorization decision check?
The decision needs more than a tool name. “Send email” is too broad when the recipient, attachment, sender identity, and volume can change the risk. A good policy checks the action, exact parameters, target resource, tenant or project, time limit, and the authority delegated by the user. Authorization should bind to the request that will execute, not a vague category of work.
For example, an agent may read invoices for one account but not export every account. It may draft a customer reply but not send it. It may create a refund request below a threshold but not approve its own request. These boundaries give the agent useful autonomy without handing it a standing administrator credential.
How does authorization differ from a guardrail?
Guardrails are broader controls around an agent. They may use deterministic policy and scope checks, or model and content checks. Authorization has a narrower role: at the execution boundary, it evaluates a specific identity, action, resource, scope, and time, then allows or denies the request. The tool must refuse an unauthorized request even if the model insists it is safe.
The runtime should validate structured tool calls before evaluating policy. It should log the identity, delegated authority, proposed parameters, decision, and result. That record lets an operator explain a denied action and trace an allowed one without saving an entire model conversation.
When should an agent ask for approval instead?
Authorization answers whether an action is within a standing policy. Tool approval is for actions that need a fresh decision, such as sending a contract, deleting data, changing a production setting, or paying a supplier. The agent can be authorized to request approval without being authorized to perform the action alone.
Least privilege means each agent receives the smallest useful permission, for the shortest useful time. When a workflow needs broader access, split it into narrow steps or use a separate agent identity. A single powerful agent is harder to review, revoke, and contain.
How should teams test it?
Start with abuse cases: a modified recipient, a cross-tenant record, a higher amount, an expired delegation, and a model that asks for an undeclared tool. Each case should reach the same policy boundary and be denied. AI red teaming can supply adversarial inputs, but the pass condition is simple. No denied request can reach the external system.