Notifications
Clear all
Topic starter
24/06/2026 7:19 pm
TL;DR: A 30-minute audit around the Vercel incident focuses on OAuth scope review, static secret inventory, and AI-agent identity checks to reduce blast radius and speed targeted rotation, according to Akeyless. The deeper issue is that standing-credential assumptions still drive governance, even when secrets are ephemeral.
NHIMG editorial — based on content published by Akeyless: a practical audit for Vercel-style OAuth and secret exposure
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
Questions worth separating out
Q: How should security teams handle broad OAuth scopes in third-party apps?
A: Security teams should inventory every high-scope OAuth app, map it to a business owner, and revoke anything without a clear current use case.
Q: When does a static secret become a governance problem instead of a convenience?
A: A static secret becomes a governance problem once it reaches production scope, persists beyond the original need, or sits outside a defined rotation process.
Q: What do teams get wrong about AI-agent identity reviews?
A: Teams often review AI tools as software integrations rather than as identities that can hold credentials and inherit access.
Practitioner guidance
- Audit delegated OAuth scopes Enumerate every third-party app with domain-wide or high-risk permissions, then revoke any app that has no current business owner or clear use case.
- Replace static production secrets Find API keys and cloud access keys in environment variables, CI/CD configuration, and Kubernetes secrets.
- Add AI tools to identity review Treat authorised AI tools as non-human identities.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step audit prompts for Google Workspace and Microsoft 365 delegated app reviews
- Practical secret inventory checks across environment variables, CI/CD files, and Kubernetes secrets
- A focused review of AI-tool identities that retain credentials between sessions
- A simple scoring exercise to prioritise the next 60 days of remediation
👉 Read Akeyless's practical audit for Vercel-style OAuth and secret exposure →
Ephemeral secrets and OAuth scopes: what IAM teams are missing?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 4:33 am
Ephemeral secrets do not eliminate the identity governance problem. They shorten the useful life of stolen credentials, but they do not answer who owns the identity, what scopes it carries, or how quickly it can be revoked when business need changes. That is why this topic sits squarely in OWASP-NHI and NIST CSF territory, not just infrastructure hygiene. The practitioner conclusion is that blast radius is still governed by identity lifecycle discipline, not by secret format alone.
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 a further 47% have only partial visibility, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, which shows how uneven identity confidence remains.
A question worth separating out:
Q: Who is accountable when a delegated app or secret causes a breach?
A: Accountability should sit with the business owner of the delegated access, the identity team that approved the scope, and the platform team that allowed it to persist. Frameworks like NIST CSF and OWASP NHI both point toward clear ownership, review, and revocation as the controls that matter most.
👉 Read our full editorial: Vercel-style breaches expose the audit gaps behind ephemeral secrets
