MCP and API security are converging faster than enterprise controls

At a glance

What this is: This conference recap argues that MCP is rapidly becoming a central design concern for API security, because it changes how agents, tools, and APIs connect and authorize each other.

Why it matters: IAM and NHI practitioners need to understand MCP because it extends identity and access decisions into agent-driven workflows, where conventional API controls may not capture tool-level risk.

👉 Read Curity's recap of Platform Summit, MCP, and API security takeaways

Context

Model Context Protocol changes the API security conversation because it turns an AI agent into an active client that can request tools and data sources, not just consume content. That shifts the governance problem from static API access to dynamically delegated authority, which is where IAM and NHI controls tend to become inconsistent. In this context, MCP is not just another integration pattern. It is a new way of distributing access across systems that were often designed with human operators in mind.

The article’s conference setting shows that practitioners are already treating MCP as a live architectural issue rather than a speculative trend. For IAM teams, the practical question is whether authorization, secret handling, and workload identity can keep pace when agents sit between users and APIs. That is a typical starting position for the market: interest is high, but operational discipline is still uneven.

Key questions

Q: How should security teams govern AI agents that call multiple APIs through MCP?

A: Treat the agent as a non-human identity with its own scopes, audit trail, and revocation path. Do not rely on the initiating user’s session to define downstream authority. Each tool call should be authorized and logged separately so the agent cannot accumulate privilege silently across APIs.

Q: What is the difference between API authentication and API authorization in MCP environments?

A: Authentication proves which client or agent is talking, while authorization defines what that entity may do once connected. In MCP environments, that distinction matters more because the server can mediate access to multiple tools. Strong authentication without strict authorization still leaves room for privilege expansion.

Q: Why do AI agents create new identity risks for API security teams?

A: AI agents can act autonomously, chain requests, and carry credentials farther than a human user normally would. That creates identity blast radius when tokens, scopes, or delegated permissions are too broad. The main risk is not the agent itself, but the trust the organisation places in its execution path.

Q: Should organisations replace symmetric JWT signing in high-risk API flows?

A: Yes, where possible. Symmetric signing makes verification depend on a shared secret, which increases exposure if that secret leaks or is reused. Asymmetric signing better separates issuance from verification and reduces the chance that one compromised key can invalidate trust across many services.

Technical breakdown

How MCP changes API authorization boundaries

Model Context Protocol creates a new trust boundary because an MCP server acts as an API that can invoke other APIs and tools on behalf of a client. That means authorization must be evaluated at multiple layers: the client to MCP server relationship, the MCP server to downstream tool relationship, and the data access policy that governs each tool. Traditional API security often assumes a direct caller and a fixed audience. MCP adds mediated delegation, which can obscure who is actually exercising authority if token scope, audience, and consent are not tightly bound.

Practical implication: Practitioners should map every MCP hop to an explicit authorization decision and avoid assuming that one login event covers all downstream tool use.

Why agentic tool access behaves differently from standard OAuth flows

The article points to OAuth-protected MCP servers and tool consumption patterns, which makes identity proofing only part of the problem. In an agentic flow, the tool requester may be a software entity acting on behalf of a person, and that distinction matters for consent, auditing, and revocation. If the agent can chain requests across multiple APIs, then access becomes a composition problem, not a single-token problem. This is where NHI governance starts to overlap with runtime authorization and workload identity.

Practical implication: Security teams should treat each agent as a non-human identity with bounded purpose, and they should verify what the agent can do after authentication, not only before it.

Why weak JWT signing remains a fast path to API compromise

The post cites a demonstration showing that weak symmetric JWT signing can be broken in seconds. The underlying issue is not JWT itself, but poor key choice and poor cryptographic separation between issuance and verification. Symmetric signing creates a shared-secret dependency that expands blast radius if the secret leaks or is reused. In API and MCP ecosystems, that is especially dangerous because a compromised signing key can validate both user-facing and agent-facing tokens, undermining trust across multiple services.

Practical implication: Use asymmetric signing for tokens wherever possible and review any system that still relies on shared secrets for high-value authorization decisions.

Threat narrative

Attacker objective: The attacker aims to impersonate trusted callers and gain durable access to APIs or agent-connected tools without legitimate authorization.

1. Entry occurs when an attacker obtains a weakly protected shared secret or other signing material used to validate JWTs in API flows.
2. Escalation follows when the attacker forges accepted tokens and extends access into downstream APIs or tool endpoints.
3. Impact is broad authorization bypass across workloads and agent-driven services that trust the forged tokens.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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 is becoming an identity governance problem before it becomes a protocol standardisation problem. The security discussion around MCP is already shifting from interoperability to authority. Once an agent can call tools through a server, access decisions no longer live only at the application edge. Practitioners should treat MCP as a governance boundary, not just an integration layer.

Agent-mediated access creates a new identity blast radius. An agent that can chain calls across APIs can carry privileges farther than the initiating user intended. That turns token scope, audience control, and revocation speed into first-order risks. The correct control objective is not only authentication, but containment of what the agent can do next.

Ephemeral trust is still trust, and it must be engineered explicitly. The article’s emphasis on modern API authorization patterns shows that many teams are still improvising delegation rules as agentic use cases expand. Ephemeral credential trust debt: the gap between short-lived credentials and the long-lived assumptions systems make about them. Practitioners should model that debt before scaling MCP into production.

Weak token design remains one of the clearest ways to collapse an API trust model. The JWT example in the post is a reminder that cryptographic convenience can become an identity failure when shared secrets are used broadly. NHI governance should require cryptographic choices that reduce shared responsibility and simplify revocation. Teams should make token design part of the security architecture review, not an implementation afterthought.

Conference anecdotes are now early warning signals for the NHI market. When MCP appears in almost every session, it signals that agentic access is no longer edge-case experimentation. That does not mean enterprises should rush to adopt it everywhere. It does mean they need a governance model that can absorb new protocols without reintroducing standing privilege through the back door.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• MCP adoption should push teams to revisit Ultimate Guide to NHIs , 2025 Outlook and Predictions for the next wave of agentic identity risk.

What this signals

MCP adoption will pressure IAM teams to think less about singular logins and more about chained authority across agents, servers, and tools. That is a structural shift in governance, not a feature request. Organisations that can already enumerate service accounts and API consumers will be better positioned than those still relying on ad hoc token handling.

Identity blast radius: the practical metric that matters when software entities can call tools on a user’s behalf. With only 5.7% of organisations having full visibility into their service accounts, per the Ultimate Guide to NHIs, most teams will struggle to prove where an agent’s authority begins and ends. The result is that governance will have to move closer to runtime controls and away from periodic review alone.

For practitioners

• Map MCP trust boundaries Document each point where an MCP client, server, or downstream API makes an independent authorization decision. Separate user authentication from agent tool authorization so you can see where privilege expands.
• Review token signing assumptions Inventory JWT and access token signing methods, then eliminate shared-secret patterns for high-value API paths. Prefer asymmetric key separation so verification does not depend on the same secret used to issue tokens.
• Define agent-specific scopes Assign bounded scopes to AI agents and service accounts, and make revocation procedures explicit for each scope. Use short-lived credentials only when you can also prove rapid revocation and audit visibility.
• Add tool-level audit logging Capture which agent invoked which tool, under what identity, and with what downstream effect. That record is essential for incident response when an agent chains actions across multiple APIs.

Key takeaways

• MCP shifts API security from direct caller control to mediated authority across agents and tools.
• Weak token design and broad non-human privileges can turn agentic convenience into a large trust failure.
• IAM teams should model agent identity, tool scope, and revocation as a single governance problem.

Key terms

• Model Context Protocol: A protocol that lets AI agents connect to tools and data sources through a standard interface. In security terms, it expands the number of places where identity, consent, and authorization must be enforced, because the agent may act as an intermediary rather than a direct user.
• Agentic access: Access exercised by an autonomous software entity that can decide which tools to call and in what order. This differs from ordinary application access because the software can chain actions, reuse credentials, and extend authority beyond a single request if governance is weak.
• Identity blast radius: The amount of damage that can result when one identity is compromised or over-privileged. For non-human identities and agents, the blast radius grows when scopes are broad, revocation is slow, or a single token can unlock many downstream systems.
• Ephemeral credential trust debt: The hidden risk created when short-lived credentials are assumed to be safe without proper controls around scope, audit, and revocation. Short duration alone does not remove trust problems if the system cannot prove who used the credential, where, and for what.

Deepen your knowledge

MCP-driven API authorization and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agent-to-tool access, it is worth exploring.

This post draws on content published by Curity: Platform Summit, API security, and the rise of MCP. Read the original.