MCP is a standard way for AI agents to connect to tools and data sources through a client-server pattern. For security teams, the important point is that MCP does not remove identity controls. It still relies on secrets, scopes, and lifecycle management for every connected system.
Why MCP Matters for AI Security Teams
Model Context Protocol, or MCP, is not just a convenience layer for integrating tools. It creates a standardised path for an AI agent to reach data, actions, and downstream systems, which means it also becomes a security boundary. The key issue is that the agent remains an autonomous workload with tool access, so identity, secrets, scopes, and revocation still matter. That is why MCP should be treated as part of the control plane, not a bypass around it.
Security teams often underestimate how quickly an MCP connection can expand the agent’s effective reach. If the agent can query tickets, read repositories, invoke automation, or retrieve records, then the blast radius is determined by the permissions attached to that connection. The same concern appears in broader agentic guidance such as the OWASP Agentic Applications Top 10 and the external OWASP Agentic AI Top 10, both of which reinforce that tool access is a primary risk surface. In practice, many security teams encounter MCP problems only after an agent has already touched systems it was never meant to reach, rather than through intentional design.
How MCP Changes Identity, Secrets, and Access Control
In practice, MCP makes the identity question more concrete. Each server, connector, or tool endpoint needs an accountable identity model, and each agent action needs a way to prove what it is, what it is allowed to do, and for how long. Static API keys and broad service accounts are a poor fit for autonomous workloads because agents do not behave like humans with predictable sessions. They can chain tools, branch unexpectedly, and repeat actions at machine speed. That is why current guidance increasingly points toward workload identity, short-lived secrets, and runtime authorisation decisions rather than standing permissions.
A practical MCP security posture usually includes:
- Per-tool scopes that limit what a connector can do, even if the agent is compromised.
- Just-in-time credentials with short TTLs so access expires when the task ends.
- Workload identity for the agent and the MCP server, rather than shared credentials.
- Policy checks at request time, using context such as task intent, data sensitivity, and destination system.
- Logging and audit trails that show which agent requested which action and why.
The operational lesson is consistent with NHIMG’s Analysis of Claude Code Security and the Ultimate Guide to NHIs — What are Non-Human Identities: the identity boundary must follow the workload, not the user interface. The same control logic is reinforced by the external Anthropic Project Glasswing, which reflects the broader industry shift toward constrained agent behaviour and safer tool use. These controls tend to break down when teams reuse long-lived secrets across multiple MCP servers, because one leaked credential can expose every connected action path.
Common Variations and Edge Cases
Tighter MCP governance often increases integration overhead, requiring organisations to balance developer speed against stronger containment. That tradeoff becomes visible in mixed environments, where some agents are read-only assistants and others can execute workflows, create tickets, or trigger deployments. Best practice is evolving, but there is no universal standard for this yet: some teams use RBAC to define coarse entitlement sets, while others move toward intent-based authorisation that evaluates whether a specific agent action matches the current task and context.
Two edge cases deserve special attention. First, shared MCP servers can become implicit privilege aggregators if different agents use the same connector with different business purposes. Second, agents that operate across multiple systems may need separate trust boundaries even when the underlying model is the same. This is where the guidance in NHIMG research such as the DeepSeek breach is useful: once autonomous behaviour touches sensitive data or credentials, the failure mode is usually not a single bad request but a chain of acceptable actions that add up to excessive access. In those cases, MCP should be paired with ZTA thinking, explicit revocation, and continuous review of tool scopes rather than treated as a one-time integration standard.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | MCP tool access expands agent attack surface and privilege misuse. |
| CSA MAESTRO | M2 | Agentic orchestration needs governance across tools, identities, and secrets. |
| NIST AI RMF | GOVERN | MCP deployments require accountability for autonomous behaviour and risk. |
Assign clear owners for MCP-connected agents and monitor their actions under AI RMF governance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
