Token governance should be shared, but not blurred. Engineering teams usually create and use the tokens, while security and identity teams should define policy, inventory requirements, and revocation standards. If ownership is unclear, tokens become orphaned, and orphaned tokens are exactly the objects attackers look for in automation-heavy environments.
Why This Matters for Security Teams
Token governance is not a documentation exercise. It is the control layer that determines whether API keys, OAuth grants, service account tokens, and other secrets can be issued, discovered, rotated, and revoked before they become standing access. When ownership is split without clear decision rights, teams typically optimise for delivery speed while nobody owns inventory, expiry, or emergency disablement. That gap is visible in incidents such as the Salesloft OAuth token breach, where token misuse became a direct path to data access.
Current guidance from NHI practitioners and frameworks such as the NIST Cybersecurity Framework 2.0 points to shared accountability, but shared does not mean ambiguous. The identity function should define the rules for issuance, lifecycle, and revocation standards, while engineering owns the systems that mint and use tokens. NHI research consistently shows why that separation matters: the State of Non-Human Identity Security found that only 1.5 out of 10 organisations are highly confident in securing NHIs. In practice, many security teams encounter orphaned tokens only after automation has already used them to move data or pivot into another system.
How It Works in Practice
The most effective operating model gives security and identity teams policy ownership, engineering teams implementation ownership, and platform owners operational accountability for the systems that issue tokens. That means one team defines what a valid token looks like, how long it may live, what it may access, and how revocation must occur. Another team integrates those rules into CI/CD, cloud platforms, application runtime, and agent workflows. This is consistent with the direction of the Ultimate Guide to NHIs lifecycle guidance, which treats lifecycle control as the core governance problem.
Practically, token governance should include:
- A complete inventory of issued tokens, service principals, OAuth grants, and machine credentials.
- Named owners for every token class, application, and secret store.
- Mandatory time-to-live rules, rotation cadence, and revocation triggers.
- Automated detection of unused, over-privileged, or orphaned tokens.
- Break-glass disablement procedures for incident response.
Implementation should align with zero trust principles and policy enforcement at request time, not just at provisioning time. For example, tokens used in automation-heavy pipelines should be bound to workload identity and evaluated against context such as source system, task type, and destination API. Research in the Guide to the Secret Sprawl Challenge shows why this matters: secrets spread fast across repositories, collaboration tools, and runtime systems, so governance must cover the full path, not only the vault. These controls tend to break down when tokens are created ad hoc by application teams in disconnected cloud accounts because no single system sees issuance, use, and revocation end to end.
Common Variations and Edge Cases
Tighter token governance often increases delivery friction, requiring organisations to balance developer speed against revocation certainty and auditability. There is no universal standard for ownership boundaries yet, so the right model depends on maturity, tooling, and whether tokens support human users, workloads, or autonomous agents.
For high-volume automation, the usual pattern is delegated ownership with central guardrails. Security sets standards, the platform team enforces them, and product teams request exceptions through a controlled process. For third-party integrations, ownership should extend beyond internal teams to the vendor relationship, because unused OAuth grants and stale API keys are a common blind spot. The 52 NHI Breaches Analysis shows that identity failures often begin with missing lifecycle control rather than sophisticated exploitation.
For agentic AI and autonomous systems, the bar is higher. Tokens should be short-lived, context-aware, and tied to workload identity rather than a static role that never changes. That approach is still evolving, but current guidance suggests that ownership should shift toward the team best able to answer three questions: who can issue the token, who can use it, and who can kill it immediately when behaviour changes.
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 address the attack and risk surface, while 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-03 | Directly covers token rotation and lifecycle governance for NHIs. |
| NIST CSF 2.0 | PR.AC-4 | Maps to management of access permissions and credentials. |
| NIST AI RMF | Governance is needed for AI and autonomous systems that use tokens dynamically. |
Assign clear owners for token issuance and rotation, then enforce short TTLs and automated revocation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
