An AI agent's permission boundary is not the list of tools in its system prompt. It is the set of effects the deployed system can produce after identity, delegation, credential issuance, policy evaluation, resource policy, and downstream behavior are all applied.
This matters because a narrowly worded tool can still carry broad authority, while a broadly described tool can be safely constrained by deterministic enforcement. Review the whole action path, not the model-facing interface in isolation.
Start with the actor and the delegation
An action normally begins with a human, service, scheduled job, or another agent. Record that initiating identity and the scope it was allowed to delegate. If an agent acts under a shared service credential with no attributable initiating identity, it becomes difficult to distinguish approved automation from confused-deputy behavior.
NIST's draft agent identity and authorization concept frames agent systems around non-human identity, delegation, authorization, data flows, logging, and attributable outcomes. NIST/NCCoE agent identity concept paper
The first review questions are therefore:
- Who requested the objective?
- Which identity does the agent present to each tool?
- Is authority delegated from the requester or inherited from the platform?
- Can one tenant cause the agent to act with another tenant's authority?
- What condition ends the delegation?
A tool schema is not an authorization policy
A tool definition tells the model which operation it may request and how to format parameters. It does not necessarily constrain the credential used behind the tool, the resources accepted by the service, or effects triggered after a successful response.
Model the boundary as a chain:
initiator → agent/workflow → tool adapter → credential → policy decision → resource → downstream effect
At each edge, record both an allow condition and a failure mode. A send_message tool, for example, may expose one recipient field to the model but use a service principal that can message every workspace. A UI-level recipient allowlist is not enough if another invocation path bypasses it.
OWASP's agentic guidance includes threats involving tool use, permissions, identity, memory, and multi-step behavior. OWASP agentic AI threats and mitigations Those categories become easier to reason about when placed on the same authority path.
Effective permission is composed at runtime
Cloud authorization provides a concrete example. AWS evaluates identity policies together with applicable resource policies, permissions boundaries, session policies, and organization policies; explicit denies and request context affect the result. AWS IAM policy evaluation logic
The lesson is broader than AWS: reading one attached policy is not equivalent to calculating an agent's effective authority. The review must include:
| Layer | Evidence to collect |
|---|---|
| Identity | Stable agent, requester, tenant, and workload identifiers |
| Delegation | Scope, purpose, duration, and approval |
| Tool | Operation semantics and parameter constraints |
| Credential | Issuer, audience, lifetime, and binding |
| Policy | All applicable allow, deny, boundary, and context rules |
| Resource | Resource policy, ownership, sensitivity, and state |
| Effect | Direct mutation plus asynchronous and downstream consequences |
Worked example: a deployment agent
Assume an agent can call deploy(service, image). The apparent capability is one deployment operation. Its real authority may include:
- selecting an image from any registry namespace;
- assuming a CI role shared across repositories;
- updating every service in a production cluster;
- passing a more privileged runtime role;
- causing the deployed workload to read secrets or modify data.
Restricting only the service name leaves the image, role-passing, environment, and downstream workload authority unresolved. The appropriate control set could include immutable artifact identities, repository-bound workload identity, environment approval, resource-scoped deployment permissions, pass-role constraints, and post-deployment verification.
Review deny paths and recovery paths
An authority map is incomplete if it only describes approved success. For each high-impact action, determine whether missing identity or context produces a deny, whether partial completion is possible, and whether the resulting resource change can be reversed.
The review artifact should state:
- the highest-impact reachable effect;
- the identities and policies that permit the path;
- which controls are deterministic and which depend on model behavior;
- which evidence proves the policy decision and resource effect;
- how active sessions are revoked;
- how incomplete or unauthorized changes are recovered.
Practical takeaway
Treat the agent-facing tool list as the start of permission analysis. The security boundary is the composed, runtime path from initiator to durable effect. If that path cannot be reconstructed, the system cannot yet demonstrate least privilege or reliable containment.
Continue with Capability, Authority, and Reach for the deeper path, evidence, and cut-set model.
Limitations
This model does not calculate permissions for a specific product, cloud account, or agent framework. It also cannot prove runtime reachability from static definitions alone. Dynamic policy, resource state, indirect calls, and service behavior must be verified in the environment where the agent operates.