AI agent attacks shift security focus from apps to access

TL;DR: Attackers are increasingly targeting access rather than applications, using compromised tokens, OAuth-connected apps, and AI-driven automation to accelerate reconnaissance, exploitation, and exfiltration, according to Entro Security and Anthropic. The decisive control problem is now identity governance for non-human access, not just perimeter defence.

At a glance

What this is: This analysis argues that 2025 marked a shift from app-centric intrusion to access-centric compromise, with tokens, secrets, OAuth apps, and agentic AI driving the change.

Why it matters: For IAM and NHI practitioners, the implication is that identities with machine permissions now define the attack surface and the blast radius.

👉 Read Entro Security’s analysis of AI-driven access attacks and NHI exposure

Context

Access becomes the real target when attackers can inherit trusted machine permissions instead of breaking into applications directly. For IAM and NHI programmes, that changes the control problem from user-centric authentication to lifecycle governance for secrets, tokens, OAuth-connected apps, and agent permissions.

The article combines three examples that point in the same direction: AI-assisted attacker workflows, secret harvesting from build and runtime environments, and compromised SaaS integrations acting as clean access paths. That mix is increasingly typical of modern NHI risk, not an edge case.

AI agents and automation increase the speed at which exposed credentials can be found, abused, and reused. Once those credentials sit inside non-human identities, conventional access controls lose effectiveness unless teams can see ownership, scope, rotation status, and downstream reach.

Key questions

Q: How should teams govern non-human identities in AI-heavy environments?

A: Teams should govern non-human identities the same way they govern other privileged assets: assign ownership, minimise scope, rotate credentials regularly, and monitor for abnormal use. The key difference is speed. AI-driven workflows can exploit exposed access quickly, so detection and revocation must be automated and tied to lifecycle controls.

Q: Why do secrets and tokens create a larger risk than application vulnerabilities?

A: Secrets and tokens matter because they bypass many application controls once stolen. An attacker with valid machine credentials can act as an authorised user, move through APIs, and reuse trust already granted by the business. That makes credential exposure a direct access problem, not just a hygiene issue.

Q: What is the difference between a service account and an OAuth-connected app?

A: A service account is usually a workload identity created for a specific system task, while an OAuth-connected app is a delegated identity that gains access through consent and scoped authorization. Both can become privileged non-human identities, but delegated apps often create wider shared blast radius if their scopes are too broad.

Q: When should organisations treat AI agent access as a privileged identity risk?

A: Organisations should treat AI agent access as privileged whenever the agent can call tools, access data, or trigger actions on behalf of users or systems. At that point, it is no longer just software. It is a non-human identity with operational authority and should be governed with the same care as any high-risk credential.

Technical breakdown

Why access-centric attacks outperform app-centric defence

Access-centric attacks work because the attacker does not need to defeat the application itself if they can reuse trusted credentials, tokens, or delegated scopes. In practice, the non-human identity becomes the control point, especially when the same secret is embedded in CI, code, tickets, or SaaS integrations. That creates an identity graph problem, not just a vulnerability problem. Defenders need to know which machine identities exist, where their credentials live, and what systems they can reach. Once those permissions are broad or shared, a single compromise can produce lateral movement across cloud, SaaS, and build systems.

Practical implication: Practical implication: map non-human identity ownership and effective privilege before an exposed secret becomes an access path.

How agentic AI changes attacker tradecraft

Agentic AI changes attacker tradecraft by compressing the time between discovery and action. Instead of a human analyst manually chaining recon, triage, credential harvesting, and follow-on exploitation, an agent can run many of those steps with limited supervision. That does not create a new class of attack by itself, but it does lower the cost of persistence and scale. The security consequence is that exposure windows matter more, and validation needs to be continuous. If a token is public for minutes, not days, the response model must assume machine-speed abuse.

Practical implication: Practical implication: shorten exposure windows and automate revocation workflows for secrets and tokens.

OAuth-connected apps as delegated non-human identities

OAuth-connected apps behave like delegated non-human identities because they inherit approved scopes and can operate with legitimate access until their tokens are abused. That makes them especially difficult to distinguish from normal business activity if monitoring is only looking for failed logins or human anomalies. The architectural failure is trust without enough downstream constraint. Security teams need to treat consented integrations as privileged machine identities with explicit scope review, ownership, and offboarding controls. Otherwise, a compromised third-party app can become a distributed skeleton key across customer environments.

Practical implication: Practical implication: review connected-app scopes and revoke stale integrations before they expand your attack surface.

Threat narrative

Attacker objective: The attacker’s objective is to turn trusted non-human access into scalable, low-friction control over cloud, SaaS, and build environments.

1. Entry occurs when exposed tokens, secrets, or delegated OAuth credentials are discovered in developer, SaaS, or CI environments.
2. Escalation follows when the attacker uses those machine credentials to move through trusted APIs and integration scopes without triggering normal user-centric controls.
3. Impact occurs when the attacker harvests more secrets, expands access, and exfiltrates data across multiple systems using the same inherited trust.

NHI Mgmt Group analysis

Access has become the primary security boundary for NHI programmes. Attackers increasingly prefer trusted credentials over noisy application exploitation because machine identities are easier to reuse at scale. That shifts the real control question to ownership, scope, and revocation of secrets and delegated access. Practitioners should treat every non-human credential as a perimeter asset, not a convenience artifact.

Ephemeral credential trust debt is now a core governance problem. The shorter the credential lifetime, the more attractive it looks on paper, but rapid automation also means exposure can be exploited before human review catches up. The issue is not whether ephemeral access is good or bad, but whether organisations can observe, revoke, and constrain it in time. Teams should measure their recovery speed against attacker speed, not policy intent.

AI-assisted abuse collapses the window between discovery and compromise. The operational impact is that secrets handling, CI hygiene, and OAuth governance can no longer sit in separate workstreams. They are one identity problem with different surfaces. Security leaders should integrate detection, rotation, and access review across those surfaces instead of optimizing each in isolation.

Shared machine credentials create identity blast radius, not just access sprawl. When one secret is reused across multiple applications, a single exposure can translate into systemic compromise. That makes blast-radius reduction the first governance objective, because shared access turns a local hygiene issue into an enterprise control failure. Practitioners should minimise credential reuse and enforce distinct identities for distinct workloads.

OAuth-connected apps need the same scrutiny as privileged service accounts. Consent does not equal safety when scopes remain broad and offboarding is weak. The practical standard is explicit ownership, documented purpose, scope minimisation, and periodic access review. If an integration cannot pass that test, it should be treated as a latent compromise path.

From our research:

• 60% of NHIs are being overused, with the same NHI utilised by more than one application, increasing the risk of widespread compromise if exposed, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to the same report.
• For lifecycle controls that reduce residual access, see Ultimate Guide to NHIs and align offboarding with continuous access review.

What this signals

Identity blast radius is becoming the right planning unit for NHI programmes. The question is no longer whether a secret can be stolen, but how far that secret can move once it is reused across systems. With 44% of NHI tokens exposed in the wild, according to The 2025 State of NHIs and Secrets in Cybersecurity, the control gap is structural rather than incidental.

Security teams should expect AI-assisted abuse to compress the time available for human response. That means lifecycle controls, revocation automation, and connected-app governance need to be measured in operational minutes, not policy cycles. The programme that cannot see its own non-human access will not be able to contain it.

Secret sprawl is now an access management problem, not just a storage problem. Once secrets are duplicated across tickets, code, and collaboration tools, they become distributed credentials with multiple failure points. The next maturity step is to connect discovery, ownership, and revocation into one control loop, not three separate processes.

For practitioners

• Audit all non-human credential locations Inventory tokens, API keys, certificates, and OAuth grants across code repositories, CI systems, ticketing platforms, and collaboration tools. Prioritise any credential that is duplicated or lacks clear ownership, because those are the fastest paths to broad compromise.
• Shorten exposure windows for secrets and tokens Automate detection and revocation so that publicly exposed credentials are invalidated within minutes, not days. Tie revocation to build pipelines, SaaS integrations, and offboarding workflows so remediation does not depend on manual triage.
• Review delegated app scopes quarterly Treat OAuth-connected apps as privileged machine identities and validate their scopes, owners, and business purpose on a fixed cadence. Remove stale integrations and narrow permissions wherever the app does not require broad data-plane access.
• Separate machine identities by workload Assign distinct credentials to distinct applications and services so one compromised secret cannot unlock multiple systems. Reduce shared access by enforcing workload-specific identity boundaries and tracking downstream reach for each credential.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

Key takeaways

• Non-human identities now sit at the centre of attacker tradecraft because trusted access is easier to abuse than applications are to break.
• Credential reuse and delegated app scopes expand blast radius, which makes lifecycle control the primary defence objective.
• Teams that cannot discover, own, and revoke machine credentials quickly will struggle to contain AI-accelerated attacks.

Key terms

• Non-Human Identity: A non-human identity is a machine credential used by software, services, or agents to authenticate and act in an environment. It can be a token, key, certificate, service account, or delegated app. In practice, these identities deserve lifecycle controls because they often hold real production access.
• Identity Blast Radius: Identity blast radius is the amount of access that can be reached if one credential, token, or delegated app is compromised. The wider the blast radius, the more systems, data, and workflows an attacker can inherit from a single trust boundary. Reducing it is a core NHI governance objective.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

What's in the full article

The vendor's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how attackers harvested secrets from npm install flows and CI environments
• Specific incident breakdowns showing how OAuth tokens became authenticated access paths in SaaS
• The vendor's incident handling questions for exposed secrets, token revocation, and post-disclosure validation
• Additional context on the separate AI-orchestrated espionage case and the techniques used across the operation

👉 The full Entro Security article includes the incident walkthroughs and response details behind these 2025 examples

Deepen your knowledge

AI agent access governance and secret lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with exposed tokens, OAuth apps, or shared machine credentials, this is a practical place to start.