MCP is only one path an agent can use. Agents can also run commands, invoke Skills, and execute generated code that reaches APIs directly. If governance covers MCP alone, teams miss unmanaged action paths, lose visibility into privilege use, and create blind spots in audit, access review, and incident investigation.
Why This Matters for Security Teams
Focusing governance only on MCP traffic creates a false sense of control because MCP is just one interface, not the full action surface of an AI agent. Agents can still execute shell commands, call tools, generate code, and reach APIs directly, which means policy coverage limited to one protocol leaves unmanaged privilege paths outside audit and review. That gap matters most when an agent is goal-driven and can chain actions quickly.
NHIMG research on agentic risk shows the broader problem clearly: in AI Agents: The New Attack Surface report, SailPoint found that 80% of organisations report AI agents have already performed actions beyond their intended scope, while only 52% can track and audit the data those agents access. Current guidance from the OWASP Agentic AI Top 10 reinforces that the control problem is broader than one transport or one broker.
In practice, many security teams encounter unauthorised agent behaviour only after an incident review, rather than through intentional governance design.
How It Works in Practice
The practical mistake is treating MCP as the security boundary when it is only a message path. An agent may start with MCP, but it can also move through other execution paths such as terminal commands, generated scripts, browser actions, direct API calls, or embedded skills. If governance is attached only to MCP logs, the organisation sees one slice of activity and misses the rest of the decision chain.
Effective control needs to follow the agent’s identity and intent, not only the protocol. That is why modern guidance points toward workload identity, runtime authorisation, and ephemeral credentials. An agent should present a cryptographic workload identity, receive only the permissions needed for the current task, and lose those permissions when the task ends. This is materially different from assigning static roles and assuming the agent will behave like a human user with repeatable access patterns.
- Use runtime policy evaluation for each action, not a one-time approval of MCP access.
- Bind permissions to workload identity and task context, then issue short-lived credentials.
- Log every action path, including tool calls and code execution, not just MCP requests.
- Review privilege use at the level of task outcome, not protocol volume.
NHIMG’s OWASP NHI Top 10 and the NHIMG Analysis of Claude Code Security both illustrate why autonomous systems need controls that extend beyond a single integration layer. These controls tend to break down in developer environments where agents can generate and execute code locally because the execution path bypasses the very broker teams assume is the control point.
Common Variations and Edge Cases
Tighter protocol-level control often increases operational overhead, requiring organisations to balance simpler monitoring against broader coverage. That tradeoff becomes visible in environments where an agent uses multiple toolchains, because each new path needs its own policy enforcement, logging, and revocation logic.
There is no universal standard for this yet, but current guidance suggests that MCP should be treated as one governed channel among many. In highly regulated settings, teams may decide to restrict MCP heavily while separately controlling code execution and direct API access through the same identity and policy layer. In less mature environments, the immediate priority is usually inventory: identify every place an agent can act, not just every place it can talk.
This is also where breach patterns matter. NHIMG reporting such as Moltbook AI agent keys breach and the external CSA MAESTRO agentic AI threat modeling framework both point to the same operational lesson: if credentials, tool permissions, and runtime actions are not governed together, MCP visibility alone is insufficient.
Best practice is evolving, but the core rule is stable: govern the agent’s identity, the task it is trying to complete, and every way it can complete it.
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 | A2 | Covers agent misuse of tools and actions beyond a single protocol. |
| CSA MAESTRO | T4 | Threat modeling must include non-MCP execution paths and chained actions. |
| NIST AI RMF | GOVERN | Requires accountability and oversight for autonomous AI behaviour. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Static credentials and weak scoping create blind spots for agent access. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access must cover all agent execution channels. |
Map every agent action path and enforce policy across tools, code, and API execution.
Related resources from NHI Mgmt Group
- Why do MCP integrations create governance gaps when AI agents connect to repositories, APIs, and logs?
- Why do AI agents make non-human identity governance harder?
- Why do AI agents create new risk in non-human identity management?
- Why do AI agents create more risk when they reuse existing credentials?
