TL;DR: AI agents need credentials to act, but long-lived keys, shared service accounts, and user-session inheritance create overbroad access and weak auditability, according to WorkOS and GitGuardian research. The governance problem is not storage alone: identity controls built for stable, predictable software do not hold when an agent can choose tools and act at runtime.
NHIMG editorial — based on content published by WorkOS: How to manage API keys, tokens, and secrets for AI agents
By the numbers:
- 29 million new hardcoded secrets were found in, ound in public GitHub commits in 2025.
Questions worth separating out
Q: How should security teams manage credentials for AI agents without creating standing access?
A: Use short-lived, task-scoped credentials, keep downstream secrets server-side, and require approval before each session begins.
Q: Why do shared service accounts create problems for AI agent governance?
A: Shared service accounts collapse attribution, so you can see which account acted but not which agent or user caused the action.
Q: What breaks when AI agents inherit a user's active session?
A: The agent inherits permissions the task may never require, which expands access beyond the approved intent and weakens separation between human action and machine action.
Practitioner guidance
- Audit every agent-held credential path Map whether each agent currently uses environment variables, config files, shared service accounts, inherited user sessions, or managed OAuth flows, then classify the blast radius of each path.
- Move raw secrets out of agent reach Keep downstream credentials server-side and let the application or MCP layer retrieve them on demand, so the agent only receives a scoped token for the current task.
- Require approval-gated task sessions Make agent access expire at session end and require a fresh human approval before a new session can begin, especially where the agent can invoke external tools.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- A concrete implementation pattern for encrypted secrets storage, including envelope encryption and context-based segmentation.
- The OAuth connection flow details for keeping raw tokens out of agent memory and out of application code paths.
- The session-scoped authorization model for MCP-connected providers, including how access checks run on every invocation.
- Practical guidance on when to use BYOK, HSM-backed keys, or managed vault patterns in enterprise agent deployments.
👉 Read WorkOS's guide to managing API keys, tokens, and secrets for AI agents →
AI agent credentials and session scope: where current controls break?
Explore further
Long-lived credentials are a poor fit for autonomous agents because the access window outlives the task window. Traditional IAM assumes credentials persist long enough to be reviewed, rotated, or revoked after use. That assumption fails when the actor can decide and execute within the same session, because the control cycle lags the behaviour cycle. The implication is that identity programmes must stop treating agent access like ordinary server-side access.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: Who is accountable when an AI agent performs an unauthorised action?
A: Accountability should be traceable to the delegating user, the agent identity, and the session that authorised the action. If any of those three are missing from logs, incident response becomes ambiguous and revocation becomes incomplete. Governance teams should treat that triad as a minimum control requirement.
👉 Read our full editorial: How AI agent credential management fails without session scope