Security teams should place credentials in a separate execution layer, not in the model context, and bind every tool call to a distinct agent identity. The key controls are scoped consent, execution-time secret injection, and unified audit logging. That way the model can request actions without ever seeing the material that authorises them.
Why This Matters for Security Teams
AI agent tool calls are not like ordinary application requests. The model can chain actions, retry failures, or pivot to a new tool based on the response it just received. If credentials are present in the prompt or model context, they can be exposed through logs, prompt injection, or tool misuse. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 points toward separation of duties, runtime controls, and explicit governance rather than trusting the model with secrets.
For NHI security, the practical issue is not just where credentials live, but whether the agent can ever observe them. The safest pattern is to keep secrets in a separate execution layer, issue them only at tool-call time, and bind every action to a distinct workload identity. That aligns with the threat patterns documented in LLMjacking: How Attackers Hijack AI Using Compromised NHIs and NHIMG’s research on static vs dynamic secrets. In practice, many security teams discover credential exposure only after an agent has already reused the same token across multiple tools.
How It Works in Practice
The operating model is straightforward: the agent decides what it wants to do, but a separate control plane decides whether it may do it and injects the minimum secret needed for that one action. The model never receives the credential itself, only the result of the tool call. This is where runtime policy, workload identity, and just-in-time access converge.
A common implementation pattern uses a workload identity for the agent, such as an OIDC-based token or a SPIFFE/SPIRE identity, so each request is cryptographically tied to a specific agent instance or task. The request then passes through policy evaluation at execution time, not through a static IAM role defined months earlier. That means intent, context, target system, sensitivity, and time window can all factor into the decision. This is the direction reinforced by the CSA MAESTRO agentic AI threat modeling framework and NHIMG’s OWASP NHI Top 10.
- Bind each agent to a unique workload identity, not a shared service account.
- Keep credentials in an execution broker or vault, injected only at tool invocation.
- Issue short-lived secrets with tight scope and automatic revocation after completion.
- Log the agent identity, policy decision, tool target, and outcome in one audit trail.
- Block direct secret exposure in prompts, memory, and tool results.
This model works best when tool permissions are narrow and the execution layer can verify both the agent identity and the requested action in real time. These controls tend to break down when legacy systems require long-lived API keys or when the tool itself cannot support per-request authorization.
Common Variations and Edge Cases
Tighter credential isolation often increases orchestration overhead, requiring organisations to balance security against latency, developer friction, and integration complexity. That tradeoff is real, especially in multi-agent pipelines where several agents coordinate across shared tools and intermediate outputs.
There is no universal standard for this yet, so current guidance suggests using the least exposed pattern that still preserves operational reliability. For low-risk read-only tasks, teams may tolerate narrower scoped tokens with short TTLs. For write actions, sensitive data access, or infrastructure changes, best practice is evolving toward per-task consent, explicit policy checks, and revocable secrets. The NIST AI Risk Management Framework and NIST Cybersecurity Framework 2.0 both support this kind of governance-by-context rather than static entitlement alone.
Edge cases include agents that call external SaaS tools, agents operating in regulated environments, and systems that require human approval before credential release. In those cases, the decision point should move closer to execution, and the audit record should show who approved the action, which identity was used, and what secret was injected. The operational lesson from NHIMG’s 52 NHI Breaches Analysis is that static credentials fail fastest when they are reused across identities, tools, and environments.
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 | Covers agent prompt and tool abuse that exposes credentials. |
| CSA MAESTRO | MTR-3 | Addresses agent identity, policy enforcement, and tool-risk boundaries. |
| NIST AI RMF | Supports governance and runtime risk management for autonomous AI systems. |
Apply AI RMF to define ownership, monitor agent behavior, and control high-risk actions.
Related resources from NHI Mgmt Group
- How should security teams govern generative AI workloads without breaking existing IAM models?
- How should security teams govern API keys used for generative AI access?
- How should security teams govern agent tool calls in production?
- How should security teams govern AI gateway traffic that carries prompts and tool calls?
