Handing an agent a secret means the credential is visible in the model’s context and can be exposed to memory or surrounding systems. Allowing indirect use means the agent can trigger approval and workflow execution without ever seeing the secret itself. That approach preserves user control while reducing the risk of credential leakage.
Why This Matters for Security Teams
The difference is not just about secrecy, but about control boundaries. If an AI agent can see a secret, that secret can be copied into prompts, memory, logs, debug output, or downstream tool calls. If the agent can only use the secret indirectly, the credential stays outside the model’s context and the workflow can enforce approval, scope, and revocation. That is the safer pattern for autonomous workloads because the agent’s behaviour is goal-driven, not fixed.
This distinction matters even more in agentic systems because the agent may chain tools, retry actions, or pivot into adjacent systems without predictable human-like restraint. Guidance from the OWASP Agentic AI Top 10 and NHIMG research on OWASP NHI Top 10 both point to the same operational problem: once a secret is visible to the agent, its exposure surface expands far beyond the original task. In the real world, that failure is usually discovered after a benign workflow has already leaked a credential into telemetry, memory, or an integration trace.
How It Works in Practice
Indirect use means the agent requests an action, while a trusted control layer performs the sensitive step on its behalf. The model may decide that it needs to send an email, open a ticket, query a database, or deploy a change, but it never receives the underlying API key, token, or certificate. Instead, the platform evaluates intent at runtime and either grants a narrow capability or routes the request through approval.
Common implementation patterns include:
- Workload identity for the agent, so the platform knows what the agent is before it authorises any action.
- Short-lived, just-in-time credentials issued per task, then revoked automatically after completion.
- Policy-as-code checks at request time, using context such as task type, data sensitivity, environment, and user approval.
- Secret brokers or vaults that execute actions server-side, so the secret never enters the model context.
That model aligns with the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize runtime governance, accountability, and bounded autonomy. NHIMG has also documented how exposed AI credentials are rapidly abused in practice in LLMjacking: How Attackers Hijack AI Using Compromised NHIs. The operational takeaway is simple: the agent should be able to ask for power, not hold the power itself.
These controls tend to break down when teams allow long-lived credentials into tool wrappers, because a single prompt path can then leak a reusable secret across many downstream systems.
Common Variations and Edge Cases
Tighter indirect access often increases orchestration overhead, requiring organisations to balance reduced leak risk against workflow latency, approval friction, and integration complexity.
There is no universal standard for this yet. Some environments allow an agent to hold a short-lived token for a narrowly scoped action, while others require the secret to remain entirely outside the agent and be used only by a backend service. The right choice depends on blast radius, regulatory exposure, and how much autonomy the workflow actually needs.
Edge cases appear when agents must operate across many tools, when human approval is unavailable, or when the action itself is high-risk and time-sensitive. In those cases, current guidance suggests combining indirect use with strict scope, short TTLs, and continuous policy evaluation rather than giving the model direct secret access. The OWASP Non-Human Identity Top 10 is especially relevant where workload credentials must be managed as first-class identities, not shared application secrets.
In practice, the safest pattern is to treat secrets as infrastructure assets, while the agent operates through delegated intent. That separation is what prevents a helpful automation from becoming a credential exfiltration path, as seen in NHIMG analysis such as The State of Secrets in AppSec.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO 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 | A2 | Direct secret exposure to agents is a core agentic authorization risk. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived secret handling and rotation are central to indirect secret use. |
| CSA MAESTRO | T2 | MAESTRO addresses runtime trust and bounded autonomy for agent workflows. |
| NIST AI RMF | AI RMF governs contextual risk and runtime controls for autonomous systems. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust supports verifying each agent action before any secret use is allowed. |
Apply AI RMF to define approval, monitoring, and escalation rules for secret-dependent agent actions.
Related resources from NHI Mgmt Group
- What is the difference between human identity governance and AI agent governance?
- What is the difference between governing human access and governing AI agent access?
- What is the difference between managed identities and hardcoded secrets for AI agents?
- What is the difference between workload identity and API keys for AI agents?
