Accountability sits with the team that owns the automation path, the secrets handling, and the endpoint control plane. For regulated or material trading workflows, that also means security, platform engineering, and application owners must agree who can create, store, rotate, and revoke bot credentials before any incident occurs.
Why This Matters for Security Teams
When developer tools expose non-human identities, accountability is not a theoretical governance question. It determines who approves creation, who owns the secret lifecycle, and who can stop reuse when a token leaks into logs, CI/CD, or an extension. That matters because non-human identities outnumber human identities by 25x to 50x in modern enterprises, and NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs.
In practice, accountability is usually split across platform engineering, security, and application owners, but the split only works if it is explicit before deployment. Otherwise, exposed developer tools become a blind spot where secrets are stored in code, rotated late, or never revoked. External guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access control and system ownership must be assigned, not implied.
Security teams get this wrong when they treat bot credentials like ordinary developer accounts instead of production identities with an attack path attached. The real failure is not just leakage, but the absence of a named owner who can respond within minutes, not days. In practice, many security teams discover that ownership was assumed only after a compromised token had already been reused in downstream tooling.
How It Works in Practice
Accountability for exposed NHIs should follow the control path, not the org chart. The team that owns the automation path owns the runtime behaviour. The team that owns secrets handling owns storage, rotation, and revocation mechanics. The endpoint or developer platform team owns the tools where credentials may surface, such as IDE plugins, shells, containers, and CI runners. That model aligns with the operational reality described in the State of Secrets in AppSec, where remediation lags and fragmented ownership are common.
In practice, mature organisations define a RACI that names who can:
- create bot credentials or service accounts
- approve scope and privilege before release
- store secrets only in approved vaults
- rotate and revoke on schedule or on incident
- review developer tooling that can surface tokens
For agentic or highly automated workflows, the accountability model gets stricter. Current guidance suggests pairing ownership with workload identity, so the automation is authenticated by what it is, not by a long-lived shared secret. That is where standards and implementation guidance such as SPIFFE overview and RFC 8693 Security Token Exchange become relevant: they support short-lived, task-bound credentials that can be issued, constrained, and revoked without waiting for a human ticket cycle.
Security and platform teams should also enforce request-time policy checks rather than assuming a static role is enough. For autonomous tools, least privilege is only meaningful if the policy engine can evaluate task context, destination, and tool scope at runtime. These controls tend to break down when developer tooling is decentralized across unmanaged extensions, personal laptops, and ad hoc CI pipelines because the credential trail becomes too fragmented to govern consistently.
Common Variations and Edge Cases
Tighter credential control often increases delivery friction, requiring organisations to balance fast developer workflows against auditability and revocation speed. That tradeoff is real, especially when teams rely on local automation, ephemeral test environments, or third-party plugins that need temporary access.
There is no universal standard for this yet, but current guidance suggests a few practical distinctions. If a tool merely stores a token, platform engineering may own the control plane. If the tool can mint, refresh, or proxy credentials, security and application owners share accountability because the blast radius is larger. If the tool is part of a regulated trading, healthcare, or payment workflow, the risk owner usually also needs formal sign-off on privilege scope and emergency revocation procedures.
Edge cases arise when vendors embed credentials into developer extensions or AI assistants. NHI Mgmt Group research on JetBrains Marketplace AI Plugin Campaign and Hard-Coded Secrets in VSCode Extensions shows why tool governance cannot be separated from identity governance. Emerging AI-assisted development also widens exposure, which is consistent with the concerns raised in Anthropic’s report on an AI-orchestrated cyber espionage campaign.
For this reason, the accountable owner should be the team that can actually stop the credential from being used again. If that team is unclear, the control has already failed.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Assigns ownership and lifecycle control for non-human identities. |
| OWASP Agentic AI Top 10 | A-04 | Covers agent autonomy and tool access governance. |
| CSA MAESTRO | ID-2 | Addresses identity, authorization, and governance for agentic systems. |
| NIST AI RMF | Supports accountability and governance for AI-enabled automation. | |
| NIST CSF 2.0 | PR.AC-1 | Requires identities and credentials to be managed under access control. |
Name a single accountable owner for each NHI and require approval for create, rotate, and revoke actions.
