When an employee leaves, HR files a ticket, IT runs a checklist, and access gets pulled the same day. When an AI agent gets retired, replaced by a newer model, or quietly abandoned after a project pivot, nothing files that ticket. Its database credentials, connection strings, and role grants keep working indefinitely — because deprovisioning an AI agent has no equivalent of an exit interview.

What’s actually happening

Organizations are accumulating orphaned non-human identities: service accounts, API keys, and database roles originally provisioned for an AI agent that no longer does the job it was built for, but whose credentials were never revoked. A 2026 identity dataset found roughly 824,000 active accounts with no assigned owner — about 8% of identity-provider users — still holding live entitlements (Iden, 2026). Separately, industry reporting on AI identity lifecycle management puts the share of organizations with a formal process for offboarding and revoking agent API keys at only about 20% (The Hacker News, 2026).

This isn’t the same problem as an agent making a bad query or a compromised credential being misused in real time — those get caught by monitoring. This is a credential that is working exactly as designed, attached to a workload that stopped existing, sitting in your database’s connection logs as a legitimate-looking, low-noise line item that nobody is actively watching because nothing about it looks wrong.

The Cloud Security Alliance frames this as a governance vacuum: non-human identities were historically provisioned by whoever needed them fastest, tracked nowhere central, and never subjected to the access reviews or lifecycle policies applied to human accounts (CSA, 2026). AI agents inherit that same blind spot, at a much higher rate of churn — a team might spin up and retire a dozen agent variants in a single quarter of prompt iteration, each with its own database connection.

Who’s affected

DBAs and platform engineers are the ones who eventually find these credentials — usually during a security audit, a breach investigation, or a routine review of who’s connecting to a production database, at which point “I don’t know what that is” is not a comfortable answer to give.

Security and compliance teams own the exposure. An orphaned credential with standing database access is precisely the kind of finding that turns a routine SOC 2 or ISO 27001 audit into a remediation project, and it’s indistinguishable from an attacker-planted backdoor until someone proves otherwise.

AI/ML engineering leads and product teams are the ones actually creating the problem, usually without realizing it. Every time an agent is upgraded to a new model, migrated to a new orchestration framework, or a pilot project is quietly shelved, the database credentials that agent used typically aren’t part of anyone’s shutdown checklist — because there usually isn’t a shutdown checklist for agents in the first place.

CTOs and engineering leadership carry the ultimate accountability, because this is a resourcing and process gap, not a technology gap. The fix requires assigning ownership of agent identity lifecycle to someone, which doesn’t happen by default.

When this becomes urgent

This is already happening, not a future risk. The 824,000-orphaned-account figure and the 20%-formal-process figure above are both from 2026 reporting on current environments, not projections. What’s changing is the rate: as agent tooling matures and iteration cycles shorten — new frameworks, new model versions, new orchestration patterns arriving every few months — the number of agent identities an organization provisions and retires per year is climbing fast, while offboarding processes have not caught up.

The realistic near-term window (next 12-18 months) is when this shifts from “quiet risk” to “active audit finding,” as more compliance frameworks explicitly extend identity governance requirements to non-human and agentic identities rather than treating them as an edge case. Regulators and auditors are increasingly asking “show me your inventory of every identity with data access, human or not” — a question most organizations currently cannot answer completely for agents.

How this actually plays out in a database environment

The mechanics are almost boring, which is exactly why they get missed:

  1. A project provisions an agent with a dedicated database login, a scoped role, or an API key tied to a service account — often created quickly, outside the standard human-identity provisioning workflow, because “it’s just for the agent.”
  2. The agent is replaced. A newer model version ships, the team migrates to a different orchestration framework, or the underlying use case is deprioritized. The code path that used the old credential stops being invoked.
  3. Nothing revokes the credential. Unlike a human offboarding, there’s no HR trigger, no manager sign-off, no ticket. The credential simply stops being used in normal operations — but it still authenticates successfully if presented.
  4. The credential drifts out of anyone’s mental model. Six months later, the person who provisioned it has moved teams, the project’s Slack channel is archived, and the credential exists only as a row in the database’s sys.server_principals or equivalent, with a vague name like agent_svc_v2 that nobody can confidently map to a live system.
  5. It surfaces one of two ways: a security review flags it as an anomaly requiring investigation (best case, costly in analyst time), or it gets reused — deliberately or accidentally, by a new project that discovers “oh, there’s already a service account, let’s just use that” — inheriting whatever scope was granted years earlier without anyone re-evaluating whether that scope is still appropriate (worse case).

This compounds with a problem covered in this series before: multi-hop agent delegation, where one agent spawns another that spawns a third, means an orphaned credential may not even map cleanly to a single retired workload — it may have been shared across a delegation chain, making “who owned this” even harder to reconstruct after the fact. It’s also the natural next question after auditing who’s actually holding database credentials in the first place: an audit tells you what exists today, but not whether it should still exist at all.

Emerging mitigations are shifting the model rather than just tightening the checklist. SPIFFE/SPIRE-based workload identity, for example, issues AI agents short-lived cryptographic identity documents (SVIDs) that rotate automatically — commonly every hour in production reference architectures — rather than long-lived static credentials (Cockroach Labs, 2026). An agent that’s retired simply stops being re-attested and its identity naturally expires within the hour, instead of persisting until someone remembers to revoke it by hand.

A first, low-effort pass at finding candidates doesn’t require new tooling — it requires cross-referencing two things most teams already have but rarely compare: the identity catalog and the connection logs. On SQL Server, that looks like pulling every login from sys.server_principals where type_desc indicates a SQL or Windows login (not a built-in role), then checking each against sys.dm_exec_sessions or your audit log for any connection in the last 60-90 days. On Postgres, the equivalent is pg_roles joined against pg_stat_activity history or your query-log archive. Anything present in the identity catalog but absent from recent activity is a candidate for either legitimate low-frequency use (worth documenting) or genuine orphaning (worth revoking). The point isn’t a one-time cleanup — it’s establishing this as a query you can re-run on a schedule, because the list changes every time a project ships, pivots, or gets shelved.

Common questions

Is this the same as a compromised or stolen credential? No. A stolen credential is misused by someone who shouldn’t have it; an orphaned credential is unused by anyone but still technically valid, because whoever should have revoked it never did. Both end up granting unauthorized access, but the failure mode and the fix are different — one is an intrusion-detection problem, the other is a lifecycle-governance problem.

Doesn’t role-based access control already handle this? RBAC controls what an identity can do once it’s authenticated; it says nothing about whether that identity should still exist at all. A well-scoped role assigned to a retired agent is still an orphaned credential — narrower scope limits the blast radius if it’s misused, but it doesn’t close the underlying gap.

Can’t we just set all agent credentials to expire? Expiration is the right direction, but a blanket short expiration on every credential without a renewal workflow just shifts the pain to production outages when a still-active agent’s credential lapses unexpectedly. The fix pairs expiration with an active renewal step tied to a named owner confirming the agent is still in use — which is exactly the mechanism SPIFFE/SPIRE-style short-lived identity automates.

Actions to take now

  1. Inventory every database identity currently in use, and flag any login, role, or connection string whose owner you cannot name in one sentence. Start with sys.server_principals / pg_roles (or your platform’s equivalent) cross-referenced against active connection logs from the last 30-90 days — anything with credentials but no recent connections is your first suspect list.
  2. Require an owner field at provisioning time, not after the fact. Any new database credential created for an agent should be tied to a named human owner and a project/ticket reference before it’s granted access, not discovered retroactively during an audit.
  3. Set expiration by default, not by exception. Where your database platform supports it, provision agent credentials with a hard expiration date (30, 60, or 90 days) that requires active renewal, rather than indefinite validity. Renewal forces someone to confirm the agent still exists and still needs that access.
  4. Add “retire the database credential” to your agent shutdown checklist — if you don’t have an agent shutdown checklist, that’s the actual gap to fix first. Treat decommissioning an agent as a two-sided operation: stop the workload, and revoke what it could reach.
  5. Run a quarterly non-human identity review, modeled on the human access reviews you likely already do for compliance, but scoped specifically to service accounts, API keys, and database roles tied to AI agents and automation. This is the single highest-leverage habit against orphaned-credential drift, because it turns an open-ended problem into a recurring, bounded task.
  6. Pilot short-lived, attested credentials for new agent deployments — SPIFFE/SPIRE or your cloud provider’s equivalent workload-identity federation — starting with one new agent project rather than attempting a full retrofit. Short-lived credentials that require active re-attestation solve the orphaning problem structurally, because an agent that no longer exists simply stops renewing its own access.
  7. Escalate this to whoever owns your compliance posture. If your organization is subject to SOC 2, ISO 27001, or sector-specific regulation, ask directly whether your current identity inventory includes non-human and agentic identities. If the honest answer is “we’re not fully sure,” that’s the finding an external auditor will eventually make for you — better to surface it internally first.

Key takeaways

  • Orphaned AI agent identities retain live database access because there’s no equivalent of an HR offboarding trigger when an agent is retired — the credential keeps working until someone manually revokes it.
  • Recent data puts unowned active identity accounts at roughly 8% of identity-provider users, while only about 20% of organizations have a formal process for offboarding agent credentials.
  • This is a current, not future, risk — the exposure already exists in most environments and is growing as agent iteration cycles shorten.
  • Multi-hop agent delegation makes orphaned credentials harder to trace back to a single owner after the fact.
  • Short-lived, auto-rotating workload identities (SPIFFE/SPIRE-style) are the structural fix; owner-tagging, expiration-by-default, and quarterly non-human identity reviews are the practical steps to take before that’s fully in place.

Getting agent identity lifecycle right is part of making a database genuinely ready for autonomous systems, not just accessible to them. Get in touch if you need help auditing what’s actually holding access to your database today.

Ivan Lima is a data engineer specializing in database modernization for AI systems. Get in touch if your database needs to be ready for what’s next.