Credential sprawl does not announce itself. It accumulates quietly in the background of every agentic deployment — one OAuth token at a time, one unused service account at a time, one experiment that never got cleaned up. By the time most teams notice it, they have a problem that is months old and impossible to untangle manually.
How sprawl starts: the three-day experiment
A developer on your platform team wants to test whether an AI agent can automate your GitHub issue triage process. They spend a long weekend building a proof of concept in LangChain. They create a GitHub OAuth app, generate a token, put it in a local .env file, and get the agent working. The POC is impressive. They demo it to the team. Everyone agrees it is promising. Then a production fire lands, the POC goes on the backlog, and the developer moves on.
The GitHub OAuth app still exists. The token is still valid. The developer's laptop still has the .env file. If the laptop is ever compromised, or if the developer ever pastes that token somewhere inadvertently, your GitHub organization is exposed — and nobody on the security team knows the token exists, because it was created during a weekend experiment that was never officially deployed.
Multiply this by the number of developers experimenting with AI agents at your company. Multiply it by the number of integrations each experiment touches. Multiply it by the months or years over which experiments have been running. That is credential sprawl in agentic AI — not one compromised token, but dozens or hundreds of forgotten credentials distributed across personal laptops, CI/CD pipelines, development Slack workspaces, and test environments.
Why agentic AI produces sprawl faster than traditional automation
Traditional automation scripts — bash scripts, Python automation, n8n workflows — tend to be explicit about their credentials. A Bash script that calls the Slack API has a token variable at the top. When someone audits the script, they see the token. When the script is decommissioned, the token is usually revoked at the same time.
AI agents are different in three ways that accelerate sprawl. First, agent frameworks abstract credential management. When you build an agent with LangChain's pre-built tool integrations, the credential setup happens in a configuration block that is separate from the agent logic. Developers think of the credential as infrastructure rather than code — so they do not treat it with the same discipline they apply to their application code.
Second, agents are composable. A complex agentic pipeline might have six sub-agents, each with its own credential set. The parent agent's developer may not know what credentials the sub-agents are using — that was the responsibility of whoever built the sub-agent tool. When the pipeline is decommissioned, the parent agent's credentials get revoked. The sub-agent credentials persist.
Third, agents produce derivative credentials. An agent that is authorized to act on a user's behalf — through OAuth with user consent — can, in some framework implementations, create additional app authorizations or grant permissions to other agents. These derivative grants are rarely tracked in the original authorization record.
Measuring sprawl: the credential audit
Before you can fix credential sprawl, you need to measure it. A credential audit for an agentic AI deployment has four components.
GitHub OAuth Apps inventory. Go to your GitHub organization settings, navigate to OAuth Apps, and list every authorized application. For each one, record the owner, the scopes, the last active date, and whether the application is still in use. In most organizations, 30-50% of authorized apps are from experiments or decommissioned projects. GitHub does not notify you when an app goes inactive — that information is only visible when you actively check.
Slack app directory audit. Check your Slack workspace's app directory for installed apps with bot scopes or OAuth user scopes. Filter for apps that have not posted or been active in the past 90 days. These are candidates for revocation. Pay special attention to apps with files:write, channels:write, or any admin scope — these represent the highest blast radius if compromised.
Secrets manager inventory. If you use AWS Secrets Manager, HashiCorp Vault, or a similar tool, pull a list of all secrets and their last-accessed timestamps. Secrets that have not been accessed in 90+ days are candidates for rotation or deletion. Sort by creation date and cross-reference with your team's list of active agents.
CI/CD environment variable scan. Check your GitHub Actions secrets, GitLab CI/CD variables, CircleCI environment variables, and any other pipeline configuration for OAuth tokens stored as environment variables. These are particularly high-risk because they are often accessible to all pipelines in a repository or organization, not just the specific workflow that uses them.
The ownership problem
The hardest part of addressing credential sprawl is not technical — it is organizational. For every abandoned OAuth token, there is a question of who owns the remediation. The developer who created it may have left the company. The project it was created for may not have a current owner. The team responsible for security may not have the authority to revoke a credential that belongs to a product team's integration.
We have seen this play out in a specific pattern across multiple enterprise customers. Security finds an abandoned OAuth token with broad scope. They escalate to the platform team. The platform team says the token belongs to the data team. The data team says it was part of an experiment run by a contractor six months ago and they are not sure if anything depends on it. Nobody revokes it because nobody wants to break something in production.
The resolution to this pattern is not more process — it is a technical change that makes the cost of revocation zero. When tokens are short-lived by design, you do not need to revoke abandoned tokens — they expire automatically. When tokens are issued through a central proxy that tracks their purpose, ownership questions become answerable: the proxy log shows which agent minted the token and which task it was executing. That evidence gives someone the confidence to act.
Short-term cleanup: the 90-day revocation sweep
If you have existing credential sprawl and want to reduce your exposure quickly, a 90-day revocation sweep is the fastest safe option. The rule: any credential that has not been used in 90 days gets revoked. This is aggressive, but it is recoverable — if something breaks in production, you can re-create the credential quickly. If nothing breaks, you have eliminated a meaningful amount of latent risk.
Run the sweep on a Friday. Monitor your error logs and agent outputs over the weekend. By Monday, you will have a list of things that actually depended on credentials you revoked — and every item on that list is now an officially tracked, actively monitored credential with a known owner rather than an orphaned secret.
Document what you revoke. Record the scope, the service, the date of revocation, and the outcome. That documentation becomes the starting point for your ongoing credential inventory.
Long-term prevention: policy at the issuance layer
Cleanup is a one-time action. Prevention requires architecture. The only durable solution to credential sprawl is enforcing a policy at the moment credentials are issued: every credential must have an owner, a purpose, and a TTL.
This is what Alter's policy engine does. Before any credential is issued to an agent, the policy engine checks whether the requesting agent is registered, whether the requested scopes are within policy, and what TTL to assign. Credentials issued outside of this system — directly through the OAuth provider's UI or API — can still be created, but they are out-of-band and visible as exceptions in the audit log.
Over time, the goal is to reduce the out-of-band exception rate to zero. When every OAuth token issued to an AI agent in your organization flows through a single policy gateway, you have complete visibility into your credential inventory at any point in time. Sprawl becomes structurally impossible — not because you trust developers to follow the rules, but because the architecture makes it difficult to issue credentials any other way.
Start with a count
This week, pick one OAuth provider — GitHub is the most common starting point — and count the active tokens your agents have issued. Not the number of agents. Not the number of integrations. The number of individual active tokens. If that number surprises you, you already know what needs attention. Start there.