A delegated secret is a credential selected or provisioned for a specific request context after policy evaluation. Rather than exposing broad standing access, it scopes the secret to the approved user, agent, and tool path so the backing system can be reached with tighter control and clearer accountability.
Expanded Definition
A delegated secret is not just a short-lived credential. In NHI operations, it is a policy-selected secret that is issued or surfaced only after the system validates the request context, then binds that credential to a specific user, agent, tool, and scope. That distinction matters because the secret is not merely hidden from view; it is constrained by authorization intent and operational context. In practice, delegated secrets sit between identity policy and runtime execution, especially in workflows where an AI agent or automation needs temporary access to a backing service without inheriting broad standing privilege.
Definitions vary across vendors, but the core idea is consistent: the secret should exist only for the approved task path and should be traceable to the decision that allowed it. This aligns with the guidance in the OWASP Non-Human Identity Top 10, which treats NHI credential handling as a primary security control surface. The most common misapplication is treating a delegated secret like a reusable service credential, which occurs when policy checks happen once at issuance and are never re-evaluated against the actual tool path or session context.
Examples and Use Cases
Implementing delegated secrets rigorously often introduces orchestration overhead, requiring organisations to weigh faster automation against tighter policy enforcement and shorter credential lifetimes.
- An AI coding agent receives a secret for a single repository action, then the credential expires when the approved change window closes.
- A workflow engine requests a delegated API key after approval, instead of storing a long-term token in the pipeline.
- A support automation tool uses a scoped secret to query one production system, while access to adjacent systems remains denied.
- A zero-trust control plane issues a request-specific credential for a tool path, then logs the policy decision for later review.
These patterns are closely related to secret sprawl, where long-lived credentials accumulate across code, CI/CD, and support tooling. NHIMG highlights that 96% of organisations store secrets outside secrets managers in vulnerable locations, which makes delegated secrets attractive because they reduce the need for reusable embedded credentials. For broader incident context, see the Guide to the Secret Sprawl Challenge and the Reviewdog GitHub Action supply chain attack, both of which show how exposed credentials become a durable attack path. Delegated secrets are also discussed in the OWASP Non-Human Identity Top 10 as part of reducing exposed NHI credentials.
Why It Matters in NHI Security
Delegated secrets matter because they create accountability without forcing every workflow to inherit standing access. That is especially important in agentic systems, where tool calls can be chained quickly and a single overbroad credential can become a universal access token. When the secret is delegated per request context, security teams can align privilege with purpose, shorten exposure windows, and preserve auditability across user, agent, and service boundaries. This is one reason NHIMG reports that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, and why delegated secrets fit naturally into zero-standing-privilege design.
Misunderstanding this term often leads to hidden privilege inflation, where a supposedly temporary credential is reused across sessions, stored in logs, or passed between tools without fresh policy checks. That creates a gap between governance intent and actual runtime access. Organisational risk becomes visible only after a leaked token, a compromised pipeline, or an unexpected agent action exposes the backing system, at which point delegated secret handling becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST Zero Trust (SP 800-207), NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret handling and excessive exposure of NHI credentials. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust limits access to the exact request context and resource path. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access management requires access to be authorized before use. |
| NIST AI RMF | AI risk management calls for controlled access and traceable governance over agent actions. | |
| CSA MAESTRO | Agentic AI security emphasizes runtime policy enforcement for tool-bound credentials. |
Constrain agent tool access with delegated secrets that support accountability and human oversight.
