One year of MCP shows why agentic AI needs governance

At a glance

What this is: MCP became the interface layer for enterprise agentic AI, and the article argues that its rapid adoption turned it into a new governance and security problem.

Why it matters: IAM, PAM, and NHI teams need to treat MCP servers as privileged identity-bearing components because they now sit between agents, tools, data, and production systems.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Akto's analysis of how MCP became the foundation for enterprise agentic AI

Context

MCP, or Model Context Protocol, is the interface layer that lets AI agents call tools, access data, and trigger actions in a structured way. In practice, that makes MCP a governance problem as much as an engineering one, because the protocol now sits inside identity, access, and execution paths for agentic AI.

The article argues that MCP shifted from plumbing to attack surface in a single year. That matters for NHI governance because every MCP server behaves like a privileged workload identity with tool permissions, tokens, and audit expectations that traditional IAM teams have not always modelled explicitly.

For practitioners, the important question is not whether MCP is useful. It is whether enterprise controls can keep pace with the rate at which MCP servers are being created, connected, and trusted across developer environments, internal platforms, and production workflows.

Key questions

Q: How should security teams govern MCP in enterprise environments?

A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.

Q: Why do MCP-based agents create more risk than ordinary API integrations?

A: Because the agent is choosing actions, chaining tools, and preserving context across steps. Ordinary API controls assume predictable request patterns, while MCP can turn one legitimate session into a route for data exposure or privilege escalation. The risk increases when identity, context, and tool access are not governed together.

Q: What breaks when MCP tool permissions are scoped too broadly?

A: Broad scoping breaks least-privilege governance because the same workload can invoke tools and reach resources far beyond its actual role. In practice, that makes audits less reliable and magnifies the blast radius of any compromise or misconfiguration. The fix is narrower claim-based policy, not looser trust in the calling identity.

Q: Who should be accountable for risky MCP actions in enterprise environments?

A: Accountability should follow the full delegation chain, not just the token holder. That means the delegating human, the agent or client, the policy owner, and the approver must all be visible in the audit record when a high-impact action occurs. Without that chain, compliance and incident response lose the evidence needed to explain why the action happened.

Technical breakdown

Why MCP became the control plane for agentic workflows

MCP standardises how agents discover tools and data sources, which is why it quickly became the connective layer across IDEs, internal APIs, and enterprise systems. That standardisation reduces integration friction, but it also concentrates privilege. A single MCP server can expose read, write, and execution paths across multiple systems, effectively becoming a micro-application with delegated authority. Once that pattern spreads, security teams no longer manage isolated integrations. They manage a distributed interface layer that can mediate identity, policy, and action at runtime.

Practical implication: Treat MCP servers as governed access points, not convenience wrappers, and inventory them with the same discipline applied to privileged integrations.

Where MCP security fails in practice: tools, tokens, and trust

The most common failures are not exotic. They are overly broad tool definitions, hardcoded credentials, weak authentication between agents and servers, and insecure defaults that allow filesystem or command access without meaningful boundaries. In agentic systems, the danger is compounded because a tool that looks read-only at design time can still be used as a springboard for downstream actions. That is why MCP security is really about constraining execution paths, not just authenticating the caller. Without those boundaries, the protocol becomes an easy way to spread privilege across the enterprise.

Practical implication: Enforce tool-level scoping, token handling, and execution restrictions before MCP servers are allowed to connect to sensitive systems.

Action-level control is the missing layer for agentic AI

Traditional IAM answers who can sign in and what a principal can reach. MCP asks a deeper question: what exact action can the agent invoke, under what conditions, and with what auditability? That is closer to runtime authorisation than static access control. Enterprises that rely only on approval workflows or coarse roles will struggle because agentic systems create and consume permissions continuously. The governance model has to shift from one-time access assignment to persistent visibility over every tool call and every permission boundary.

Practical implication: Build policy and logging around individual tool actions, then require reviewable traces for every high-risk MCP interaction.

Threat narrative

Attacker objective: The objective is to turn a trusted agent interface into a path for unauthorised data access, command execution, or credential exposure.

1. Entry occurs when an MCP server is connected to an IDE, internal tool, or production workflow with broad permissions and weak boundary controls.
2. Escalation happens when hardcoded tokens, permissive tool definitions, or missing authentication let the server invoke actions beyond the intended scope.
3. Impact follows when the agent or server reads sensitive data, triggers production changes, or exposes credentials that enable broader compromise.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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 security is now an identity governance problem, not just a developer tooling issue. Once MCP becomes the standard interface for agentic workflows, the security question shifts from integration convenience to authority management. The server is no longer a passive connector. It becomes a delegated actor that can read, write, and execute across enterprise systems, which means IAM, PAM, and NHI governance now intersect at the protocol layer.

Privilege inside MCP is structurally different from privilege in classic service integrations. Traditional service accounts usually map to a bounded function, but MCP servers can expose many functions through one identity surface. That creates an interface privilege concentration problem, where one server can mediate multiple tool paths and multiple data domains. Practitioners should read that as a governance warning: the blast radius is no longer defined by the number of integrations, but by the breadth of tool authority behind each MCP endpoint.

Action-level authorisation is the control gap MCP exposes most clearly. Security teams can no longer stop at who created the server or whether a token exists. They have to care about which actions are allowed, which are blocked, and which are logged at runtime. That means MCP governance sits between NHI management and zero-trust execution policy. Organisations that do not map tool permissions to explicit business actions will find that agentic systems outpace their review cadence.

The security model for MCP will converge on governed NHI patterns, not bespoke AI exceptions. The article shows a common enterprise mistake: treating agent infrastructure as if it were fundamentally new when the real issue is delegated access at scale. The discipline is familiar. Scope tightly, audit continuously, and remove trust assumptions that no longer hold once tool use is machine-timed rather than human-timed. Practitioners should expect MCP to pull identity governance closer to runtime enforcement.

Named concept: interface privilege concentration is the condition where one MCP server accumulates too much effective authority because it can call many tools across many systems through a single trust boundary. That concentration matters because it hides real blast radius behind a simple integration pattern. The implication for practitioners is straightforward: every additional MCP server must be evaluated as a privileged surface, not as a low-risk plumbing component.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap is a strong reason to review OWASP Agentic Applications Top 10 alongside runtime governance for MCP servers.

What this signals

Interface privilege concentration: MCP adoption will push more organisations to manage one privileged interface layer rather than many isolated integrations. That changes programme design because security teams need discovery, scope control, and action logging at the server layer, not only at the application layer. The practical test is whether your IAM and PAM controls can describe every tool path an agent can take without relying on manual exceptions.

The next phase of MCP governance will look less like API management and more like runtime identity control for non-human actors. Teams should expect stronger pressure to correlate server ownership, token provenance, and tool usage into a single reviewable record. That is where internal policy and external frameworks begin to converge, especially as agentic workflows spread beyond engineering into business operations.

For practitioners

• Inventory every MCP server and owner Create a current register of all MCP servers, the systems they reach, the teams that created them, and the identities they depend on. Separate approved servers from ad hoc deployments so you can spot unmanaged privilege quickly.
• Scope every tool to a named business action Replace broad tool permissions with explicit action boundaries that reflect what the tool should do in production, not what it could do in theory. Review any server that exposes write or command execution paths first.
• Remove hardcoded secrets from MCP configurations Scan server configs, local development environments, and CI pipelines for embedded tokens, then rotate and replace them with managed secrets or workload identity patterns. Treat exposed credentials as an access path, not a hygiene issue.
• Log and review every high-risk tool call Require session traces for tool invocations that touch sensitive data, production systems, or credential stores. Use those traces to prove what the agent did, who approved it, and whether the action stayed inside policy.

Key takeaways

• MCP has become a privileged interface layer, which makes it an identity and governance issue as much as a developer productivity issue.
• Broad tool permissions, hardcoded secrets, and weak authentication are the main failure modes that turn MCP convenience into attack surface.
• Practitioners should treat MCP servers like governed non-human identities with explicit action boundaries, logging, and ownership.

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.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Sequence-Level Authorisation: Sequence-level authorisation is control over the full chain of actions an autonomous agent can take, not just the permissions on each individual request. It matters because an agent can combine several valid calls into an outcome that no single policy check would flag.
• Interface Privilege Concentration: A condition where one integration layer accumulates too much effective authority across many systems and tools. In MCP deployments, this increases blast radius because a single trusted server can mediate multiple sensitive actions, making ownership and policy enforcement harder.

What's in the full article

Akto's full blog covers the operational detail this post intentionally leaves for the source:

• Specific examples of MCP server deployment patterns across IDEs, internal platforms, and CI/CD workflows
• The article's own breakdown of how developers and security teams split on governance versus enablement
• Akto's description of its MCP Security category and how it frames discovery, permissions, and oversight
• Additional references to related resources on MCP governance, attack matrices, and AI agent security

👉 Akto's full post covers the adoption timeline, security reality check, and governance needs in more detail

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 or identity security programme, it is worth exploring.