Governance breaks when the organisation assumes access happens through a stable, inspectable human workflow. MCP-connected agents can retrieve data and trigger tool calls across many systems in one session, so blind spots emerge in discovery, classification, and audit. If policy, logging, and inspection are not agent-aware, the organisation cannot prove what was accessed or why.
Why This Matters for Security Teams
MCP changes the failure mode. Instead of a single human session with a known scope, an agent can chain prompts, tools, and data sources inside one workflow, which makes access reviews, logging, and classification far less reliable. That is why current guidance from the OWASP Top 10 for Agentic Applications 2026 treats agent tool abuse and indirect prompt injection as governance problems, not just application bugs.
The practical risk is not only exfiltration. Once an MCP-connected agent can reach multiple systems, a weak policy boundary can let one tool call become many: read a document, pull secrets, open a ticket, send a message, or trigger an admin action. That breaks assumptions behind RBAC, because the question is no longer “who logged in,” but “what autonomous workload was allowed to do this at this moment.” NHI Management Group’s analysis of OWASP Agentic Applications Top 10 shows how quickly agent behaviour becomes cross-system once tool permissions are too broad. In practice, many security teams discover this only after an agent has already performed an out-of-scope action, not during design review.
How It Works in Practice
Strong governance for MCP starts by treating the agent as a workload with its own identity, not as a user impersonator. That means runtime authorisation, short-lived credentials, and policy decisions that evaluate the task, the target system, and the context of the request. Static entitlements are too blunt when the agent’s sequence of actions is not known in advance. For that reason, best practice is evolving toward intent-based controls, ephemeral tokens, and workload identity patterns such as SPIFFE or OIDC-backed service identities, aligned with the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework.
In operational terms, teams should:
- Scope each MCP server to the minimum tool set the agent genuinely needs.
- Issue just-in-time credentials with short TTLs, then revoke them automatically after task completion.
- Log tool invocations, upstream prompts, policy decisions, and downstream side effects in a way that supports audit.
- Inspect data flow for secrets, sensitive records, and cross-domain transfers before the agent can forward content elsewhere.
- Apply policy-as-code so permissions are evaluated at request time, not fixed at deployment time.
This matters because MCP configurations already concentrate risk. NHI Management Group’s review of The State of MCP Server Security 2025 found that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows how often the control plane itself becomes the weak point. These controls tend to break down in highly federated environments where MCP servers are owned by different teams and policy enforcement is inconsistent between platforms.
Common Variations and Edge Cases
Tighter MCP governance often increases latency, operational overhead, and integration complexity, so organisations have to balance faster agent execution against tighter control boundaries. That tradeoff becomes visible when teams want broad tool access for productivity but still need provable oversight for compliance and incident response.
One common edge case is delegated access. An agent may need to act on behalf of a user, but that does not mean it should inherit the user’s full standing privilege. Current guidance suggests using constrained delegation with per-task approval, not long-lived impersonation tokens, although there is no universal standard for this yet. Another edge case is observability. If logs capture only the final tool call and not the chain of reasoning or intermediate actions, the organisation may still fail audit even when permissions were technically correct.
Vendor and platform differences also matter. Some MCP deployments support fine-grained tool permissions, while others expose broad server-level trust, which creates uneven risk across the estate. For that reason, NHI Management Group recommends pairing policy enforcement with research such as AI Agents: The New Attack Surface report and implementation lessons from CoPhish OAuth Token Theft via Copilot Studio and Amazon Q AI Coding Agent Compromised. The guidance breaks down most sharply when an agent can reach legacy systems that lack request-level authorization or modern audit hooks.
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 | A1 | Covers agent tool abuse and authorization failures in MCP workflows. |
| CSA MAESTRO | T1 | Addresses threat modeling for autonomous agent tool chains and trust boundaries. |
| NIST AI RMF | GOVERN | Requires accountability and oversight for AI system behaviour. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Relevant because MCP often exposes or mismanages secrets in configs. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control is central to MCP governance. |
Apply least privilege to each agent task and validate entitlements regularly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org