11How to
How do you control and record what an AI agent may do before it acts?
Put the decision outside the model. Your agent proposes an action. Before the tool runs, a separate check that the agent cannot edit answers allow, deny or ask a person, and records the decision with the exact details it judged. Write down in advance what each agent may do, on which systems, within which limits, and which actions need a person.
A prompt that tells the agent to ask before acting is a request, not a control.
7 steps
- List what each agent may do: its owner, its actions, the systems it may touch, its limits, and when its permission ends.
- Give it the narrowest tools. A tool that reads records cannot change them.
- Decide outside the model. Before each consequential tool call, a check the agent cannot edit answers allow, deny or ask a person. Deny what is not on the list.
- Send high-impact actions to a person with separate authority. The agent that proposed an action cannot approve it.
- Bind each decision to the exact details: agent, action, target, arguments. A clearance for 1 payment is not a clearance for another.
- Treat an approval as single use, with an expiry. Check it when the action runs, not when the workflow resumes.
- Keep the decisions where the agent cannot rewrite them, and review denials and escalations each week.
How are teams handling authorization for agent tool calls in production?
The pattern that holds up: the model proposes, code outside the model decides, and the tool runs on an allow. Check against both identities, the agent's and the person or service it acts for, and never trust an identity the model wrote into the request. Check at each consequential call, not once at the start of a run.
What OWASP advises
OWASP names excessive agency as a risk for language model applications: too much functionality, too many permissions or too much autonomy. Its advice includes to “implement authorization in downstream systems rather than relying on an LLM” and to have a person approve high-impact actions.
Where TrustGate fits
TrustGate returns a signed allow, deny or escalate decision before the action runs, for actions that go through it. It answers under the policy you set, so what it allows or denies depends on your rules. The receipt binds the agent, action, target and exact arguments that were evaluated.
Escalate means ask a person, and that answer is on the record. It records whether approval was asserted, not who approved. It does not replace your identity and access system.
What this page is not
- Not identity and access management.
- Not a promise that each tool call is checked. A check covers the calls you route through it.
- Not a lock. Signatures prove and detect. They do not prevent.
Quick answers
How do you handle authorization for AI agent tool calls in production?
The model proposes, code outside the model decides, and the tool runs on an allow. Check at each consequential call, against the agent's identity and the identity it acts for. Send high-impact actions to a person with separate authority, and record each decision with its exact details.
Is a system prompt that says ask before acting enough?
No. A prompt is a request to the model, and the model can be talked out of it. The check has to sit outside the model, in code the agent cannot edit.
Can an approval be reused after it was given?
It should not be. Bind it to the exact action and details, give it an expiry, and check it when the action runs, not when the workflow resumes. In our lab, the same payment request, word for word, came once with its approval already used and once with it still valid. See what our tests found
Sources
Each source was read on October 13, 2026. Wording in quotation marks is exact; the rest is paraphrase.
- LLM06:2025 Excessive Agency · OWASP Gen AI Security Project · 2025 (no day shown on the page)