AI key sprawl is outpacing governance across provider dashboards

At a glance

What this is: This is an independent analysis of AI provider key sprawl and KeyLedger’s read-only inventory model, with the key finding that organisations often lack a unified view of issued AI credentials across providers.

Why it matters: It matters because IAM, PAM, and NHI teams cannot govern what they cannot inventory, especially when AI keys can be old, unused, over-privileged, or tied to departed owners.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read Riptides' analysis of AI key sprawl and KeyLedger

Context

AI key sprawl is the practical problem here: organisations are issuing credentials across multiple provider dashboards, but they are not maintaining a single, dependable inventory of what exists, who owns it, or when it was last used. That leaves stale keys, orphaned access, and forgotten admin credentials outside routine governance.

For NHI and IAM teams, the issue is not whether a key can be rotated in theory. It is whether the organisation can see all issued AI provider keys well enough to apply lifecycle controls, detect idle access, and remove credentials that outlive their business purpose. The visibility gap is the control gap.

The article uses KeyLedger as the trigger for the discussion, but the governance question is broader than one tool. Provider-specific dashboards fragment the evidence needed for reviews, recertification, and incident response, which means AI credentials often sit outside the same discipline applied to other NHIs.

Key questions

Q: How should security teams govern AI provider keys across multiple dashboards?

A: Security teams should centralise AI provider keys into one inventory, then attach ownership, creation time, status, and usage data so review and revocation decisions can be made consistently. Provider consoles alone are not enough because they fragment the record of what exists. Treat the inventory as part of the control plane, not as reporting after the fact.

Q: Why do stale AI keys become a higher-risk NHI issue than teams expect?

A: Stale AI keys remain dangerous because they often still authenticate successfully even when nobody is actively using them. If an old key is discovered in a repository, shell history, or ticket, it can become an immediate access path to model services or connected cloud resources. The longer a key persists without review, the more likely it is to outlive its owner and purpose.

Q: What breaks when organisations cannot inventory their AI credentials?

A: Rotation, recertification, and offboarding all break down when the inventory is incomplete. Teams cannot prove which keys are active, cannot identify which owners should review them, and cannot confidently retire credentials that may already be obsolete. The result is governance theatre: policies exist, but the evidence needed to enforce them does not.

Q: How do security teams connect AI key management to broader NHI governance?

A: They should manage AI provider keys the same way they manage other non-human identities: assign an owner, track lifecycle state, review usage, and remove credentials that no longer have a business purpose. The difference is not the governance model but the provider fragmentation, which makes a unified inventory more urgent, not less.

How it works in practice

Why AI provider dashboards create key inventory blind spots

AI providers expose credentials through different administrative models, so inventory is fragmented by design. OpenAI groups keys by organisation and project, Anthropic uses organisations and workspaces, Google Cloud nests service accounts and keys inside projects, and AWS ties keys to IAM users. That means the same organisation may need to query several APIs, each with different metadata depth and different limits on usage history. A unified inventory tool works by normalising those models into one view, which is useful for auditability but also reveals how inconsistent provider-native governance really is.

Practical implication: Build an external inventory layer for AI keys instead of relying on provider consoles as your control plane.

Health scoring, snapshots, and diffs for AI credentials

A key inventory is only useful if it captures change over time. Snapshotting creates point-in-time records, while diffs show what changed between scans, including new keys, revoked keys, status changes, and scope changes. Health scoring adds another governance layer by flagging stale, idle, or never-used keys based on thresholds. This is not the same as rotation. It is the evidence base that tells you which credentials need review, which have drifted, and which may already be obsolete.

Practical implication: Use snapshots and diffs to turn AI key review from a manual checklist into a repeatable control.

Why last-used data matters more than raw key counts

Counting keys does not tell you which ones are dangerous. Last-used timestamps, owner metadata, and status fields make the difference between a list and a governance signal. Where providers expose last-used data, teams can distinguish active service keys from dormant ones. Where they do not, teams are forced into indirect inference through usage reports or manual review. That limitation matters because stale keys can remain valid long after the business need has ended, and every extra day widens the exposure window.

Practical implication: Prioritise inventory sources that include owner, creation, and usage metadata so you can target revocation and recertification correctly.

NHI Mgmt Group analysis

AI key sprawl is a governance problem before it becomes a breach problem. The article shows that organisations are issuing credentials faster than they can inventory them, across dashboards that do not share a common control model. That means key count, key age, and key ownership become fragmented facts rather than governable records. The practitioner conclusion is simple: if the inventory is incomplete, the lifecycle programme is already failing.

Visibility is the prerequisite control for AI credential lifecycle management. The article’s strongest insight is that rotation, revocation, and recertification all depend on knowing what exists. A key that is not discoverable cannot be reviewed, and a key with no owner cannot be confidently recertified or retired. For NHI programmes, inventory is not reporting. It is the control surface that makes every other decision possible. The practitioner conclusion is that AI keys need the same authoritative asset view as other privileged identities.

KeyLedger exposes a named concept we should call identity inventory debt. This is the gap between the number of issued AI credentials and the organisation’s ability to explain them on demand. It grows when keys are created in silos, left in default workspaces, or never tied back to an accountable owner. The implication is that teams are accumulating hidden lifecycle liability, not just operational clutter. The practitioner conclusion is to treat unexplained keys as debt with an expiry date, not as harmless leftovers.

Provider-native APIs are not yet a reliable governance baseline for AI NHIs. The article shows that some providers expose rich metadata, others expose partial usage signals, and some still lack the fields needed for reliable idle-key detection. That inconsistency creates uneven governance and leaves teams dependent on whichever provider happens to have the best admin surface. The implication is that NHI governance for AI keys must assume heterogeneity, not uniform platform capability. The practitioner conclusion is to design controls around the weakest provider, not the strongest one.

AI key governance is converging with broader NHI lifecycle discipline. The same questions now apply across service accounts, API keys, and AI provider credentials: who owns it, when was it issued, when was it last used, and when should it be removed. That makes AI key management part of the same governance discipline as other non-human identities, not a separate special case. The practitioner conclusion is to fold AI provider keys into the main NHI review and offboarding process.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and 47% have only partial visibility, according to The State of Non-Human Identity Security.
• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months.
• The visibility problem is not limited to AI keys, which is why Guide to the Secret Sprawl Challenge is the next step for teams trying to reduce credential exposure across the lifecycle.

What this signals

Identity inventory debt: the more AI providers an organisation adopts, the more likely it is to accumulate credentials that no one can account for quickly. That debt shows up first in recertification and offboarding, then in incident response when teams discover they cannot answer basic ownership questions. The practical signal is that AI key governance should now be measured as part of the wider non-human identity programme, not as a separate admin task.

The next phase of maturity is not more dashboards, but control stitching across inventory, usage, and lifecycle events. If a team cannot connect issued credentials to owners, workloads, and recertification outcomes, it will keep mistaking visibility for governance. That is where NHI programmes need to move from discovery to decisioning, with one consistent record across human, machine, and agent-adjacent access.

For practitioners

• Create a unified AI key inventory Pull OpenAI, Anthropic, Google Cloud, and AWS credentials into one authoritative register that tracks owner, creation time, status, and last use. Do not rely on the provider dashboard as the only source of truth.
• Flag stale and never-used keys for immediate review Set risk thresholds for age and inactivity, then route keys older than your policy window or never observed in use to recertification and revocation queues.
• Treat departed owners as a revocation trigger If a key was created by someone who has left the company or changed teams, verify whether the credential still has a business owner and remove it if it does not.
• Snapshot and diff key state on a schedule Record periodic inventories so you can identify new keys, revoked keys, and scope changes between review cycles instead of depending on ad hoc detection.
• Embed AI keys into NHI offboarding workflows Add provider credentials to the same joiner-mover-leaver process used for other non-human identities, including owner reassignment, review, and deletion checks.

Key takeaways

• AI key sprawl creates a lifecycle governance problem because organisations often cannot see, own, or retire the credentials they issue.
• Provider dashboards expose different amounts of metadata, which means inventory quality varies by platform and weakens recertification, rotation, and offboarding.
• The practical response is to centralise inventory, track usage and ownership, and fold AI provider keys into the main NHI governance process.

Key terms

• AI Provider Key Inventory: A central record of all API keys and access credentials issued across AI providers and cloud platforms. It captures ownership, creation time, status, and usage so security teams can govern credentials instead of discovering them incidentally during incidents or audits.
• Identity Inventory Debt: The gap between the number of credentials an organisation has issued and the organisation’s ability to explain, review, and remove them on demand. It grows when keys are created in silos, never mapped to owners, or left outside lifecycle processes such as recertification and offboarding.
• Key Recertification: A periodic review process that confirms whether a credential still has a valid business purpose and an accountable owner. For AI provider keys, recertification should use usage history, owner data, and scope information so stale or orphaned access can be removed before it becomes exposure.
• Provider Metadata Normalisation: The process of converting different provider-specific key fields into one consistent governance model. It matters because OpenAI, Anthropic, Google Cloud, and AWS expose different inventories and usage signals, so security teams need a common record before they can compare risk or automate lifecycle decisions.

Deepen your knowledge

AI key inventory, ownership, and lifecycle review are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to govern provider-issued AI credentials across fragmented dashboards, it is worth exploring.

This post draws on content published by Riptides: Introducing KeyLedger and the case for AI key inventory governance. Read the original.