MCP authorization and AI agent access control in Curity examples

At a glance

What this is: This is a set of Curity code examples showing how MCP authorization, backend agent access, and step-up authentication patterns constrain AI agents at the protocol and token level.

Why it matters: IAM and NHI teams need to treat AI agent access as delegated runtime authority, because login controls alone do not bound what an agent can do once tokens are issued.

Context

MCP authorization is a governance problem, not just an integration pattern. Once an AI agent can reach tools or APIs, the important question becomes which actions are allowed, under what approval conditions, and how those privileges are revoked or narrowed later.

These examples focus on protocol-level control: OAuth-secured MCP, backend authorization for agents, and step-up authentication where human approval is part of the access path. That matters because agentic access behaves more like delegated machine identity than like a normal interactive login session.

Key questions

Q: What breaks when AI agents use authorised tools for malicious activity?

A: Single-event detection breaks first, because each call appears legitimate in isolation. The real failure is that permissions, logs, and alerts are assessed separately, so the attack only becomes visible after the sequence has already crossed data, identity, and cloud boundaries. Defenders need behavioural correlation, not isolated event review.

Q: Why do AI agents need approval gates before token issuance?

A: Because approval only matters if it changes the access state. If the agent already holds a broad token, the approval is ceremonial. The useful pattern is to make policy, human review, and token issuance part of the same decision so the agent cannot act first and justify later.

Q: How do organisations know whether agent access is actually constrained?

A: Look for evidence that every sensitive action has a distinct authorization event, a narrow token audience, and a revocation path that ends access when the task ends. If the same credential can call multiple tools without reauthorisation, the control is too broad to be trusted.

Q: Should teams treat MCP access like normal user login flows?

A: No. MCP access is a delegated machine path, so the real control point is what the agent can reach after authentication. Teams should compare login assurance with post-login authorization, because the latter determines whether the agent can overreach across tools and APIs.

Technical breakdown

OAuth-secured MCP access as delegated machine identity

Model Context Protocol connects an agent to tools and data sources, but the identity question is still familiar: what token does the agent present, what audience can it reach, and what scope limits apply. When MCP is protected with OAuth, the access model shifts from a generic authenticated caller to a governed delegation path with explicit issuance, audience restriction, and revocation points. That matters because the tool surface is where overreach becomes operational, not at the login screen.

Practical implication: Treat every MCP server as a delegated access surface and define scopes, audiences, and revocation paths before exposing tools.

Backend agent authorisation and approval gates

Backend agent authorization pushes the decision point behind the UI, where policy can inspect the requested action, context, and target resource before the agent receives usable access. Human approval is then a control on delegation, not a decorative checkpoint. The technical issue is that agents can chain requests quickly, so authorization must be bound to the action being requested rather than to the fact that the agent is already logged in. This is where token exchange and policy enforcement become central.

Practical implication: Place authorization at the action boundary so policy can approve the request itself, not just the agent session.

Step-up authentication for high-risk agent actions

Step-up authentication adds an extra authentication event when the requested operation crosses a risk threshold, such as broader data access or a sensitive tool call. In agentic workflows, step-up is less about proving the human is present at login and more about reasserting approval before the agent expands its authority. The design challenge is to keep the user experience coherent while ensuring the agent does not inherit standing privilege for every subsequent call in the task chain.

Practical implication: Use step-up only for sensitive actions and tie the elevated approval to a narrowly scoped, time-limited token.

NHI Mgmt Group analysis

MCP authorization exposes the trust boundary that most AI deployments try to avoid naming. Once an agent is allowed to call tools, the security question stops being whether the user authenticated and becomes whether the delegated identity is constrained enough to remain safe. That is a classic NHI governance problem, because the agent is operating through issued credentials rather than human judgement. Practitioners should treat MCP as an access brokerage layer, not a convenience feature.

Human approval remains useful only when it gates a concrete privilege change. If approval happens before the agent receives a token, scope, or audience claim, it changes the authorization state. If it happens after the token already grants broad access, it is only ceremonial. The practical lesson is that approval must bind to the request, the resource, and the resulting token state, or the control does not actually limit agent behaviour.

Protocol-level scoping matters more than login hardening for agentic access. These examples show that the real control surface is token audience, scope, exchange path, and revocation discipline. That is why agent access governance converges on the same disciplines as NHI governance: narrow issuance, explicit offboarding, and proof that the credential cannot outlive the task.

Step-up authentication is not a substitute for least privilege in autonomous workflows. It can slow risky escalation, but it does not solve the underlying problem that an agent may keep asking for more access once the first request succeeds. The governance objective is to make privilege expansion observable and bounded, not merely to add another challenge screen.

Protocol-scoped delegation: AI agents should not be treated as ordinary authenticated users with broader APIs attached. The governing assumption is that access is bounded by token design, approval points, and revocation timing, and that assumption must be enforced at the protocol layer. Practitioners should redesign agent access around explicit delegation states rather than around login events.

From our research library:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
• Read next: OAuth 2.0 and OpenID Connect Guide for Identity Teams

What this signals

AI agent access programmes need to shift from identity proofing at the edge to delegation control in the middle of the transaction. When tokens, audiences, and scopes define what the agent can do, the governance model becomes closer to machine identity management than to user access management.

Protocol-scoped delegation: the useful control boundary is the credential that reaches the tool, not the login that started the session. That means access reviews alone will miss the real risk unless they can also inspect token issuance, token exchange, and revocation behaviour.

For practitioners

• Define MCP server scopes explicitly Map each tool to a narrow audience and permission set so the agent can only invoke the operations it actually needs. Avoid broad bearer tokens that collapse tool, resource, and task boundaries into one access grant.
• Require approval before token issuance Place human approval and policy checks before the agent receives a usable token or exchanged credential. That ensures the approval changes the effective access state rather than merely documenting it.
• Separate login from authorisation decisions Do not rely on the initial user sign-in to justify later tool calls by the agent. Re-evaluate each sensitive action at the point of execution so the access path remains auditable and bounded.
• Set revocation rules for delegated agent access Make it possible to invalidate the credential or exchanged token independently of the human session. Agent access should end when the task ends, not when the next login happens.

Key takeaways

• MCP and AI agent access become governable only when the credential, audience, and scope are constrained at the protocol layer.
• Human approval helps only when it changes the token or access state before the agent can act.
• Delegated agent access should end with the task, which makes revocation discipline as important as authentication.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.