TL;DR: MCP can connect AI agents to internal tools in a structured way, but Willow says most enterprises still treat it as a proof of concept because security review, governance, and integration work remain unresolved. The adoption gap shows that operational readiness, not protocol quality, determines whether MCP becomes practical.
At a glance
What this is: Willow argues that MCP is promising for AI-agent workflows, but most organisations remain blocked by security, governance, and integration overhead rather than protocol capability.
Why it matters: IAM and security teams need to treat MCP as an access-governance problem, because agent-to-tool connectivity changes who can act on systems, what gets audited, and how least privilege is enforced.
Context
MCP is a protocol that lets AI agents connect to internal tools and data sources through a structured interface instead of one-off integrations. The governance gap appears when those connections move from experimentation to production, because identity, authorisation, and audit expectations have to work at machine speed rather than human pace.
The article frames the central problem as adoption friction, but the deeper issue is that MCP expands the blast radius of each connected agent. Once a tool can read and write across tickets, code, alerts, and customer data, the organisation needs a defensible model for who or what is allowed to act. That is where most programmes stall.
Key questions
Q: What breaks when MCP agents are given broad permissions?
A: Broad permissions turn one compromised or manipulated agent into a wide-blast-radius identity. The agent can read, write, and trigger actions beyond the original workflow, which makes tool poisoning, credential theft, and accidental misuse far more damaging. Least privilege is the control that limits how far the delegation chain can spread.
Q: Why does MCP create security risk even when the protocol is well designed?
A: Because the risk comes from what connected agents can do once authorised. If an agent can read tickets, query databases, open pull requests, or update records, the organisation must control delegated rights, not just transport security. The protocol can be sound while the governance model remains too weak to contain misuse.
Q: When should organisations prioritise governance before broader MCP rollout?
A: They should do so before any production use that touches sensitive data, customer records, or write-capable tools. The moment an agent can change state, governance must define ownership, approval paths, revocation, and auditability. Without those controls, rollout expands risk faster than the business can absorb it.
Q: How do teams know whether MCP permissions are actually under control?
A: Look for separate read and write entitlements, explicit per-tool scoping, and complete logs for both permitted and denied actions. If tool access is inherited from a general user role without per-workflow limits, the control is probably too coarse to trust.
Technical breakdown
Why MCP changes the access-control problem
MCP standardises how agents reach tools, but the security question is not the protocol itself. It is how the agent authenticates, what scopes it receives, whether those scopes are reused across sessions, and how actions are attributed after the fact. In practice, MCP shifts the control point from isolated app integrations to an access plane for software actors. That makes authorisation, auditability, and least privilege the decisive design choices, especially when the same agent can both retrieve context and trigger actions. See the NHI Authentication Guide.
Practical implication: Treat every MCP connection as a governed identity path, not a convenience integration.
Why governance, not just engineering, becomes the bottleneck
The article highlights approvals, versioning, rollback, and ownership as blockers because MCP deployments behave like shared infrastructure, not point tools. Once multiple teams depend on the same servers and connectors, breakage becomes a change-management issue as much as an engineering one. That is why MCP adoption often stalls in pilot mode: the organisation has not defined who approves new servers, who owns failures, or how breaking changes are controlled across dependent teams.
Practical implication: Define ownership and change control before broadening MCP access.
How MCP turns agent actions into an audit and accountability problem
When an AI agent can create pull requests, query customer records, or update tickets, the key requirement is traceability. Without strong identity binding between the agent, its delegated rights, and each action it takes, audit logs become descriptive rather than accountable. That is especially important in mixed workflows where an agent helps a human but also initiates downstream tool use. The security model has to preserve attribution, scope, and revocation at the action layer, not just at initial login. See the MCP Security Guide.
Practical implication: Require action-level attribution for every agent-initiated tool call.
Threat narrative
Attacker objective: The objective is to use trusted agent connectivity to reach internal data and actions at a scale that bypasses normal human review.
- Entry occurs when an AI agent receives access to internal tools through MCP connectors and delegated credentials, allowing it to operate inside business systems.
- Escalation happens if the agent can reuse broad scopes across multiple tools or sessions, turning a single integration into a wider action surface.
- Impact follows when the agent makes unintended changes, exposes data, or amplifies a compromise across connected systems faster than a human reviewer can intervene.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP adoption is constrained less by protocol readiness than by identity governance maturity. The article shows that many teams can understand the integration pattern but cannot yet prove who may act, under what scope, and with what audit trail. That is a governance gap, not a technical novelty problem. The practical consequence is that MCP tends to move only as fast as the organisation can govern delegated machine action.
Actionable agent identity is the real control plane behind MCP. Once an agent can read, write, and route work across multiple systems, the access model must describe the agent as an operating identity, not a user surrogate. NHI authentication matters here because the weak point is not connectivity alone but how credentials, delegation, and revocation behave across the workflow. Practitioners should treat each agent as a governed principal with explicit lifecycle ownership.
Governance that assumes human-paced review will fail at MCP scale. Approval queues, manual exception handling, and after-the-fact audit are too slow once agents start taking routine actions directly. The article implicitly shows a control gap in which organisations want the outcome of automation without redesigning the decision rights around it. That gap will widen as more business functions attach agents to live systems.
Named concept: agent access governance gap. This is the mismatch between MCP's technical reach and the organisation's ability to govern delegated machine action consistently. The gap appears when teams can connect tools but cannot yet specify stable ownership, authorisation, rollback, and accountability across every agent action. Practitioners should recognise this as a programme design failure, not a product selection problem.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
MCP adoption will increasingly hinge on whether organisations can govern delegated machine action as a distinct identity class, not just as another integration pattern. The teams that move beyond pilots will be the ones that separate authentication, authorisation, and audit for agents from the controls they use for humans.
Agent access governance gap: the next phase of MCP maturity is not more connectors, but clearer authority over who can deploy them, what they can do, and how quickly they can be withdrawn when something changes. That will force IAM, platform, and security teams to coordinate more tightly around the agent lifecycle.
The adoption curve will likely split between organisations that can operationalise least privilege for agents and those that remain stuck in proof-of-concept mode. The difference will show up in how quickly teams can approve new use cases without weakening review and traceability.
For practitioners
- Map every MCP-connected agent to a named owner Assign a business and technical owner for each agent, then require that owner to approve scope changes, revocation, and exception handling.
- Enforce least-privilege scopes for tool access Limit each agent to the minimum set of tools, actions, and data domains needed for one workflow, and review those scopes on a fixed schedule.
- Separate pilot access from production access Keep experimental MCP servers and production connectors in different governance tracks so a proof of concept cannot inherit broad operational rights.
- Require action-level logging for agent operations Record which agent invoked which tool, on whose behalf, with which delegated permissions, so investigations can reconstruct decisions and outcomes.
- Build a rollback path before expanding adoption Document how to disable a connector, revoke tokens, and revert changes when an MCP integration behaves unexpectedly or breaks downstream workflows.
Key takeaways
- MCP adoption is being limited by governance and access-control maturity more than by the protocol itself.
- The core risk is not connectivity alone but the expansion of delegated machine action across production tools.
- Organisations that can define ownership, scope, and audit for agent actions will move faster without sacrificing control.
Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · OWASP Agentic Applications Top 10 · Smithery.ai MCP hosting breach 2025
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP access depends on how agents authenticate to internal tools and data sources. |
| NHI-05 — Overprivileged NHI | The article centres on whether agents receive excessive access across connected systems. | |
| NHI-07 — Long-Lived Secrets | MCP deployments often rely on credentials that can persist beyond a single task or session. | |
| Recommendation — Bind every MCP connector to explicit authentication and revoke credentials that outlive their intended workflow. Scope each MCP agent to the smallest set of tool rights and remove any unused write permissions. Replace persistent agent secrets with short-lived credentials and rotate any shared tokens immediately. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article concerns AI agents acting with delegated authority across multiple business tools. |
| Recommendation — Constrain agent privileges so each tool action is limited to the exact business function the workflow requires. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The central governance issue is who or what is authorised to act through MCP-connected agents. |
| Recommendation — Review agent entitlements regularly and remove any access that is not needed for current workflows. | ||
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.
- Vendor access governance: Vendor access governance is the set of policies and controls that define, limit, review, and revoke external user or system access. It focuses on lifecycle, scope, evidence, and accountability, so third-party identities do not become permanent or overly broad trust paths.
- Delegated Machine Action: Delegated machine action is work performed by an AI agent under authority inherited from a human or system sponsor. The identity remains non-human, but the accountability path still traces back to the original delegate. In practice, this makes runtime behaviour, not just issuance, the governance concern.
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.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org