Security teams should treat tool calls and generated code as separate execution modes with different control requirements. Direct calls are easier to log and approve, while generated code can compress many actions into one runtime block. Governance should define when each mode is allowed, what permissions it may inherit, and what evidence must be retained for review.
Why This Matters for Security Teams
MCP agents that can switch between tool calls and generated code create two very different risk surfaces under one identity. Tool calls are discrete, inspectable, and easier to constrain with policy. Generated code can bundle many actions into a single runtime block, hide intent until execution, and blur the line between approved assistance and uncontrolled automation. That is why governance has to be mode-aware, not just agent-aware.
The practical failure mode is that teams often apply one blanket permission model to both behaviours, then discover too late that the agent inherited broader access than intended. Current guidance suggests this should be handled as an agentic AI governance problem, not just an NHI problem, because the core issue is autonomous action selection at runtime. The AI Agents: The New Attack Surface report is a useful reminder that oversight gaps are common, with only 52% of companies able to track and audit what their agents access.
For control design, the relevant standards are moving in the same direction. The OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework both reinforce the need for context-aware governance rather than static trust. In practice, many security teams encounter the real problem only after an agent has already used generated code to chain tool calls in ways no approval workflow anticipated.
How It Works in Practice
Effective governance starts by separating execution modes in policy. Tool calls should be treated as narrow, auditable actions with explicit allowlists, request-level logging, and short-lived credentials. Generated code should be treated as higher-risk execution, even when it originates from the same agent, because it can compress multiple steps, create new runtime branches, and invoke libraries or commands that were never part of the original plan.
A practical control pattern is to require mode-specific authorization decisions at runtime. That means the policy engine evaluates not only the agent’s identity, but also the intent, target resource, data sensitivity, and whether the request is a direct tool invocation or generated code path. This is where policy-as-code, just-in-time privilege, and workload identity become important. Security teams should prefer ephemeral access tied to a single task, then revoke it immediately after completion. For implementation guidance, the CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix are both useful for mapping how agents can be induced to misuse tools or escalate through chained actions.
For control evidence, teams should retain the prompt, the selected mode, the policy decision, the exact tools invoked, the generated code artifact, and the post-execution result. That evidence supports both incident review and compliance traceability, especially where generated code may have performed actions that were not obvious from the initial request. NHIMG research on Analysis of Claude Code Security and the OWASP Agentic Applications Top 10 shows why code-producing agents need stronger containment than simple API orchestration.
These controls tend to break down in environments where agents can spawn nested interpreters, call external plugins, or run inside broad developer sandboxes because the execution boundary becomes too diffuse to enforce consistently.
Common Variations and Edge Cases
Tighter mode separation often increases operational friction, requiring organisations to balance developer velocity against containment. That tradeoff is real, especially when teams want the same agent to do both simple retrieval and complex code synthesis.
Best practice is evolving on whether generated code should be blocked by default or allowed with step-up controls. There is no universal standard for this yet. In lower-risk workflows, a policy may allow generated code only in a constrained sandbox with no network egress, no secret access, and no write permissions outside a scratch workspace. In higher-risk workflows, generated code may require human approval before execution, while tool calls remain automated within tightly scoped limits.
Another edge case is tool chaining across multiple systems. An agent may start with a harmless lookup, then use the resulting context to justify a privileged action elsewhere. That is why teams should not rely on static RBAC alone. The more defensible approach is to pair NIST AI Risk Management Framework governance with mode-specific guardrails and audit trails. Where MCP servers are involved, the The State of MCP Server Security 2025 report is especially relevant, because exposed secrets and weak tool scoping make both tool calls and generated code far harder to contain.
Security teams should also watch for environments where code generation is used to bypass API limitations. That pattern often looks efficient until an agent composes a runtime path that reaches data or systems the original workflow never intended to expose.
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 | A1 | Mode switching expands prompt injection and tool misuse risk in agents. |
| CSA MAESTRO | TM-2 | MAESTRO addresses agent tool abuse, chaining, and execution-path risk. |
| NIST AI RMF | GOVERN | AI RMF governance covers accountability for autonomous agent actions. |
Classify tool calls and generated code separately, then gate each with request-time policy and logging.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
