Vercel-style breaches expose the audit gaps behind ephemeral secrets

At a glance

What this is: This is a practical audit for identifying OAuth overreach, static secrets, and AI-agent identity exposure after the Vercel incident.

Why it matters: It matters because IAM, NHI, and identity governance teams need to know where long-lived access, broad third-party scopes, and agent credentials still create avoidable breach blast radius.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.

👉 Read Akeyless's practical audit for Vercel-style OAuth and secret exposure

Context

Ephemeral secrets reduce the time an attacker can use stolen credentials, but they do not remove the governance work required to know which identities exist, who owns them, and what access they can reach. The operational problem is identity sprawl across OAuth apps, static API keys, cloud service accounts, and newly authorised AI tools.

The article turns that into a short audit sequence for platform and security teams. The primary issue is not one breach mechanism, but the continuing gap between how access is granted and how quickly teams can prove whether that access still makes sense.

Key questions

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. Broad delegated access is only defensible when ownership, purpose, and review cadence are all explicit. If an app cannot be justified quickly, its scope is already too broad for safe governance.

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. Age alone is not the issue. The issue is that the longer a key survives, the more it behaves like standing privilege and the more blast radius it creates if stolen.

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. That misses persistent session state, broad scopes, and unclear ownership. If an AI tool can continue acting after the user interaction ends, it needs lifecycle controls similar to a service account.

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.

Technical breakdown

OAuth scope review and delegated third-party access

OAuth apps inherit the authority of the user or tenant that authorises them, which makes scope review a control on delegated trust rather than simple application inventory. Broad scopes such as domain-wide mail access or directory permissions can create durable exposure even when the app itself is not actively used. The governance issue is that authorisation often outlives business need, especially where no one can clearly name the owner or last use case. In practice, OAuth risk is about permission shape, not just application count.

Practical implication: map every high-scope app to an owner, a use case, and a review cadence before revoking anything without justification.

Static secrets versus dynamic credentials

Static API keys and long-lived cloud access keys are dangerous because their value to an attacker does not decay unless teams explicitly rotate or replace them. Dynamic credentials, by contrast, reduce standing exposure by making the credential useful only within a narrow operational window. The technical distinction matters in Kubernetes, CI/CD, and cloud service accounts, where secrets often persist in environment variables or config files long after the job that created them has changed. Secret age becomes a measurable signal of governance quality.

AI-agent identity and persistent session credentials

AI tools increasingly authenticate through enterprise identity providers, but the identity risk changes when the tool can retain credentials between sessions or accumulate broader scope than a human user would need. That creates a workload-like identity pattern with delegated access, not a human interaction pattern. The question is not whether the tool is clever, but whether its identity behaves like an NHI that can carry privileges forward without tight lifecycle control. Treating the agent as just another app misses how quickly its access can become operationally privileged.

Practical implication: review every authorised AI tool for persistent credentials, inherited scopes, and ownership before allowing it to remain connected.

Threat narrative

Attacker objective: The attacker aims to exploit legitimate identity paths to reach production data and widen the breach beyond a single compromised secret.

1. Entry occurs through delegated third-party access, stolen static secrets, or an AI tool that already has valid identity-provider authorisation.
2. Escalation follows when broad OAuth scopes, long-lived keys, or persistent agent credentials expose production systems, mail, or directory data beyond the original task.
3. Impact is measured in blast radius, because the attacker can act through legitimate access paths and force broad rotation or containment across multiple systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

OAuth scope drift is the hidden control failure in third-party access. The article’s audit questions are really a call to challenge delegated access that has outlived its business purpose, especially where no one can explain the current use case. This is a classic NHI trust problem: the system assumes authorisation is still legitimate because the token remains valid. The practitioner conclusion is that ownership, review, and revocation need to be as explicit for apps as they are for people.

Static secret age is a measurable proxy for standing privilege debt. A production-access key older than 90 days is not just stale inventory, it is evidence that access has been allowed to persist beyond operational need. That is the same failure mode the OWASP Non-Human Identity Top 10 treats as credential sprawl and over-privilege. The practitioner conclusion is to use age, scope, and production reach as the three priority fields in any NHI review.

AI-agent identity should be governed like a high-risk NHI, not a convenience feature. The article correctly treats authorised AI tools as identities that can retain credentials and exceed human-equivalent scope. That aligns with the broader shift in identity security: the control question is no longer only who logged in, but what runtime identity can keep acting after the human is gone. The practitioner conclusion is to fold AI tools into the same access review and offboarding discipline used for service accounts.

Identity blast radius is becoming the right unit of analysis. The most useful concept in this article is not credential type, but the combined effect of scope, persistence, and ownership on breach reach. Once teams can see that a single stale key, OAuth grant, or agent credential can touch many systems, the governance conversation changes from inventory to containment. The practitioner conclusion is to measure exposure by blast radius, not by secret count alone.

From our research:

• 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.
• That gap is why teams should pair scope review with lifecycle controls, as explored in The 52 NHI Breaches Report for the breach patterns that make visibility failures expensive.

What this signals

Ephemeral credential hygiene is no substitute for governance visibility: if teams cannot see who authorised a third-party app, which secrets still exist, and which AI tools retain access between sessions, they have not reduced risk so much as changed its shape. The operating model now needs access ownership, not just secret rotation. For broader identity context, the OWASP Non-Human Identity Top 10 remains a useful reference point.

The article points toward a larger programme shift: teams should track blast radius, scope age, and offboarding latency as first-class identity metrics. Those are the signals that show whether review and revocation are actually keeping pace with delegated access. For identity teams aligning governance to zero trust, the NIST Cybersecurity Framework 2.0 remains the right control lens.

For practitioners

• 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. Keep a 30-day review cycle for the remaining high-scope apps.
• Replace static production secrets Find API keys and cloud access keys in environment variables, CI/CD configuration, and Kubernetes secrets. Rotate or replace any production-access key older than 90 days with a dynamic credential where possible.
• Add AI tools to identity review Treat authorised AI tools as non-human identities. Check whether they retain credentials between sessions, exceed human-equivalent scopes, or can keep acting after the original task is finished.
• Measure blast radius before the next incident For every critical secret or delegated app, document what systems it can touch, who can revoke it, and how long rotation would take under incident pressure. If the answer is days, the control problem is standing privilege.

Key takeaways

• Ephemeral secrets reduce exposure windows, but they do not solve the underlying problem of delegated access that nobody owns or reviews.
• OAuth scope drift, static key age, and persistent AI-tool credentials are the practical indicators that blast radius is still too large.
• Teams should prioritise ownership, revocation speed, and lifecycle control before they trust any inventory count as proof of security.

Key terms

• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another, usually through an OAuth app, API token, or service integration. In identity governance terms, it is only safe when ownership, scope, and revocation are explicit and continuously reviewed.
• Static Secret: A static secret is a credential that remains valid until someone rotates or revokes it, such as an API key, password, or long-lived cloud access key. It creates standing exposure because compromise persists until the secret is replaced, regardless of whether the original job is still active.
• Identity Blast Radius: Identity blast radius is the amount of damage one credential, token, or delegated app can cause if abused. It is shaped by scope, lifetime, and the systems reachable through that identity, which makes it a better risk measure than counting secrets alone.
• AI-Agent Identity: AI-agent identity is the set of credentials, scopes, and lifecycle controls attached to an AI tool that can authenticate into enterprise systems. When the agent retains access between sessions or exceeds human-equivalent scope, it behaves like a high-risk non-human identity and should be governed that way.

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

👉 Akeyless's full post covers the step-by-step audit prompts and prioritisation logic

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.