Notifications
Clear all
Topic starter
10/06/2026 11:01 pm
TL;DR: AI key inventories are fragmenting across OpenAI, Anthropic, Google Cloud, and AWS dashboards, leaving stale, unused, and orphaned credentials easy to miss, according to Riptides. The governance gap is not visibility alone, but the absence of lifecycle control over issued AI keys before they become exposure points.
NHIMG editorial — what this means for NHI practitioners
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.
Questions worth separating out
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.
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.
Q: What breaks when organisations cannot inventory their AI credentials?
A: Rotation, recertification, and offboarding all break down when the inventory is incomplete.
Practitioner guidance
- 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.
- 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.
What's in the full announcement
Riptides' full article covers the operational detail this post intentionally leaves for the source:
- Provider-by-provider implementation notes for OpenAI, Anthropic, Google Cloud, and AWS key enumeration
- The exact field mapping used to build a cross-provider inventory and health score
- How snapshots and diffs are stored and compared in the local SQLite workflow
- The runtime architecture for continuous polling, alerting, and credential injection inside Riptides
👉 Read Riptides' analysis of AI key sprawl and KeyLedger →
AI key sprawl across providers: what IAM teams are missing?
Explore further
12/06/2026 4:48 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI key sprawl is outpacing governance across provider dashboards
