Move those workflows away from long-lived bearer credentials and into short-lived, scoped tokens with clear ownership and fast revocation. Also assume any system that can install packages or run scripts can read local secrets, so package trust, endpoint hardening, and secret storage must be governed together.
Why This Matters for Security Teams
AI agents and developer tools do not just "use" secrets, they actively search, copy, chain, and reuse whatever is available locally. That changes the risk model from a credential-handling problem into an execution-control problem. Once a workstation, container, or CI runner can install packages or run scripts, local secrets should be treated as exposed unless strong boundaries exist. NHI governance has to cover trust in the tool, the endpoint, and the secret store together.
This is why static RBAC alone is not enough for autonomous workloads. Agents are goal-driven, so their access needs shift with the task, context, and time window. Current guidance from OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward runtime control, accountability, and continuous evaluation rather than assuming a fixed human-style permission model. NHIMG research also shows that AI-related credential leaks surged 81.5% year over year in 2025, which is a strong signal that agent workflows are already outpacing traditional secrets governance.
In practice, many security teams discover the problem only after an AI coding assistant, package install, or CI job has already exfiltrated a credential, rather than through intentional secret lifecycle design.
How It Works in Practice
The practical answer is to replace standing secrets with short-lived, narrowly scoped credentials issued at the moment of use. For agents, that usually means just-in-time access, workload identity, and policy checks at request time. A workload identity such as SPIFFE or an OIDC-backed token proves what the agent is, while the policy engine decides what it may do right now. That is a better fit than pre-assigned roles when the agent can change tools, plans, and destinations during execution.
Security teams should separate three decisions:
- Authentication: prove the agent or tool instance is the expected workload.
- Authorisation: evaluate intent, context, and risk before each sensitive action.
- Secret delivery: issue the minimum secret needed, with a short TTL and automatic revocation.
That model aligns with the direction of the CSA MAESTRO agentic AI threat modeling framework and the OWASP Non-Human Identity Top 10, which both emphasise machine identity, lifecycle control, and misuse prevention. NHIMG’s Guide to the Secret Sprawl Challenge is a useful reminder that leakage is often a process problem, not just a vault problem.
Operationally, that means blocking long-lived bearer tokens on developer laptops, stripping secrets from local files where possible, using brokers or secret managers with ephemeral leases, and applying endpoint hardening so package managers, build scripts, and browser extensions cannot trivially read the same secret namespace. Where possible, policy-as-code should evaluate the agent's intent before access is granted. These controls tend to break down when agents run inside flat CI/CD runners with broad network reach and shared filesystem mounts because a single compromise can expose every cached credential at once.
Common Variations and Edge Cases
Tighter secret controls often increase latency and operational overhead, so organisations have to balance speed against blast-radius reduction. That tradeoff matters most in developer experience, ephemeral test environments, and automated build systems where teams are tempted to cache credentials for convenience. Best practice is evolving here, and there is no universal standard for every tool chain yet.
In highly distributed environments, the edge cases usually involve local execution that is hard to govern centrally: offline developer tooling, self-hosted runners, package hooks, notebook environments, and agents that call other agents. In those settings, revocation alone is not enough if secrets were already copied into logs, caches, or prompt history. NHIMG research on Analysis of Claude Code Security shows why code-assisting systems deserve the same scrutiny as production workloads, and the OWASP NHI Top 10 reinforces that autonomous software should not be trusted with standing secrets by default.
Where agents must retain access across multiple steps, current guidance suggests using intent-based authorisation and rechecking policy at each sensitive transition. That is especially important when a tool can install dependencies, spawn shells, or move laterally across environments. In those cases, the safer pattern is to give the agent a fresh lease for each task and revoke it the moment the task ends, rather than trying to police a credential that should never have been persistent in the first place.
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 | Covers agent misuse and unsafe autonomy around sensitive actions. |
| CSA MAESTRO | N/A | Models identity, trust, and control for agentic workloads. |
| NIST AI RMF | Supports governance and accountability for AI-enabled decision making. |
Assign ownership, monitor behavior, and enforce continuous review for agent access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
