TL;DR: MCP security compliance is undermined by weak auditability, broad token-based access, unmonitored data sharing, and limited visibility into agent decisions, according to Akto. The governance gap is not just logging, but proving that AI-driven tool use stayed within policy, consent, and data-handling boundaries.
At a glance
What this is: Akto argues that MCP security compliance breaks down where AI integrations lack auditability, consent controls and least-privilege access.
Why it matters: This matters because MCP turns AI assistants into governed access paths, so IAM, data protection and compliance teams need evidence that tool use, data sharing and agent actions stayed within policy.
Context
MCP sits at the junction of AI orchestration, tool access and data governance. The problem is not that AI systems can call tools, but that many deployments cannot explain, constrain or prove what those calls were allowed to do, which leaves access governance weaker than the integration layer suggests.
That creates a genuine identity and compliance problem for AI programmes. When broad tokens, weak logging and persistent context are used to connect agents to internal and third-party systems, the control boundary shifts from authentication to ongoing authorisation, data handling and audit evidence.
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 do MCP deployments increase identity and access risk?
A: MCP increases risk because it connects untrusted model output to real systems that can act on it. That creates new paths for token exposure, overbroad authorization, rogue endpoints, and confused deputy behaviour. The issue is not AI novelty, but the expansion of machine-to-machine trust at runtime.
Q: How can security teams tell whether MCP logging is good enough?
A: Logs are strong enough only if they show the request intent, the policy decision, and the exact context or action returned. If investigators cannot reconstruct those three steps, the server is not providing meaningful audit evidence. In practice, good logging should support recertification, incident review, and misuse detection without inference.
A: Security teams should treat MCP as a controlled interface, not a blanket trust layer. Limit each tool to a narrow function, scope access to the smallest practical project or repository set, and require tokens with explicit authorization. The goal is to let AI systems retrieve needed context while preserving least privilege, auditability, and clear boundaries around security data.
Technical breakdown
Why MCP turns access into a governance problem
MCP lets models and agents interact with external systems through tools, APIs and data sources. That is operationally useful, but it also means the security question moves beyond connectivity and into authorisation, consent and traceability. A token can prove that a session was allowed to start, yet still fail to show whether a tool call was appropriate, data-minimised or policy-compliant. In practice, the risk is not just unauthorised access. It is authorised access used in ways the organisation cannot easily reconstruct after the fact.
Practical implication: treat MCP sessions as governed access events, not simple integrations.
Why auditability fails when reasoning is not recorded
Many MCP deployments can log that an API or tool was invoked, but not why it was invoked or which decision path led there. That gap matters because compliance regimes and internal controls increasingly depend on explainability, traceability and reviewable evidence. Without decision context, teams can see activity but cannot assess intent, necessity or proportionality. The result is a control that records motion but not accountability, which is weak protection for regulated data and high-value workflows.
Practical implication: require decision-level logging where agents can touch sensitive data or regulated workflows.
How broad tokens undermine least privilege in AI integrations
The article's strongest governance warning is about access scope. When MCP relies on broad credentials instead of role-bounded permissions, the agent inherits more authority than the task needs. That creates a machine-identity problem similar to overprivileged service accounts in IAM: access becomes reusable, opaque and hard to constrain by purpose. In an AI setting, the danger is amplified because the agent may combine data access, tool execution and third-party sharing inside one flow, which makes over-privilege both a security and a compliance issue.
Practical implication: replace broad tokens with task-scoped permissions and explicit tool boundaries.
Threat narrative
Attacker objective: The objective is not always direct exfiltration; in many cases the failure is governance collapse, where the organisation cannot prove what the agent accessed, why it acted or whether it stayed compliant.
- Entry occurs when an AI assistant or agent connects to multiple tools and data sources through MCP using broad access tokens or credentials.
- Credential and permission abuse follows when the agent can invoke tools beyond the user's explicit approval and carry context across workflows.
- Impact appears as unmonitored data sharing, weak audit evidence and an inability to prove that regulated data stayed within policy boundaries.
Breaches seen in the wild
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
- SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
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
Auditability is now an access control problem, not just a logging problem. MCP environments that cannot explain why an agent called a tool have already lost part of the governance chain. Security teams need proof that each action was justified, scoped and reviewable, especially where regulated data or third-party services are involved. The practitioner conclusion is simple: if the decision path is invisible, compliance is already incomplete.
Broad tokens are the machine-identity equivalent of standing privilege. The article exposes a familiar IAM failure pattern in a new setting, where access is durable, reusable and wider than the task demands. That combination defeats least privilege because the agent can keep acting across tools and workflows without fresh governance checks. The practitioner conclusion is to govern MCP permissions as ephemeral, task-scoped identity rather than persistent access.
MCP security compliance is really data-flow governance for agentic systems. The article is right to connect consent, sharing and auditability, because the real control failure is not only the agent's authentication but the lack of enforceable boundaries on where data can move. This is where identity, privacy and compliance converge: if the organisation cannot bind tool use to purpose and policy, it cannot credibly claim controlled AI adoption. The practitioner conclusion is to align MCP oversight with both access governance and data protection controls.
Shadow MCP is likely to become the next governance blind spot. As AI teams add tools quickly, undocumented connectors and unmanaged agent flows will appear faster than review processes can track them. That creates the same class of problem seen in shadow IT, but with autonomous or semi-autonomous decisioning layered on top. The practitioner conclusion is to inventory MCP endpoints and agent connections before they become unreviewable production pathways.
Agentic AI compliance will increasingly depend on identity evidence, not policy statements. Regulators and auditors will care less about whether an organisation says it has controls and more about whether it can show who or what was allowed to act, on which data, and under what constraints. That makes MCP governance an evidence problem as much as a security problem. The practitioner conclusion is to design for demonstrable control, not assumed compliance.
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.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Guide
What this signals
Task-scoped identity will become the defining control pattern for MCP governance. The old model of authenticating an integration once and trusting the session no longer fits agentic workflows that can decide, chain tools and carry context. Security teams should expect access reviews to move from static entitlements toward issuance-time controls, with MCP inventories becoming part of the identity estate.
Consent and authorisation will be judged together in agentic AI programmes. If an assistant can move data or invoke tools beyond the user's explicit approval, the organisation has a governance defect even if the authentication is technically valid. That pushes AI programmes toward tighter policy binding, clearer purpose limitation and evidence that every sensitive flow was intentional.
Shadow MCP: the unmanaged connector problem is now an identity problem. Undocumented agents, hidden connectors and broad machine credentials can expand faster than governance can track them, which means inventory and ownership have to be treated as operational controls, not documentation tasks.
For practitioners
- Inventory MCP endpoints and agent connections Map every MCP server, tool, connector and downstream data source in use, including shadow deployments and third-party integrations. Build the inventory around ownership, data sensitivity, and the identities or tokens used to authenticate each path.
- Replace broad tokens with task-scoped permissions Bind agent permissions to narrowly defined workflows, short-lived sessions and explicit tool boundaries so an MCP integration cannot reuse access across unrelated actions or data sets.
- Require decision-level audit logging Log the tool invoked, the data touched, the policy context, and the outcome for every agent action that can affect regulated or sensitive information. Store logs in a format that supports correlation and review.
- Apply redaction before storage or sharing Mask authentication tokens, credentials, PII and other regulated content before logs, dashboards or transcripts leave the originating system. Treat output handling as a control point, not a formatting step.
- Review third-party tool trust before connection Assess the security and privacy posture of external APIs and services before allowing agents to reach them, and keep that review tied to data classification and contractual accountability.
Key takeaways
- MCP security compliance fails when organisations can authenticate an agent but cannot prove what that agent was allowed to do with tools, data and third-party services.
- The main governance gap is evidence. Broad credentials, weak logging and persistent context make it hard to demonstrate policy compliance after the fact.
- Teams should govern MCP as an identity and data-flow problem, with task-scoped permissions, decision-level logging and tighter control of external tool access.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Broad MCP tokens and weak session boundaries create insecure machine authentication paths. |
| NHI-05 — Overprivileged NHI | The article centers on broad access tokens and permissions that exceed task need. | |
| NHI-08 — Environment Isolation | Context and data can persist across workflows and users unless environments are isolated. | |
| Recommendation — Harden MCP authentication so each tool call is bound to a narrowly scoped, verifiable identity. Reduce MCP permissions to the minimum task scope and remove reusable standing access. Segregate agent workflows and data contexts so MCP sessions cannot leak across boundaries. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token scope and lifecycle are central to MCP access governance. |
| Recommendation — Manage MCP credentials as short-lived authenticators with strict issuance, rotation and revocation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about whether AI access stays within authorised bounds. |
| Recommendation — Review MCP entitlements continuously and align each connector to explicit authorised purpose. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Overbroad tokens and shared context can enable credential abuse and movement across tools. |
| Recommendation — Map MCP token misuse to credential access and lateral movement to prioritise detection coverage. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is about proving AI actions stayed within policy and accountability boundaries. |
| Recommendation — Establish AI governance controls that require traceable approval, oversight and evidence for MCP actions. | ||
Key terms
- MCP Security: MCP security is the set of controls that protect Model Context Protocol connections between agents, tools, and data sources. It covers connector permissions, secret handling, and policy enforcement because the protocol can become a direct path from agent intent to enterprise action.
- Decision-level Audit Logging: A logging model that records not just that access happened, but why a specific access request was approved or denied. For healthcare AI, it must capture the request, policy version, context, and outcome so auditors can reconstruct the control decision later.
- Task-scoped Permission: Task-scoped permission is access granted only for a specific job, action, or workflow step. It limits what a user, service, or agent can do to the minimum needed for that task, often with time and context boundaries. In identity systems, it reduces standing access and narrows misuse if credentials are exposed.
- Shadow MCP: Shadow MCP is an unauthorized or ungoverned use of the Model Context Protocol inside an organization. It appears when AI agents, scripts, or tools connect to data or actions through MCP servers without security review, inventory, policy control, or monitoring. This creates hidden access paths, data exposure, and weak accountability.
Deepen your knowledge
NHI Mgmt Group's NHI Foundation Level course covers NHI governance, agentic AI identity and machine identity security, the industry's only accredited NHI security programme. It helps practitioners translate identity controls into programmes that can withstand audit, operational scrutiny and real-world AI adoption.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org