Teams should require request-by-request policy decisions, not session-level trust. Each call should be tied to a verified principal, evaluated against least privilege, and written to logs with enough detail to explain why it was allowed or denied. That is the only practical way to preserve accountability across delegated agent activity.
Why per-call authorization is the right control boundary for agents with API and MCP access
When an agent can reach internal APIs or MCP servers, the control boundary has to move from “the agent is trusted for this session” to “each request is independently allowed.” That means the platform should evaluate the current principal, the requested action, the target resource, and the context on every call, rather than assuming prior approval still holds. The MCP authorization specification is built around that model.
That shift matters because agents are not static users. They chain tools, cross trust boundaries, and often operate on behalf of a person or workflow whose authority should be narrower than the agent’s technical reach. Per-call policy decisions make the authorization decision visible and reviewable at the point where impact occurs, which is the only place least privilege can be enforced with any precision.
For MCP specifically, the practical question is whether the server is treating itself as a resource server with its own policy, or whether it is merely accepting whatever token the client forwards. A server that accepts token passthrough without audience checks or resource-specific evaluation creates an easy path for confused deputy behaviour and over-broad delegation. The MCP Security Guide covers those authorization and gateway patterns in detail.
What least privilege and verified principal mean in an agentic workflow
Least privilege in this setting is not a slogan, it is an operational rule about the scope of the token, the scope of the action, and the scope of the target. The agent should not inherit a standing blanket trust just because it is authenticated once. Instead, the request should carry enough identity context to determine who or what is acting, which delegated authority is in play, and whether the action fits the narrowest workable permission set. The AI Agent Authorisation Guide is a useful companion for task-scoped access and per-action decisions.
Verified principal also means the system can distinguish between the end user, the agent, and any service account or workload identity the agent uses under the hood. If those are blended together, accountability breaks down and revocation becomes blunt, because you can no longer tell whose authority to reduce or whose access path to disable. For teams building agent controls, the NHI Authentication Guide helps frame how non-human actors should authenticate without turning authentication into open-ended trust.
Where agents operate against internal APIs, the same logic should apply to authorization scopes, function boundaries, and object boundaries. An API that is safe for read-only lookup is not automatically safe for write, delete, or bulk export, and an MCP tool that is convenient in a demo may become dangerous once it can touch production data or side-effecting actions. The OWASP API Security Top 10 remains relevant whenever the agent’s action path is exposed through an API.
How to preserve accountability without making agents unusable
Good logging is what makes per-call authorization defensible after the fact. Teams should record enough context to reconstruct the decision, including the verified principal, requested resource, action, policy result, and any delegation or approval signal that influenced the decision. That is especially important when the agent makes many small calls rather than one obvious transaction, because the risk is often distributed across a chain of individually modest steps. The AI Agent Observability, Audit and Incident Response Guide is the strongest internal reference for attribution and audit trails.
At scale, the mistake is to log only the final outcome or only the user-facing prompt. That leaves security teams unable to answer basic questions such as which tool was invoked, which policy condition failed, or whether a retry changed the effective privilege path. If the logs cannot support that reconstruction, the policy model is probably too coarse to trust in production. For teams that need a broader governance view, the Agentic AI Security Guide ties the tool layer and identity layer together.
Risk and Threat Considerations
Agents with internal API or MCP access are attractive targets because they often sit at a trust intersection: they can hold delegated authority, access sensitive tools, and act quickly across many systems. If the platform treats a session as trusted after the first approval, a later malicious or unintended call can reuse that trust to reach data or functions that were never meant to be broadly exposed.
Failure mechanism: Standing trust, token passthrough, or vague delegation lets one successful authentication or approval unlock a long chain of downstream actions. That creates confused deputy risk, excessive privilege, and poor blast-radius control when the agent is steered, compromised, or simply makes a bad tool choice.
Impact: Teams can lose the ability to prove why a specific action happened, limit what the agent could do at the moment it did it, or revoke only the unsafe path. In practice, that raises the cost of incident response and increases the chance that an agent can read, change, or exfiltrate more than intended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent access to APIs and MCP servers depends on per-action privilege decisions. |
| Recommendation — Enforce per-action authorization and least privilege for every agent tool call. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Agent-invoked internal APIs need function-level checks on each request. |
| Recommendation — Validate function-level authorization on every API request from the agent. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Per-call accountability requires logs that capture allow and deny decisions. |
| AC-6 — Least Privilege | The question is about limiting an agent to only the access each call needs. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | MCP and internal API access by agents hinges on authenticating the calling non-human principal. | |
| Recommendation — Log each agent request with principal, action, resource, and decision context. Constrain the agent to the minimum permissions needed for each task. Authenticate the calling agent or service before authorizing its request. | ||
Practitioner Guidance
What to prioritise: Treat request-by-request authorization as the default design, and reserve any broader trust only for narrowly defined, low-risk operations. If a call can reach production data, trigger side effects, or cross tenant or environment boundaries, it needs a fresh policy decision.
What to verify: Confirm that the policy engine sees the current principal, the exact target, and the intended action before the request executes, and that the log trail can explain both allows and denies. If any of those elements is missing, the control is not yet trustworthy enough for delegated agent use.
Common mistake: Teams often secure the initial login and then assume the rest of the session is safe. For agents, that shortcut is usually where the exposure starts, because the dangerous event is rarely the login itself, it is the later tool call.
Practitioner takeaway: The goal is not to eliminate agent autonomy, but to make every meaningful action individually accountable, narrowly authorised, and reversible when the agent’s behaviour stops matching its intended role.