MCP is only one path an agent can use. Agents may also run CLIs, execute Skills, or generate code that calls APIs directly, which can bypass narrow controls if governance is tied only to one interface. Organisations need a control plane that spans all agent actions, with logging, access review, and clear approval boundaries.
Why This Matters for Security Teams
Approved MCP use does not make an enterprise AI agent governed. MCP is only one interface, while the agent’s real risk comes from its ability to choose other execution paths, chain tools, and act outside the assumptions embedded in a single approval workflow. That is why agent governance has to cover identity, tool access, data movement, and runtime decision-making together, not just one protocol.
Current guidance suggests treating agents as autonomous workloads with expanding blast radius, not as conventional users. The AI Agents: The New Attack Surface report from SailPoint notes that 80% of organisations report agent actions beyond intended scope, including unauthorised system access and sensitive data exposure. That aligns with the broader pattern documented in the 2024 ESG Report: Managing Non-Human Identities, where NHI compromise is already a routine enterprise issue rather than a corner case.
The core mistake is assuming an approval on one channel constrains the whole agent. In practice, many security teams discover the gap only after the agent has already exercised a second path that was never meant to be in scope.
How It Works in Practice
Governance for enterprise AI agents has to be evaluated at the action layer. An agent may start in MCP, then pivot to a CLI, call a Python library, invoke a skill, or generate code that reaches an API directly. If policy is attached only to the MCP entry point, the control fails as soon as the agent changes routes. The better pattern is to bind authorisation to the workload identity and evaluate each request at runtime.
That means using a control plane that can inspect intent, context, destination, and data sensitivity before allowing execution. In practice, teams are pairing workload identity with short-lived credentials, scoped tokens, and policy-as-code so that permissions are issued per task and revoked when the task ends. The relevant question is not whether MCP was approved, but whether the agent is allowed to perform this action, against this system, with this data, right now. The OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework both reinforce the need for runtime controls, traceability, and human-defined boundaries.
- Give the agent a workload identity, not a standing user account with broad entitlements.
- Issue just-in-time secrets with tight TTLs and automatic revocation on completion.
- Log every tool call, data access, and outbound action across MCP, CLI, code, and APIs.
- Review approvals at the policy layer, not only at the interface layer.
This guidance breaks down when agents operate across fragmented SaaS platforms and local developer tools, because the control plane cannot reliably see every execution path.
Common Variations and Edge Cases
Tighter runtime governance often increases operational overhead, requiring organisations to balance agent autonomy against auditability and change velocity. That tradeoff becomes more pronounced as teams move from simple copilots to multi-step agents that can browse, code, schedule, and transact. There is no universal standard for this yet, so best practice is evolving rather than settled.
Some environments may accept MCP-only approvals for low-risk read-only assistants, but that exception should be explicit and narrow. Once an agent can write data, trigger workflows, or handle secrets, MCP approval alone is not enough. The strongest implementations also incorporate findings from the OWASP Agentic AI Top 10, which highlights tool misuse, prompt injection, and excessive autonomy, and from the CSA MAESTRO agentic AI threat modeling framework, which emphasizes multi-control-plane governance.
Edge cases also matter: code-generating agents may appear safe until their output is executed; multi-agent systems can pass trust between agents faster than reviewers can follow; and long-lived credentials can silently outlast the approval that justified them. In practice, approved MCP access often becomes a false comfort when the agent’s real authority lives somewhere else.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A5 | Agent tool misuse and bypass paths are central to this question. |
| CSA MAESTRO | GOV-2 | MAESTRO addresses agent governance across multiple control planes. |
| NIST AI RMF | GOVERN | AI RMF governs accountability, traceability, and risk management for autonomous agents. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Static credentials and weak lifecycle control create NHI governance gaps. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is required when agents can reach multiple execution paths. |
Apply least privilege to all agent interfaces and review entitlements continuously.
Related resources from NHI Mgmt Group
- Why do AI agents create risk even when they stay within approved permissions?
- Why do AI coding agents create governance risk even when they improve productivity?
- Why do AI agents create governance risk even when they are meant to help testing?
- Why do AI coding agents create access and governance risk even when they are not autonomous?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
