# Check Permission at the Moment of Action

> How runtime authorization connects an agent’s proposed tool call to policy, human approval, and the protected service.

[Canonical HTML page](https://trustcyber.ca/insights/ai-agent-runtime-authorization/)

- Author: [Junior Williams](https://trustcyber.ca/about/)
- Type: Insight brief
- Published: 2026-09-26
- Modified: 2026-09-26
- Topics: AI governance, Agentic AI, Cybersecurity

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.

![Proposed action reaches an enforcement point, which consults policy. Allowed actions reach the service; denied actions stop; approval-required actions wait.](https://trustcyber.ca/images/insights/decision-series/runtime-action-flow.svg)

Illustrative control flow. Human approval returns a decision to the enforcement point; it does not bypass the check.

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.

**Failure cases worth exercising**

| 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

- [Microsoft Security: Runtime authorization beyond identity](https://techcommunity.microsoft.com/blog/microsoft-security-blog/authorization-and-governance-for-ai-agents-runtime-authorization-beyond-identity/4509161)
- [AWS Prescriptive Guidance: Governing and architecting agentic AI at scale](https://docs.aws.amazon.com/prescriptive-guidance/latest/govern-architect-agentic-ai/introduction.html)