MCP authorization and AI agent access control in Curity examples

At a glance

What this is: Curity’s code examples focus on securing API access, OAuth flows, and plugin-based extensions, with MCP authorization and backend agent access standing out as the most relevant patterns for AI agent governance.

Why it matters: For IAM and NHI practitioners, the practical issue is how to bind autonomous agents to tightly scoped, reviewable access paths without treating them like ordinary users or static service accounts.

👉 Read Curity’s code examples for MCP authorization, SSO revocation, and OAuth flows

Context

Model Context Protocol gives AI agents a standard way to connect to tools and data sources, but that also makes it a governance problem as much as an integration problem. Once an agent can request tools, tokens, or approvals, IAM teams need to decide where authentication ends and authorization begins for each non-human identity.

Curity’s example set is less about a single product feature than about implementation patterns across OAuth, token exchange, step-up authentication, and plugin-based policy enforcement. That matters because NHI governance breaks down when agent access is assembled from loosely controlled building blocks rather than managed as a lifecycle.

The strongest signal here is that the examples are operational, not abstract. They reflect a common enterprise starting point: teams can wire agent access together, but they still need a repeatable way to control scope, approval, and revocation across those agent identities.

Key questions

Q: How should security teams govern AI agents that use MCP to access tools?

A: Security teams should treat MCP access as scoped, task-bound authorization rather than broad session trust. Each agent should have a defined purpose, a narrowly constrained token, and an approval path for sensitive actions. The control objective is to make tool use auditable and revocable, not merely authenticated.

Q: Why do AI agents create different IAM risks than ordinary service accounts?

A: AI agents can choose actions, chain requests, and escalate across tools in ways ordinary service accounts usually do not. That makes static permissions, long-lived credentials, and weak approval boundaries more dangerous. Teams need policy, logging, and revocation designed around autonomous behaviour, not around fixed workloads.

Q: What breaks when agent access is handled only through login controls?

A: Login controls do not govern what happens after the agent is in the environment. Without downstream authorization, token scoping, and revocation, an authenticated agent can still overreach, reuse privileges, or continue acting after the original task is complete. The failure is usually blast radius, not authentication failure.

Q: How should organisations respond when privileged agent access must be revoked quickly?

A: They should be able to revoke the agent’s token, disable any related plugin path, and confirm that downstream sessions or delegated grants are also invalidated. The first priority is containment. The second is evidence, so the team can verify which actions were already taken and whether any scope persisted.

Technical breakdown

MCP authorization for AI agents

An OAuth-secured MCP server places authorization in front of tool access rather than assuming an agent that is authenticated should also be trusted to act broadly. That distinction matters because MCP is designed to connect agents to tools and data sources, which means every connection can become an access boundary. In practice, the authorization model needs to account for the agent, the human approving the action, the target tool, and the lifetime of the token or session. Without that structure, agents inherit permissions that were meant for a narrower workflow and become harder to audit after the fact.

Practical implication: Treat every MCP connection as a governed access path, not a generic integration.

Step-up authentication and controlled delegation

Step-up authentication is the pattern of requiring stronger verification before a sensitive action is allowed, such as a delegated agent request that exceeds its normal scope. In an NHI context, that means the control is not just for humans at login time. It can also be used to gate privileged agent actions, token issuance, or access to higher-risk APIs. The architectural point is simple: autonomous software can be authenticated once, but authorization must still be reevaluated when the request changes in sensitivity, context, or impact. That is where many agent workflows need an explicit trust boundary.

Practical implication: Use step-up controls when an agent crosses from routine retrieval into privileged execution.

Plugin-based identity and authorization extension

Plugins extend the identity server by inserting custom logic into login, token issuance, or SSO revocation flows. That flexibility is useful when an environment must support unusual identity proofing methods, external IdPs, or agent-specific policy checks. The risk is that extension points can also become hidden control logic if they are not documented, tested, and tied to ownership. For NHI governance, the technical question is whether custom logic preserves least privilege and revocation guarantees or quietly creates exceptions that survive longer than intended.

Practical implication: Review every plugin path for privilege creep, hidden exceptions, and revocation gaps.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP authorization is becoming a first-class NHI governance problem. When agents connect through MCP, the security question shifts from whether the agent can authenticate to whether each tool invocation is properly authorized. That changes the control surface from single login events to ongoing, task-scoped access decisions. Practitioners should treat MCP as an identity-bound execution channel and govern it accordingly.

Ephemeral agent access does not remove trust debt. Short-lived tokens and step-up checks reduce exposure windows, but they do not solve the underlying problem of who approved the action, what scope was granted, and how that decision is later revoked or reviewed. The named concept here is an ephemeral credential trust debt: every temporary grant still creates accountability and audit obligations. Teams should design for traceability, not just short lifetime.

Customization points are where identity controls become brittle. Plugin architectures are often necessary, but they also create a place where policy logic can drift away from standard IAM governance. If revocation, token exchange, or authorization decisions depend on custom code, the organization inherits testing and assurance obligations that are easy to underweight. Practitioners should map every extension point to an explicit control owner and review cycle.

AI agents should be governed as distinct non-human identities, not as enhanced service accounts. The operational difference is that agents may branch, request new scopes, or chain actions across systems in ways static workloads do not. That makes conventional secrets handling necessary but insufficient. Security teams should build a separate governance model for agent identity, approval, and revocation.

Implementation examples are useful only if they become policy patterns. A code sample can show how to wire OAuth, MCP, or SSO revocation, but it does not by itself establish enterprise control. The real value is in converting those examples into reusable policy, logging, and review standards across environments. Practitioners should use the patterns, then harden them into repeatable identity governance.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably prove who or what still has access.
• For a broader view of identity failure patterns, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the 52 NHI Breaches Analysis.

What this signals

Ephemeral credential trust debt: short-lived access for agents reduces exposure, but the governance burden moves to approval, logging, and revocation. If those records are incomplete, the organisation gains speed without gaining control. The practical next step is to make every delegated agent action traceable to an owner and a decision record.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, the problem is not isolated misconfiguration. It is a structural mismatch between how IAM has historically modelled access and how autonomous agents consume it. Teams should expect stronger pressure for task-scoped authorisation and continuous review.

Practitioners should watch for policy sprawl inside plugins and custom authorization code, because that is where agent governance often drifts away from standard controls. The right response is to turn implementation patterns into repeatable policy, review, and offboarding workflows that survive beyond the original use case.

For practitioners

• Map every MCP tool path to an explicit authorization decision Document which requests require human approval, which can be delegated, and which must be denied by default. Tie each tool invocation to a scoped token, a named owner, and a revocation path so the access model stays reviewable.
• Apply step-up checks to high-risk agent actions Require stronger authentication or approval when an agent requests privileged APIs, cross-system writes, or changes to policy. Use the same escalation logic across environments so sensitive actions do not depend on ad hoc implementation choices.
• Track plugin logic as part of the identity control plane Inventory every custom plugin that affects SSO, token issuance, or revocation, then assign control ownership and test cases. Treat custom code as security logic, not as application convenience, because hidden exceptions are a common governance failure mode.
• Separate agent identities from human session assumptions Do not reuse human-centric session lifetime, approval, or audit patterns for autonomous agents. Give each agent a defined purpose, a narrow scope, and an explicit offboarding process when the workflow changes or is retired.

Key takeaways

• MCP changes the governance question from whether an agent is authenticated to whether each tool action is properly authorised.
• Agent access introduces a new class of NHI risk because autonomy, delegation, and privilege scope can expand faster than standard IAM reviews.
• The practical control response is task-scoped access, explicit approval for sensitive actions, and fast revocation tied to ownership.

Key terms

• Model Context Protocol: An open protocol that lets AI agents connect to tools and data sources through a standard interface. In security terms, it creates a new authorization boundary because every tool connection can carry delegated access, scoped tokens, and audit requirements that need explicit governance.
• Non-Human Identity: A digital identity used by software rather than a person, including service accounts, API keys, tokens, certificates, workloads, bots, and AI agents. NHI governance focuses on lifecycle, privilege, rotation, and revocation because these identities can act without human presence and often outnumber users.
• Step-up Authentication: A control that requires stronger verification before a higher-risk action is allowed. For NHIs and AI agents, it is not just a login pattern. It can also be used to gate privileged API calls, token issuance, or delegated execution when the request crosses a sensitivity threshold.
• Plugin-based Extension: A software design pattern that lets custom logic be added to identity or authorization flows without changing the core platform. It is useful for specialised identity cases, but it also creates governance risk if the added logic becomes undocumented, inconsistent, or difficult to revoke and test.

Deepen your knowledge

MCP authorization, delegated agent access, and step-up controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance around autonomous tooling and identity-aware APIs, it is worth exploring.

This post draws on content published by Curity: code examples for securing API access, OAuth flows, MCP authorization, and identity server plugins. Read the original.