MCP identity and consent controls for agentic systems

At a glance

What this is: MCP is a protocol for context-aware agent access, and the key finding is that identity and consent must be explicit because agents can choose tools and actions at runtime.

Why it matters: It matters because IAM, PAM, and NHI programmes need to govern delegated machine action, not just authenticate a session or issue a token.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read PermitIO's guide to MCP identity, consent, and agent security

Context

MCP security is really an identity governance problem for agentic systems. The protocol gives AI agents structured context, but that context can change what the agent can see, infer, and do, which means authentication alone is not enough to control runtime behaviour.

For IAM and NHI programmes, the practical issue is delegation: who authorised the agent, what was consented to, which tools were exposed, and how those decisions are audited and revoked. Once agents can select tools at runtime, the programme has to govern action, not just access.

This is a typical failure pattern for early agent deployments. Teams start by treating MCP as a better integration layer, then discover that the real risk is uncontrolled machine decision-making inside the access path.

Key questions

Q: How should security teams govern MCP access for AI agents?

A: Treat MCP access as delegated machine authority, not a normal application login. Give each agent a distinct identity, scope its consent to specific tools and downstream services, and enforce policy at a middleware boundary so the system can inspect context before actions execute.

Q: Why do MCP-based agents increase identity governance risk?

A: Because the agent can select tools and chain actions at runtime, which means authority is no longer fixed at issuance. Traditional IAM assumes a stable entitlement set, but MCP lets context change behaviour, so the real risk is authority drift across the session.

Q: What do security teams get wrong about OAuth in agentic systems?

A: They treat OAuth as if it fully represents delegation. In MCP, OAuth may authenticate access, but it does not by itself express what the agent may do, under which conditions, or how consent is revoked across tool and service boundaries.

Q: Who should be accountable when an MCP agent misuses delegated access?

A: Accountability should sit with the identity and governance chain that authorised the delegation, not with an abstract model or shared token. The organisation must be able to show who granted scope, what the agent could reach, and where revocation was enforced.

Technical breakdown

Agent identity in MCP sessions

MCP introduces a layered identity model because the agent, the delegator, the MCP server, and upstream tools all need to be distinguished. If those identities collapse into a single token or shared credential, audit trails become meaningless and authorisation becomes ambiguous. The article correctly treats agent identity as distinct from user login, which aligns with NHI governance rather than human SSO design. In practice, this means the runtime must preserve who initiated the action, who delegated it, and which service executed it.

Practical implication: issue distinct identities for agents and map every action back to the delegated authority that allowed it.

Consent, delegation, and contextual scope

MCP consent is not a one-time OAuth approval. It is a bounded delegation relationship that should describe what the agent may do, under what conditions, and with which downstream services. Because the context payload can influence behaviour, scope is not just a permissions list, it is also an execution boundary. That makes consent revocation, traceability, and policy evaluation part of the control plane, not post-incident cleanup. The important shift is from static grant to governed delegation.

Practical implication: model consent as revocable delegated authority with explicit scope, not as a generic login grant.

Middleware as the policy boundary

The article’s middleware layer is the right architectural answer because MCP implementations themselves often lack a reliable native policy surface. A middleware boundary can authenticate identities, inspect tool exposure, enforce policy, log decisions, and block dangerous tool use before execution. That is especially important when remote servers, chained tools, or inconsistent client behaviour make direct enforcement hard. In identity terms, middleware becomes the place where intent, permission, and action are reconciled.

Practical implication: place enforcement between the agent and the MCP server so policy can evaluate context before tools execute.

Threat narrative

Attacker objective: The objective is to manipulate agent behaviour so delegated access is used to reach systems, data, or actions beyond the delegator’s intended scope.

1. Entry begins when an agent is granted delegated access to an MCP server and receives contextual tool definitions from the server.
2. Escalation occurs when context, prompt content, or tool chaining changes the agent’s behaviour and expands what it can attempt within the delegated scope.
3. Impact follows when the agent performs actions against upstream services that exceed the original intent of the delegation relationship.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Context-aware delegation is the new identity boundary for agentic systems. MCP does not fail because it is too powerful. It fails when organisations treat the agent as a passive API caller instead of an actor whose runtime choices alter the security boundary. That pushes identity teams to govern delegation relationships, tool exposure, and revocation with the same seriousness they apply to privileged machine accounts.

Consent in MCP is really controlled delegation, not authentication. The article’s strongest point is that login and consent are separate controls, and collapsing them destroys accountability. That maps directly to OWASP-NHI and ZT-NIST-207 thinking: access must be explicit, scoped, and inspectable at the moment of action. Practitioners should treat consent as the control plane for agent behaviour, not a checkbox on the way in.

Permissioning static credentials into dynamic agent behaviour creates policy drift. Once an agent can choose tools and chain actions based on context, a token no longer expresses the full authority picture. The governance problem is not just overprivilege, but authority that changes shape after issuance. The implication is that IAM teams must re-evaluate whether their current access model can describe runtime intent at all.

Agent identity and human identity cannot share the same accountability model. Humans are auditable through intent, approval, and post hoc review. Agents are auditable only if the system preserves delegated scope, context, and execution provenance at runtime. That difference means conventional recertification and access review processes are insufficient unless they are redesigned for machine action traces.

Identity blast radius becomes the decisive metric in MCP deployments. When a single agent can touch multiple tools and upstream services, the blast radius is defined by delegated reach, not by the number of tokens issued. NHI governance should focus on how far a compromised or misdirected agent can move through the tool graph. Practitioners should measure and limit that blast radius before production rollout.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A separate finding from our research shows that only 5.7% of organisations have full visibility into their service accounts, which is why delegated access paths are still so hard to govern.
• For a broader control view, compare that with the Ultimate Guide to NHIs, which maps rotation, offboarding, and privilege management across machine identities.

What this signals

Consent becomes the operational hinge for agentic access. As MCP-style systems spread, teams should expect pressure to move from static entitlement management toward runtime delegation controls that can inspect context before action. The governance model will increasingly resemble machine access administration with explicit revocation, provenance, and tool-scoped approval.

A useful signal for programme maturity is whether identity teams can answer three questions at runtime: what the agent can see, who delegated that reach, and how quickly that scope can be withdrawn. If they cannot, the organisation is relying on hope rather than enforceable policy.

The broader market signal is that AI agent security is converging with NHI governance and privileged access management. That makes tool exposure, delegation lifecycle, and runtime logging the practical controls to prioritise before agentic deployments scale beyond pilots.

For practitioners

• Assign unique identities to every agent Give each agent a distinct, traceable identity so every action can be tied back to a specific runtime actor and delegated authority. Avoid shared API keys or inherited user tokens where the audit trail would collapse.
• Separate login from delegation consent Model consent as a bounded approval that states which tools, actions, and downstream services an agent may use on behalf of a user. Make the grant revocable and inspectable across the full delegation chain.
• Insert a policy middleware boundary Place enforcement between the agent and the MCP server so you can evaluate tool exposure, log decisions, and block unsafe behaviour before any upstream service call is made.
• Audit tool chaining for unintended authority expansion Test whether a context change in one tool can alter behaviour in another tool chain, then remove any path where the agent can carry more authority than the delegator intended.
• Redesign reviews around runtime provenance Change access review and recertification workflows so they verify delegated scope, execution provenance, and revocation status instead of assuming a stable human-style entitlement record.

Key takeaways

• MCP turns agent access into a delegation problem, not just an authentication problem.
• Runtime context can change what an agent is authorised to do, which makes static token-based control insufficient.
• Security teams should enforce policy between the agent and the MCP server, where consent, scope, and action can still be checked.

Key terms

• MCP server: An MCP server is the component that exposes tools, resources, and context to an agent. In identity terms, it is not just an integration endpoint. It is a policy-sensitive control point that influences what the agent can know, choose, and do at runtime.
• Delegation consent: Delegation consent is the explicit permission a principal gives an agent to act on its behalf within defined limits. For agentic systems, it must describe scope, duration, and revocation conditions so that machine action remains attributable and constrained.
• Runtime provenance: Runtime provenance is the record of who delegated authority, what context the agent received, and which actions it executed. For agentic access, provenance is what makes audit and review possible after the fact, especially when the agent’s behaviour changes with context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by PermitIO: The Ultimate Guide to MCP Auth: Identity, Consent, and Agent Security. Read the original.