Security teams should govern them as privileged workloads, not as chat interfaces. Every tool call needs server-side authorization, schema validation, and a dedicated identity with minimal scope. If a model can influence code execution, treat that path like a production admin channel and apply least privilege, logging, and runtime isolation.
Why This Matters for Security Teams
LLMs that can call tools or run code stop behaving like passive interfaces and start behaving like privileged workloads. That changes the control problem completely: the risk is no longer only prompt quality, but whether the model can reach secrets, invoke APIs, trigger automation, or execute code outside the intended business process. Current guidance from OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward stronger runtime controls, but best practice is still evolving.
This is why teams should govern these systems as NHI workloads with separate identities, bounded scopes, and explicit approval paths. The same logic appears in NHIMG research on OWASP NHI Top 10, which treats agentic tool use as a governance problem, not a chatbot problem. If the model can decide when and how to act, then the security boundary must move from the prompt to the action.
In practice, many security teams discover that a harmless-looking assistant became an admin path only after it touched production data, called a sensitive API, or launched code in a way no one had explicitly reviewed.
How It Works in Practice
Governance starts by separating the model’s conversational surface from the execution plane. The model should never directly hold broad credentials. Instead, give it a dedicated workload identity, short-lived tokens, and server-side policy enforcement for every tool call. That means the application validates the request schema, checks intent, evaluates policy, and only then issues a narrowly scoped action. This is where CSA MAESTRO agentic AI threat modeling framework and NIST Cybersecurity Framework 2.0 are useful: both support structured control mapping around asset inventory, access restrictions, logging, and response.
Practically, teams should implement:
- Workload identity for the agent, so every execution request is tied to a cryptographic identity rather than a shared service account.
- Just-in-time credential provisioning, so secrets are minted per task and revoked on completion.
- Intent-based authorisation, so the request is evaluated against the task the agent is attempting, not a static role assigned months ago.
- Runtime isolation for code execution, including container boundaries, egress limits, and explicit human approval for high-risk actions.
- Full audit logging for tool calls, data access, and code paths, so incident responders can reconstruct what the agent actually did.
NHIMG reporting on the Analysis of Claude Code Security reinforces the point: code-capable assistants need controls that are closer to production change management than to ordinary conversational safety. The same logic applies to incidents like the AI LLM hijack breach, where compromised identity and overbroad execution paths turn an assistant into an attacker’s lever. These controls tend to break down when agents share long-lived secrets across environments because one compromise can persist across many tasks.
Common Variations and Edge Cases
Tighter control often increases latency and operational overhead, requiring organisations to balance fast agentic workflows against approval friction and secret-management complexity. There is no universal standard for this yet, especially where teams want high autonomy but still need strong separation of duties. In some environments, static RBAC is still acceptable for very low-risk read-only tools, but current guidance suggests moving to dynamic evaluation as soon as an agent can write, execute, or chain actions across systems.
One common edge case is multi-step orchestration. A model may be safe for a single tool call but unsafe when it can chain search, extract, transform, and execute in one run. Another is shared infrastructure: if several agents use the same backend queue or code runner, one weak path can expose all of them. This is where NHIMG coverage of the Top 10 NHI Issues is especially relevant, because credential reuse and poor lifecycle management remain recurring failures.
For governance decisions, the NIST AI 600-1 Generative AI Profile is helpful for mapping model behaviour to risk treatment, while NHIMG analysis of the Moltbook AI agent keys breach shows why static secrets and overexposed keys are especially dangerous in agentic systems. The practical rule is simple: if the model can influence state, treat that path as privileged, short-lived, and continuously re-authorised.
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 | Tool use and code execution are core agentic attack surfaces. |
| CSA MAESTRO | Provides threat modeling for autonomous agent workflows and controls. | |
| NIST AI RMF | GOVERN | Defines accountability for AI behavior and runtime risk ownership. |
Model agent execution paths and add policy, isolation, and approval gates around risky actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
