They lose action-level governance. Token issuance shows that access was granted, but not whether the agent was allowed to use it for this specific resource, at this specific moment, under this specific task context. Without a runtime policy, audits become token logs rather than proof of controlled behaviour.
Why This Matters for Security Teams
oauth token issuance is often treated as proof that access control succeeded, but for autonomous systems and high-risk applications it is only the start of the trust chain. The failure mode is simple: a token can be valid while the action is still unsafe, out of scope, or no longer appropriate for the current task. That gap is where abuse, lateral movement, and data exposure happen.
This is especially visible in incidents like the Salesloft OAuth token breach and the CoPhish OAuth Token Theft via Copilot Studio, where the existence of a token did not mean the resulting behaviour was safe. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls still supports layered authorization and monitoring, but the practical lesson is that token issuance alone is not a decision point for runtime governance.
NHIMG research has repeatedly shown that credential and token exposure is common enough that organisations cannot rely on issuance as a meaningful stopping point; for example, the 2025 State of NHIs and Secrets in Cybersecurity reports that 44% of NHI tokens are exposed in the wild. In practice, many security teams discover misuse only after a token has already been exercised far beyond the original intent.
How It Works in Practice
The control gap appears when access is granted at authentication time, but no separate policy evaluates what the agent, workload, or integration is trying to do at the moment of use. A token can authenticate a client, yet a runtime decision still needs to answer whether this specific request should reach this specific resource under this task context. That is why action-level governance is emerging as the real control boundary for NHI and agentic workflows.
In practice, teams are moving toward three layers working together:
- Workload identity to prove what the caller is, often using OIDC-based service identity or SPIFFE-style cryptographic identity.
- JIT, short-lived credentials so the token’s lifetime matches the task and revokes quickly after completion.
- Real-time policy evaluation so each request is checked against context, purpose, resource sensitivity, and environment signals.
This aligns with evolving agentic guidance from OWASP and the broader shift toward policy-as-code patterns such as OPA or Cedar, where authorization is evaluated at request time instead of being assumed from prior issuance. It also fits the operational reality described in NHIMG research on the Guide to the Secret Sprawl Challenge, where leaked or duplicated secrets become persistent risk unless access is narrowed and short-lived.
For security operations, the key question changes from “Was a token issued?” to “Was this action permitted right now?” That means logging must include task context, policy decision outcomes, and revocation events, not just token minting and expiry. These controls tend to break down when legacy OAuth clients, broad refresh-token reuse, or service accounts with shared entitlements are embedded in high-throughput automation because the authorization decision becomes detached from the actual action.
Common Variations and Edge Cases
Tighter runtime authorization often increases integration overhead, requiring organisations to balance stronger task-level control against performance, developer friction, and legacy compatibility. That tradeoff is real, especially in environments that were built around long-lived OAuth grants and assume that possession of a token is sufficient proof of intent.
There is no universal standard for this yet. Current guidance suggests that high-risk workflows should use the narrowest feasible scopes, explicit context checks, and aggressive token rotation, while lower-risk internal automations may tolerate simpler policies if compensating monitoring is strong. The main exception is machine-to-machine workloads with stable, well-bounded behaviour; even there, token issuance should not be the final gate when data sensitivity or privilege level is high.
Edge cases show up most often in multi-tenant SaaS integrations, agentic AI tools, and delegated admin flows. In these environments, a token may be valid for a platform, but not for a specific tenant object, customer record, or downstream tool action. That is why many practitioners now treat OAuth as one control in a chain, not the chain itself. NHIMG’s analysis of the Dropbox Sign breach shows how quickly trust can fail once broad API access is assumed rather than continuously checked.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Focuses on NHI access boundaries beyond initial token issuance. |
| OWASP Agentic AI Top 10 | A-03 | Agentic systems need runtime checks, not one-time OAuth trust. |
| CSA MAESTRO | C1 | Covers governance for autonomous AI actions and delegated access. |
| NIST AI RMF | AI RMF addresses runtime risk management for dynamic AI behaviour. | |
| NIST Zero Trust (SP 800-207) | PA-3 | Zero Trust requires continuous verification, not token-only trust. |
Enforce action-level authorization for each agent tool call and resource access.
