An agent can authenticate successfully and still ask to do something it should not do. A valid credential might permit access to a customer system while the particular task permits only a summary. Exporting every customer record would cross that task boundary even if the API accepts the token.
Put the check where the action happens
Runtime authorization evaluates the proposed operation before execution. Microsoft’s reference architecture separates the place that enforces the result from the service that decides policy. The distinction matters: the component holding the tool credential must be able to refuse execution, regardless of what the model asks next.
01 / Runtime authorization
One action. One enforceable decision.
Proposed action
User · task · target
Enforcement point
Holds the tool credential
Checks policy using context + current rules; receives the decision.
Decision outcomes
Allow → protected service executes the action.
Deny / stop → no tool execution.
Hold for approval → bind approval to the exact action, then return to policy.
TrustCyber / Illustrative design
The decision needs enough context to distinguish legitimate work from an overreach: the acting user, agent identity, approved task, operation, target, data classification, and relevant conditions. A policy can then allow a bounded read, refuse an export, or ask a person to authorize a specific change.
Keep credentials outside the model’s text and make the enforcement route unavoidable. If the same agent retains a broad token for a direct call, a separate policy service cannot reliably govern that action. The protected service should also enforce the business rules it knows best, such as whether an account is eligible for a refund.
The retry is a new request
Suppose a person approves sending a report to one internal recipient. Delivery fails, and the agent proposes a shared link instead. The destination, exposure, and retention may now be different. Reusing the original approval without checking those differences turns a narrow authorization into a wider one.
Bind approval to the meaningful parts of the action. Where the workflow allows minor changes, define those tolerances explicitly. Otherwise, changed payloads, recipients, amounts, or resources should return to the decision point. This is particularly important when the model replans after an error.
| Test | Expected evidence |
|---|---|
| Approval has expired | Execution is held or denied; the reason is recorded |
| Policy service is unavailable | The configured safe failure behaviour is observed |
| Tool redirects to another resource | The new destination is checked before access |
| Agent attempts a direct API call | The protected action cannot bypass enforcement |
Keep the decision and the result
An authorization log explains why an action was permitted. A tool response records what the service reported. The downstream state establishes what actually happened. Keep these linked through request identifiers so investigators can distinguish a refused operation, a successful change, and a timeout with an uncertain outcome.
This adds work to the execution path, so choose policy attributes that can be obtained reliably and measure the latency. Start with consequential operations such as external sends, financial changes, and access grants. The practical test is whether a reviewer can reconstruct one action from the original task through the final state without relying on the agent’s account of its own behaviour.
Selected primary sources
Open the primary-source pages used to verify the claims summarized here.