April identity attacks exposed new AI agent governance gaps

At a glance

What this is: This is an identity-risk analysis of April attack patterns, with the key finding that attackers increasingly treated AI configuration files, machine identities, and credential stores as privileged access points.

Why it matters: It matters because IAM, NHI, and human identity programmes all need to govern execution paths and credential artifacts, not just logins and password-based access.

By the numbers:

• April saw 5,372 CVEs disclosed industry wide.
• Of those, 439 were identity-related and 41 directly impacted identity products.
• Bitwarden is used by over 10 million users and 50,000 businesses.

👉 Read Delinea's threat report on how April attacks changed identity risk

Context

Identity risk now extends to configuration files, pipeline tokens, and machine credentials that behave like access keys even when teams do not treat them that way. In April, the source article says attackers targeted AI assistant configs, credential stores, and service account tokens because those artifacts control execution, not just authentication.

For IAM and NHI teams, the gap is structural: governance often stops at the login event, while attackers are operating on the control plane, the build pipeline, and the credential layer. That means identity programmes need to classify AI configuration artifacts, service accounts, and privileged tokens as governed identities, not auxiliary files.

Key questions

Q: How should security teams govern AI configuration files that contain credentials?

A: Treat them as sensitive identity artifacts, not ordinary application files. Inventory where API tokens, server definitions, and authentication endpoints live, restrict who can read them, and bring them into the same review and rotation process used for secrets and service accounts. If a file authorises an agent to reach production systems, it belongs in identity governance.

Q: Why do service account tokens increase lateral movement risk?

A: Because they authenticate as valid identities without human interaction and often carry access that persists beyond the original task. If the token is over-scoped or poorly monitored, an attacker can reuse it across systems and clouds while appearing authorised. The risk grows when teams treat service accounts as infrastructure details instead of governed identities.

Q: What breaks when identity governance stops at login events?

A: Teams lose visibility into the actions that happen after authentication, including token reuse, secret harvesting, and privilege escalation. Attackers increasingly operate through valid identities, so the compromise may never look like a failed login. Governance has to extend into execution, privilege use, and artifact handling.

Q: Should organisations prioritise AI agent settings or service account cleanup first?

A: Start with whichever set of artifacts currently grants broader or less visible access, but do not separate them into different programmes. AI settings files, pipeline tokens, and service accounts can all become enterprise access paths, so the right approach is to govern them under one identity risk model with consistent inventory, classification, and review.

Technical breakdown

Why control plane compromise changes identity risk

A control plane is the layer that decides what identities, tokens, and policies can do across systems. When attackers reach that layer through a trusted CI/CD path or a misused identity artifact, they do not need to break each target individually. They inherit the trust relationships already built into the environment. In this article’s example, a compromised machine identity in a pipeline was enough to publish malicious software and harvest secrets at scale. The technical lesson is that identity abuse often begins upstream of the workload, in the systems that mint, store, or distribute credentials.

Practical implication: Treat pipeline identities and credential brokers as governed access paths, not just supporting infrastructure.

Why AI assistant configuration files behave like secrets

Claude MCP configs and similar AI settings files can contain API tokens, server definitions, and authentication endpoints. That makes them identity artifacts, because they authorise how an agent reaches tools and data sources. If an attacker steals the file, they often gain the same practical access that an exposed secret would provide. The important distinction is that the risk is not the AI model itself, but the file that binds the model to real enterprise systems. This is the same governance problem as hardcoded secrets, but in a newer form factor.

Practical implication: Inventory AI configuration files as sensitive credentials and move them under the same protection as API keys and tokens.

Why service account tokens enable lateral movement

Service accounts are non-human identities that authenticate without user interaction, so they can bypass MFA and move across cloud environments with standing permissions. If those tokens are over-scoped or left unreviewed, attackers can pivot from one environment to another without triggering human access workflows. The article’s cloud examples fit a common pattern: once the token is valid, the attacker operates as an authorised entity, not as a noisy intruder. That is why NHI governance must focus on scope, rotation, and observability rather than only on initial compromise.

Practical implication: Map every service account token to its reachable systems and remove standing privileges that support lateral movement.

Threat narrative

Attacker objective: The objective is to convert trusted identity artifacts into broad enterprise access, then use that access to harvest more credentials, move laterally, and apply extortion or infrastructure disruption.

1. Entry occurs when attackers compromise a trusted machine identity or supply chain path and gain access to credential-bearing artifacts such as pipeline tokens or AI configuration files.
2. Escalation happens when harvested secrets, service account tokens, or auth endpoints are reused to move from a local compromise into enterprise control paths and cloud access.
3. Impact follows when those identities are used to exfiltrate credentials, pivot into production systems, and turn identity control into ransomware leverage or broader infrastructure access.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Identity control plane exposure is now the real attack surface. The article shows attackers targeting trusted build paths, token stores, and configuration artifacts instead of only endpoint payloads. That shifts the governance problem from protecting systems at login to protecting the machinery that creates and distributes privilege. Practitioners should read this as a control-plane security problem, not a malware problem.

AI assistant configuration files are privileged identities in disguise. Claude MCP configs and similar settings files contain the credentials and endpoints that let an agent reach enterprise systems. Once those files are handled outside identity governance, organisations create a new class of unmanaged access artifact. The implication is that AI configuration files belong in the same governance model as service accounts and API keys.

Standing privilege remains the accelerant behind supply chain abuse. The campaign path described in the article depended on access that outlived the moment of creation and could be reused across tools and clouds. That is the same structural weakness that appears in NHI sprawl, over-scoped tokens, and weak rotation discipline. Security teams should treat standing privilege as the force multiplier, not the initial exploit.

Governance that stops at authentication is already obsolete. The source article makes clear that attackers are exploiting what happens after identity is accepted, including privileged behavior, lateral movement, and token reuse. That means identity security has to cover execution paths, not just entry points. The discipline now spans IAM, PAM, and NHI controls across the full trust chain.

Ephemeral credential trust debt: credentials are being consumed faster than programmes can govern them. Short-lived access does not help if teams cannot inventory, classify, and monitor the artifacts that grant that access in the first place. The article’s evidence shows that AI configs, service account tokens, and pipeline identities are being treated as disposable by attackers but not by governance teams. Practitioners should view this as a backlog in identity classification, not only a detection gap.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why unmanaged machine identities stay operational long after teams think they are contained.
• Read 52 NHI Breaches Analysis for real-world root cause patterns that show how identity failures compound across cloud and supply chain environments.

What this signals

Control-plane governance is becoming the deciding variable for identity programmes. The immediate programme risk is not simply more secrets, but more identities hidden inside build systems, AI settings, and delegated automation paths. Teams that still segment IAM, PAM, and NHI work streams will miss the shared failure mode.

The governance signal is that visibility, classification, and revocation have to move upstream into the places where access artifacts are created. Without that, identity controls react after the fact while attackers operate inside valid trust chains.

For practitioners

• Classify AI configuration files as governed identity artifacts Move MCP configs, agent settings, and token-bearing files into the same control set used for secrets, service accounts, and privileged credentials.
• Review pipeline identities as part of access governance Inventory GitHub Actions, CI/CD tokens, and third-party build identities, then verify who can publish packages, trigger workflows, and access cloud secrets.
• Reduce standing privilege on service accounts Scope cloud and Kubernetes service accounts to the minimum required resources, and rotate or revoke tokens that remain valid beyond the task window.
• Monitor post-authentication privilege behavior Detect abnormal token reuse, cross-environment access, and secret harvesting after login, because the initial compromise often looks legitimate.

Key takeaways

• April’s attack patterns show identity control planes and AI configuration artifacts being used as enterprise access points, not just supporting files.
• The scale of the problem is already measurable, with thousands of CVEs and a large share of identity-related weaknesses reinforcing the same governance gap.
• Security teams need one identity model for service accounts, pipeline tokens, and AI settings files, because the attacker sees them all as privilege-bearing artifacts.

Key terms

• Control plane: The control plane is the layer that decides who or what can reach systems, issue commands, or change policy. In identity security, it includes the services and workflows that mint, distribute, or authorize access artifacts, which makes it a high-value target when attackers want broad and trusted access.
• AI configuration artifact: An AI configuration artifact is any file or settings object that binds an agent to tools, servers, or credentials. These artifacts matter because they can contain authentication endpoints, API tokens, or operational context, turning a seemingly harmless config file into a governed access path.
• Standing privilege: Standing privilege is access that remains available beyond the moment it is needed. In NHI governance, it creates persistent exposure for service accounts, tokens, and pipeline identities, especially when teams do not review scope or revoke access promptly after the task is complete.
• Post-authentication behaviour: Post-authentication behaviour is what an identity does after access has been accepted. For machine and AI identities, that includes token reuse, secret retrieval, lateral movement, and policy deviation, which means defenders must watch execution patterns, not only login outcomes.

Deepen your knowledge

Identity control planes, AI configuration files, and service account governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a programme around the same trust paths, it is worth exploring.

This post draws on content published by Delinea: How April’s attacks redefined identity risk. Read the original.