Security teams should apply policy-based controls across every execution path, not just MCP traffic. Use allowlists, role or group based access, and human approval for higher risk actions. The goal is to govern what an agent can do, where it can act, and which identities are trusted, while keeping audit trails complete enough for review and compliance.
Why This Matters for Security Teams
AI agents can act across MCP servers, command lines, skills, and generated code in a single workflow, which means the real control problem is not one protocol or one tool. Security teams that only inspect MCP traffic miss actions executed through CLIs, local scripts, or code the agent generates on the fly. That creates uneven enforcement, weak auditability, and a false sense of containment.
The risk is already visible in current research. NHIMG’s The State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, while the NIST AI Risk Management Framework stresses that AI governance must address the full lifecycle of system behavior, not just a single control point. In practice, many security teams encounter risky agent actions only after a tool call, shell command, or generated script has already crossed the boundary.
How It Works in Practice
Governance should follow the action, not the interface. For AI agents, that means treating MCP calls, CLI execution, skill invocation, and generated code as equivalent policy enforcement points. The policy layer should decide whether the action is allowed based on the request context, the agent identity, the target system, data sensitivity, and the risk level of the operation.
That usually requires four controls working together. First, use allowlists for tools, repositories, commands, and destinations so the agent cannot invent new paths to privilege. Second, bind permissions to role or group membership for baseline access, but do not rely on static RBAC alone for autonomous systems. Third, require human approval for sensitive actions such as destructive changes, credential use, data export, or privilege elevation. Fourth, keep immutable audit logs that capture the prompt, policy decision, execution path, and outcome.
- MCP should be governed as one path among many, not as the whole security model.
- Generated code needs the same review and execution controls as manually written scripts.
- CLI access should be mediated through scoped identities, not broad interactive shell trust.
- Skills should be treated as privileged actions with explicit authorization boundaries.
Current guidance suggests pairing policy-as-code with runtime evaluation so decisions can reflect live context rather than a predeclared list of safe operations. The OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework both reinforce that agent behaviour must be constrained at the point of action. NHIMG’s Analysis of Claude Code Security shows why generated code needs separate scrutiny, because code synthesis can convert an ordinary request into an execution path with broader privileges than the original intent.
These controls tend to break down in hybrid environments where one agent can reach SaaS tools, internal APIs, and local shells through loosely integrated connectors because the policy boundary becomes fragmented.
Common Variations and Edge Cases
Tighter action control often increases operational overhead, requiring organisations to balance autonomy against review burden. The right balance depends on whether the agent is assisting a human, running a bounded workflow, or operating with meaningful execution authority.
There is no universal standard for this yet, but current practice is converging on risk tiers. Low-risk read actions may be allowed with scoped identities and logging. Medium-risk actions may require context-aware policy checks and destination restrictions. High-risk actions, such as secrets access, production changes, and external communications, usually need approval and short-lived authorization.
Edge cases matter most when the agent chains actions across boundaries. A benign MCP request can become a CLI command, which triggers generated code, which then calls a skill that reaches a sensitive API. That is why governance must be end-to-end and identity-aware. The Moltbook AI agent keys breach and the Replit AI Tool Database Deletion illustrate how quickly tool access and generated actions can turn into unintended impact when permissions are too broad.
For teams building a control baseline, the practical rule is simple: govern the agent’s action, not just the channel it used. If the identity, intent, and approval state are not visible at the moment of execution, the control is incomplete.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agent tool abuse and unsafe actions are central to this governance question. |
| CSA MAESTRO | MAESTRO covers threat modeling for agent workflows across tools and execution paths. | |
| NIST AI RMF | GOVERN | AI RMF governance is needed to assign accountability for autonomous agent actions. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Scoped, short-lived identities are essential when agents act across multiple tools. |
| NIST Zero Trust (SP 800-207) | SA-4 | Zero trust supports continuous authorization for dynamic agent actions. |
Issue least-privilege identities per agent and rotate or revoke access after task completion.
Related resources from NHI Mgmt Group
- How should security teams enforce guardrails across AI gateways and agent actions without wiring each application separately?
- How should security teams govern agent configuration when configuration can execute code?
- How should security teams govern API keys used for generative AI access?
- How should security teams govern AI agent identities in MCP workflows?
