AI agent authorization at the action boundary

Write an action authorization contract

An authorization decision needs more than a user ID. Identify the principal, the tenant, the target resource, the requested operation and the relevant conditions. The conditions might include a monetary limit, resource version, approval requirement or time window. Define where each value comes from and which service is authoritative.

OWASP recommends server-side authorization, checks on requests and default denial. In an agent system, model-generated tool arguments are another untrusted request input; they do not replace the identity established by the application.[1]

Worked scenario: a support credit

A synthetic support operator may read an account and propose a service credit. Policy allows the operator to approve credits up to a defined limit for accounts in the operator’s tenant. Larger credits require another authorized approver. The model produces an account ID, amount and reason.

The application derives the operator and tenant from authenticated context, fetches the account within that scope and validates the amount. It checks the permitted action and any approval requirement. The model cannot expand the limit by describing the request as urgent, and a retrieved support note cannot grant permission to issue the credit.

At execution, the service validates the current resource version and policy again. If the operator has lost access or the proposal has changed, execution stops. An earlier successful read is not a standing grant to write later.

Preserve authority through delegation

A background worker often runs under a service identity. That does not mean every task should inherit all of the service’s technical privileges. Preserve the initiating authority and the allowed task scope, or use an explicit tenant-scoped service policy when the task is not acting for a person.

• Distinguish the identity running the process from the authority for the business action.
• Carry an authenticated task reference rather than trusting identity fields written by the model.
• Limit tools and credentials to the action class the task needs.
• Recheck current resource policy when the action executes.
• Record the relevant delegation and decision without storing unnecessary secrets or personal data.

If the intended behavior is to continue after the initiating user leaves, define that as a deliberate service-owned workflow with its own policy. Do not let an implementation accident decide whether a departed user’s tasks retain authority.

Use several layers for different purposes

Defense in depth is useful when the layers have explicit jobs. Duplicating inconsistent policy logic across a gateway, tool wrapper and domain service can create gaps. Prefer one authoritative decision contract with enforcement at the points where access or mutation actually occurs.

Test denials as product behavior

An authorization suite should vary the principal, resource, tenant, operation and timing. Test the same valid request under an invalid authority. Include permission changes between proposal and execution, and attempts to reuse an approval for a different payload.

Track attempted and blocked violations separately from successful unauthorized actions. The former can demonstrate a working boundary; the latter is a critical failure. Both can inform investigation, but they should not be collapsed into one ordinary error rate.

What to ask during a vendor review

Ask the vendor to walk through one allowed action and the same action denied by tenant, role, resource and timing. Inspect the code or contract where the decision is enforced. Ask how delegation works and what happens to a pending task when permissions change.

The credible answer identifies the trusted inputs, enforcement service, policy version and recorded outcome. A prompt that says “only access authorized data” can guide behavior, but it is not that enforcement mechanism.