What access control covers
An agent may authenticate successfully and still lack permission to perform a particular task. Identity answers who is calling. Authorization answers whether this caller can perform this action now. Credential custody determines which component can make that decision effective.
For example, a procurement agent might read approved invoices, prepare a payment request, and send that request to a finance approver. These are different capabilities. The permission to read an invoice should not silently include permission to pay it.
Keep a named owner for the agent and a separately authorized approver for the request. When an agent acts for an employee, record the delegation and limit it to the relevant resource and lifetime. A delegated agent should not gain authority simply by describing a broader task.
Make an action-level decision
The following is an evaluation worksheet, not an AAES API payload. Replace the example values with a bounded workflow in your test environment.
| Decision input | Example constraint | Failure to test |
|---|---|---|
| Agent and owner | Procurement agent assigned to a named operations manager | Unknown or disabled agent attempts the call |
| Resource and action | Read an invoice in the test account | Change the resource to another account |
| Delegated scope | Read-only access for the current work item | Use the grant for a write or unrelated task |
| Approval | Finance approval for the exact payment request | Change the payee after approval |
| Spending commitment | Reserve the amount before dispatch | Submit concurrent requests near the ceiling |
| Credential path | The broker controls the downstream credential | Call the provider directly from the agent |
| Outcome | Match the recorded decision to the provider result | Lose the response and retry the same effect |
A successful policy check is insufficient if the agent can bypass it using another credential. Inventory standing secrets, alternate network routes, and delegated tokens as part of the same evaluation. State clearly which paths are enforced and which are only observed.
Bind approval to the action being reviewed
Show the approver the target, action, amount where relevant, and consequences of the request. Record who approved it and why that person had authority. Expire approvals, invalidate them when decision-relevant inputs change, and define how retries behave.
Separate access approval from action approval. Granting a temporary entitlement to request a capability does not necessarily approve every use of it. A consequential action may still require a fresh decision. The human-in-the-loop guide explains these approval patterns; the spending controls guide covers reservations and reconciliation.
Evaluate the boundary before expanding access
- Choose one synthetic workflow and identify its credential owner, agent manager, and approver.
- Run an allowed action and confirm its outcome in the downstream test system.
- Try an unauthorized resource, expired approval, changed request, and direct credential bypass.
- Interrupt the decision journal or policy service. Determine whether new work stops and how previously issued grants behave.
- Run concurrent requests near the budget ceiling and retry an uncertain result. Check the provider before authorizing a second effect.
- Export the records and verify them using trust material retained separately from the export.
Document both what passed and what remains outside the boundary. Evidence integrity does not prove that every action was captured. See the public control-evaluation procedure for more detailed acceptance criteria.
Evaluating AAES for this workflow
AAES applies scoped permissions, authorized-person approvals, and configured spending limits to supported actions routed through it. On a brokered execution path, the downstream credential stays behind the broker. Observation-only integrations cannot prevent a direct call.
Customer-operated evaluation access is available by request. Live provider compatibility must be validated for the proposed workflow; capability-pack review is not live integration certification. Inspect the capability matrix, trust model, and API documentation before selecting an integration.
This guide is authored by AAES. Its workflow is a proposed evaluation method, not an independent assessment of the product. For MCP transport-specific considerations, read the MCP security checklist.
Common questions
What is AI agent access control?
AI agent access control determines which resources and actions an agent may use, under whose authority, and under what conditions. A useful design checks the agent, delegated scope, requested action, target resource, and current policy before the action reaches the business system.
Is an agent role enough to authorize a payment?
A role can establish eligibility, but a payment may also require an amount limit, a permitted recipient, a specific human approval, and a budget reservation. Define those conditions at the point that controls execution and verify the resulting payment with the provider.
Can human approval be reused for a changed request?
For action-specific approval, changing the recipient, amount, resource, or other decision-relevant input should require a new approval. In AAES, approval for an irreversible capability binds to the exact request and expires. It does not grant unrestricted permission for later actions.