Should organisations treat MCP as a security control or a transport standard?

Why This Matters for Security Teams

MCP is often introduced as a clean integration layer, but security teams should be careful not to mistake transport for control. A protocol that forwards prompts, tool requests, and responses does not by itself decide whether an agent should act, what it may access, or how long credentials should remain usable. That distinction matters because autonomous agents do not behave like static applications. Their tool use changes with context, and their failure modes often show up as overreach rather than obvious compromise.

The practical risk is that organisations deploy an MCP server and assume the governance problem is solved. In reality, the control plane still has to enforce scope, mediation, logging, and revocation at request time. NHI Management Group has highlighted similar visibility gaps in its The State of Non-Human Identity Security research, where lack of rotation, monitoring, and over-privilege repeatedly surfaced as root causes. The same pattern appears in agentic systems, only faster.

OWASP’s OWASP Agentic AI Top 10 treats this as an application security problem with identity consequences, not a transport-only issue. In practice, many security teams encounter MCP risk only after an agent has already chained tools, expanded scope, or exposed credentials, rather than through intentional policy design.

How It Works in Practice

The safest way to think about MCP is as the pipe, not the policy. The transport can standardise how an agent reaches tools, but the security value comes from what sits alongside it: workload identity, runtime authorisation, secret mediation, and audit. For autonomous workloads, the identity primitive should be the workload itself, not a reusable human-style account. That means cryptographic proof of what the agent is, paired with short-lived access that is issued only for the task at hand.

In practice, that often means combining MCP with just-in-time credential release, short TTL secrets, and real-time policy evaluation. Current guidance suggests evaluating each tool call against context such as task intent, data sensitivity, chain-of-tool risk, and environmental trust. Standards work in this area is still evolving, but policy-as-code patterns such as OPA or Cedar are often used to enforce decisions at request time rather than through pre-defined static roles.

• Use MCP to structure requests, not to assume trust.
• Bind agent sessions to workload identity such as SPIFFE or OIDC-backed service identities.
• Issue ephemeral credentials per action, then revoke them automatically when the task completes.
• Log tool calls, policy decisions, and secret release events as separate audit signals.

NHI Management Group’s Ultimate Guide to NHI frames this as an identity lifecycle problem, not simply an integration problem, which is the right lens for agents that can pivot across tools. The same concern appears in the OWASP Top 10 for Agentic Applications 2026, where uncontrolled tool use and weak authorization are treated as core risk patterns. These controls tend to break down when MCP is deployed behind legacy service accounts because the agent inherits broad standing privilege and the runtime cannot distinguish one request from the next.

Common Variations and Edge Cases

Tighter MCP mediation often increases operational overhead, requiring organisations to balance stronger per-call control against latency, integration complexity, and developer friction. That tradeoff is real, especially in fast-moving agentic environments where teams want quick tool onboarding. There is no universal standard for this yet, so current best practice is to keep transport, authorization, and audit layers explicit rather than collapsing them into one protocol assumption.

One edge case is internal-only MCP deployment. Some teams treat an internal network boundary as sufficient, but autonomous agents can still misroute requests, chain tools, or misuse broadly scoped credentials inside the perimeter. Another edge case is multi-agent orchestration, where one agent delegates to another and identity context gets blurred. In those environments, the runtime needs to preserve provenance across hops, or the audit trail becomes too weak to support investigation.

This is why the distinction between transport standard and security control matters. MCP can support security architecture, but it is not a control unless it enforces policy and credential release at runtime. The emerging guidance in OWASP Agentic Applications Top 10 and the NHI security research above points to the same conclusion: treat MCP as an enabling layer, then layer on least privilege, short-lived secrets, and verifiable auditability.

Related resources from NHI Mgmt Group

• What is MCP in the context of AI security?
• When should organisations treat an AI agent as a privileged system?
• Should organisations treat agent audit logs as a security control?
• When should organisations treat OAuth as a security control issue?