Should teams use bearer tokens at all for autonomous agents?

Why Bearer Tokens Are a Poor Default for Autonomous Agents

bearer token were designed for portability, not for autonomous delegation. That is why they become risky when an agent can chain tools, retry actions, or pivot across services without a human in the loop. A token that works anywhere can also be replayed anywhere, which makes theft, forwarding, and accidental overuse much harder to contain. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward tighter runtime controls rather than standing authority.

NHIMG research shows why this matters operationally: the 2025 State of NHIs and Secrets in Cybersecurity found that 44% of NHI tokens are exposed in the wild, often in collaboration tools and code, and 91% of former employee tokens remain active after offboarding. That combination is especially dangerous for agents because they do not just hold secrets, they use them at machine speed and across systems. In practice, many security teams discover bearer-token abuse only after an agent has already reused the credential in a place no human intended.

What Safer Agent Authorization Looks Like in Practice

The safer pattern is not “no credentials,” but constrained, task-bound access. For autonomous workflows, that usually means a workload identity establishes what the agent is, then a short-lived credential is issued for a specific action, audience, and time window. Standards such as CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix reinforce the need to model tool chaining, lateral movement, and privilege escalation as runtime risks rather than static access-review issues.

In practice, teams reduce bearer-token risk by combining these controls:

• Use workload identity, such as SPIFFE or OIDC-backed service identity, so the system can authenticate the agent without making the token itself the identity.
• Exchange credentials at every hop, so each downstream call gets a fresh, narrowly scoped token instead of a reusable portable one.
• Bind tokens to a key or client context, so interception alone does not grant immediate replay value.
• Set short TTLs and automatic revocation on task completion, not calendar-based expiry measured in days or weeks.
• Evaluate policy at request time using policy-as-code, because pre-defined roles cannot predict every tool chain an autonomous system will attempt.

NHIMG has also documented how quickly secrets exposure spreads when AI systems are in the loop, including the Analysis of Claude Code Security, which underscores that AI-assisted workflows can increase secret leakage if controls are not built into the execution path. These controls tend to break down when agents must operate across legacy systems that only accept long-lived bearer tokens, because the workflow then forces portability back into the design.

Where Teams Still Need Bearer Tokens and the Tradeoffs to Watch

Tighter token handling often increases integration overhead, requiring organisations to balance security gains against platform compatibility and operational latency. There is no universal standard for this yet, so current guidance suggests treating bearer tokens as an exception only where a downstream service cannot support stronger binding or delegated identity. That exception should be narrow, documented, and surrounded by monitoring.

Common edge cases include third-party APIs that still only issue opaque bearer tokens, legacy SaaS connectors, and agent pipelines that span multiple trust domains. In those environments, a bearer token may be unavoidable, but it should still be exchanged, scoped, and revoked as quickly as possible. The strongest control is to prevent the agent from ever holding a general-purpose token that can move beyond the intended hop. Where that is impossible, teams should add explicit allowlists, anomaly detection, and hard caps on session duration. The practical lesson is consistent with NHIMG’s broader research on secret sprawl in the State of Secrets Sprawl 2026 and the Guide to the Secret Sprawl Challenge: exposure usually grows faster than remediation unless revocation is automatic and immediate.

Related resources from NHI Mgmt Group

• How should teams govern AI agents that use MCP?
• How should security teams govern AI agents that use OAuth access?
• How can organisations govern AI agents that use service accounts and tokens?
• How should security teams manage permissions for AI agents?