← All posts
· by Omnodex Team · 8 min read
security credentials ai agents identity

Your AI Agents Handle More Credentials Than Your DevOps Team

AI agents touch dozens of API keys, OAuth tokens, and secrets in a single session. Almost nobody is tracking them. Here's why credential visibility is the missing piece in AI security.

Think about what your DevOps team does with credentials. They have a vault. They rotate secrets on a schedule. They audit access logs. They scope permissions to the minimum a service actually needs. It is careful, deliberate work, and most mature organizations have built real systems around it.

Now ask what happens when an AI agent runs a task.

The agent doesn’t have a vault. Its credentials are usually a set of API keys in a configuration file, OAuth tokens granted at setup with broad permissions, and whatever database passwords were available when the pipeline was built. It uses them without logging. Nobody knows which ones got touched. When the session ends, the credentials stay exactly where they were: unchanged, unaudited, and ready for the next run.

The scale is already hard to ignore

Non-human identities, including service accounts, API tokens, secrets, and autonomous agents, now outnumber human users by a ratio of 100 to 1. AI agent deployments are accelerating that imbalance. Every new agent is a new identity, and every new identity is a new credential surface.

The numbers from the secrets side are equally stark. GitGuardian’s State of Secrets Sprawl 2026 report found 28.6 million new secrets exposed in public GitHub commits across 2025 alone, a 34% year-over-year increase and the largest annual jump in the report’s history. Among credentials confirmed as valid in 2022, 65% were still valid in January 2026. They were never rotated. Nobody knew they were still live.

That is the environment AI agents are being deployed into: an existing secrets sprawl problem, now accelerated by agents that authenticate against real systems in every session.

A SINGLE AGENT SESSION: THE CREDENTIAL SURFACETOOL CALLCREDENTIAL USED01Fetch calendar eventscalendar API · schedule.readOAuth Tokenbroad scope · 14 months old02Query customer recordsproduction database · PII includedDatabase Passwordstatic · shared across agents03Call enrichment servicethird-party API · external egressAPI Keyteam-wide key · never rotated04Post update to Slackworkspace · channels.writeBot Tokenworkspace-wide scope · unscoped4 credentials. 1 session. 0 of them being tracked.
A representative agent session. Credential types and detail are illustrative but based on common deployment patterns.

How agents are actually being credentialed today

A 2026 survey by Gravitee found that 45.6% of organizations rely on shared API keys for agent-to-agent authentication, and 27.2% use custom hardcoded logic for authorization management. Only 21.9% treat AI agents as independent identity-bearing entities with their own scoped credentials.

Those numbers have direct security consequences. Shared API keys mean a compromised agent session can pivot to any system using the same key. Hardcoded credentials are effectively static until someone discovers them who shouldn’t. And agents that don’t carry their own scoped identities can’t be audited individually after the fact.

The answers are well-established: short-lived credentials, scoped permissions, rotation on a schedule, per-entity access logs. The tooling exists and is well understood. It just hasn’t been applied to AI agents in most organizations.

What happens when it goes wrong

In April 2026, Vercel was breached via Context.ai, an AI analytics integration. An attacker infected a Context.ai employee’s device with Lumma infostealer, extracted the OAuth token associated with their Vercel integration, and used its broad “Allow All” permissions to pivot through Vercel’s internal systems. Environment variables across customer projects were exposed. The attacker was inside for roughly two months before detection. Vercel’s database was subsequently listed for sale on BreachForums at $2 million.

Eight months earlier, in August 2025, a threat actor identified as UNC6395 used stolen OAuth tokens from Drift’s Salesforce integration to access customer environments across more than 700 organizations. The access looked routine because the credentials were legitimate. No anomaly detection flagged it.

The pattern in both incidents is the same: credentials held by or associated with an AI integration were never scoped, monitored, or revoked. The credential was the attack vector, and it was completely invisible to the teams responsible for defending the perimeter.

Masking is not the same as tracking

Some tools in this space address part of the problem. Lasso Security’s MCP Gateway and MintMCP can detect and mask credentials in transit, preventing secrets from being logged in plaintext. That helps.

But masking at the network level is not the same as tracking credential lifecycle through an agent’s execution. Knowing that an API key was present in a tool call doesn’t tell you which key it was, what system it authenticated against, when it was first used, how many sessions it appeared in, or whether the pattern of use looks like normal operation or an early-stage breach.

The difference between masking and tracking is the difference between redacting a document and understanding what the document said. A security audit after the fact requires the latter.

What a credential ledger actually needs to do

Credential visibility at the execution layer means several things that current tools don’t address.

Identify credentials as they’re used: not just mask them, but recognize the type (API key, OAuth token, database password), the system they belong to, and surface them as security-relevant events that can be queried and audited.

Track them across the execution chain. A credential appearing in step 2 of an agent’s execution and reappearing in step 7 via a different tool call is a pattern. That pattern might indicate normal operation, or it might indicate credential reuse in a context that was never intended. Without execution-level tracing, you cannot distinguish between the two.

Build a ledger, not just a log. Logs capture events. A ledger tracks state: which credentials an agent held, when it used them, what it accessed, and whether they were ever rotated or revoked. That is the record a compliance audit requires, and it is the record most organizations cannot currently produce.

Score risk automatically. A credential used across fifteen tool calls in a single session, or a token from one agent surfacing in another agent’s execution trace, should trigger a flag. Risk scoring at the credential level is how you move from raw data to action.

What we’re building

Omnodex intercepts every tool call in AI agent execution, including every point where credentials enter the picture. The result is a credential ledger that tracks every API key, token, and secret used at runtime: what it was, when it appeared, what it accessed, and whether the pattern warrants attention.

Your security team can already audit credentials across every other system in your stack. AI agents should not be the exception.

If you’re working through this problem, we’d like to talk. Reach us at hello@omnodex.com.

Sources