Shadow AI governance fails when identity behavior is invisible

At a glance

What this is: This is an analysis of why shadow AI governance breaks when teams rely on discovery instead of behavior, and why identity activity is the real control point.

Why it matters: It matters because IAM, PAM, and NHI programmes must judge access patterns, not just approved tooling, or they will miss sanctioned abuse, AI agent drift, and takeover-like activity.

By the numbers:

• In 2025, 1.27 million hardcoded AI-service credentials were exposed in public repos, roughly one every 25 seconds all year.

👉 Read Abnormal AI's analysis of shadow AI governance and identity behaviour

Context

Shadow AI governance is the problem of discovering, classifying, and controlling AI tools, agents, and the identities they use. The core failure is assuming that inventory equals control. In practice, a tool can be sanctioned, unsanctioned, or invisible, while the real security signal is whether the identity behind it is accessing data, chaining actions, or behaving outside its normal pattern.

For IAM and security teams, this shifts the question from what is installed to what is happening at runtime. A passive discovery list does not show whether an AI agent is touching unfamiliar systems, whether a user account is being abused through a rogue installer, or whether a sanctioned identity is behaving like a takeover in progress. That is why behavior must sit alongside governance, not after it.

Key questions

Q: How should security teams govern shadow AI without relying on discovery alone?

A: Security teams should use discovery as the starting point, then combine it with runtime identity telemetry. The goal is to see whether a sanctioned or unsanctioned tool is actually touching data, chaining actions, or behaving outside its normal pattern. Discovery without behaviour monitoring leaves the highest-risk activity invisible.

Q: Why do hardcoded AI credentials create more risk than ordinary code mistakes?

A: Hardcoded AI credentials are risky because they become standing identity paths when exposed, especially in public repositories. Attackers can test and reuse them quickly, long after the original developer has forgotten they exist. The issue is not just leakage, but durable access with no natural expiry.

Q: What do teams get wrong about AI agents and account takeover detection?

A: Teams often apply human-centric anomaly detection to machine actors, which misses how AI agents actually behave. AI agents can access unfamiliar systems, move quickly, and do so without human timing patterns. If the model only understands human behaviour, it can misclassify legitimate AI activity or miss abuse entirely.

Q: Who is accountable when a sanctioned AI tool causes a data breach?

A: Accountability should sit with the owner of the identity and permissions behind the tool, not only the team that approved the application. If a sanctioned AI workflow can reach sensitive data, the organisation must govern its access path, logging, and containment as rigorously as any other high-risk identity.

Technical breakdown

Why discovery-based shadow AI control misses the real risk

Discovery tools tell you which AI applications, browser extensions, or local utilities exist in the environment. They do not tell you whether those tools are actively accessing files, credentials, or customer data. That gap matters because identity risk is behavioural, not just installed-state based. A sanctioned tool can be used to move laterally, and an unsanctioned tool can sit idle. In both cases, the exposure depends on runtime activity, not the software label. Practical security decisions need telemetry from identity, endpoint, and data access layers together.

Practical implication: combine discovery with runtime identity monitoring so you can detect misuse after installation, not just inventory it.

How hardcoded AI credentials turn developer convenience into identity exposure

Hardcoded AI-service credentials in public repositories are a classic NHI failure mode. A secret pasted into code, installer logic, or sample configuration can be harvested automatically and used long after the original author forgets it exists. The problem is not just leakage, but durability: once exposed, the credential becomes a standing identity path that attackers can reuse, share, or test at scale. This is especially dangerous when the credential reaches systems with broad data access or indirect privilege.

Practical implication: treat exposed AI-service credentials as active identities and revoke them immediately rather than waiting for downstream evidence of abuse.

Why AI agent access can look like account takeover under legacy detection

Legacy detection logic often assumes a human actor with stable working hours, consistent navigation, and familiar system sequences. AI agents break that model because they can move across systems quickly, access unfamiliar data sets, and do so without the telltale signals tied to human behaviour. That makes them easy to misclassify as account takeover, or worse, to miss because they do not match human baselines. The operational issue is not just false positives. It is that the detection model may not recognise legitimate but risky non-human behaviour at all.

Practical implication: update detection rules to baseline identity behaviour by actor type so AI-driven access does not disappear inside human-centric anomaly logic.

Threat narrative

Attacker objective: The attacker aimed to gain durable internal access and exfiltrate high-volume business data without detection.

1. Entry occurred when an employee downloaded a free AI art tool from a public code repository, and the installer contained an infostealer.
2. Credential access followed as the attacker used the foothold to persist inside the environment and observe activity long enough to extract data at scale.
3. Impact came when the intruder exited with 1.1 terabytes of information, including 44 million internal chat messages, 18,800 spreadsheets, and 13,000 PDFs.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Behavioral shadow AI governance is now more important than discovery alone: inventory tells you what exists, but not whether an identity is actively misusing access. That distinction matters because the risk sits in runtime behaviour, especially when sanctioned and unsanctioned tools can both reach sensitive data. Discovery remains useful, but it is no longer a sufficient control boundary. Practitioners should treat behaviour as the primary governance signal.

Hardcoded AI-service credentials create standing identity paths that outlive the workflow that exposed them: once a secret is pasted into a repository or installer, the exposure becomes a reusable access mechanism rather than a one-time mistake. That is why public-repo secret leakage is an NHI governance problem, not just a development hygiene problem. The implication is that credential lifecycle, not only code review, determines blast radius.

AI agent access requires a different trust model than human-centric anomaly detection: most legacy controls assume a person behind the keyboard with familiar hours, predictable paths, and stable intent. That assumption breaks when software identities can touch unfamiliar systems at machine speed without obvious human cues. The implication is that identity programmes must classify behaviour by actor type, or they will misread legitimate automation as compromise and genuine compromise as normality.

Identity blast radius is the right concept for shadow AI governance: the security question is not whether a tool is approved, but how far an identity can move if it is abused. The Fortune 50 case shows that a single foothold can translate into months of persistence and massive exfiltration when privilege, data access, and detection coverage are misaligned. Practitioners should measure how much damage one identity can reach before containment begins.

Shadow AI governance fails when programme owners confuse tooling approval with access accountability: an allowed application can still represent unacceptable risk if it can reach customer data, internal chat systems, or privileged back-end services. The governance gap is not only discovery, it is ownership of the identities and permissions behind each AI workflow. Practitioners should map accountability to the identity, not the app label.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, including 46% confirmed and 26% suspected.
• 52 NHI Breaches Analysis shows how credential exposure and privilege sprawl combine into repeated compromise patterns across environments.

What this signals

Identity programme owners should expect shadow AI to behave like an NHI governance problem, not just a discovery problem. A tool list does not expose runtime access, and runtime access is where the risk lives. The stronger operating model is to combine endpoint discovery, identity telemetry, and data-access monitoring so you can see whether an actor is actually crossing policy boundaries.

AI agents and rogue installers now sit in the same decision space as service accounts and tokens. Once exposed credentials are in play, the issue becomes lifecycle control, revocation speed, and containment of reach. That is why NHI programmes need to own AI-service secrets, not leave them split across developer tooling and ad hoc reviews.

Shadow AI expands the identity attack surface faster than most programmes can inventory it. Gartner projects more than 150,000 AI agents inside the average Fortune 500 by 2028, up from fewer than 15 today, which means governance designed for occasional exceptions will not scale. The practical response is to treat every new AI workflow as an identity with measurable blast radius.

For practitioners

• Correlate discovery with identity activity Pair AI tool discovery with logs for file access, API calls, and unusual session timing so sanctioned and unsanctioned behaviour are evaluated together. A discovered tool that is idle is not the same risk as a sanctioned identity exporting data at 3 a.m.
• Treat exposed AI credentials as live identities Search public repositories, sample projects, and installer packages for hardcoded AI-service credentials, then revoke and rotate anything exposed before waiting for evidence of abuse. The key control is rapid secret invalidation, not post-incident cleanup.
• Baseline non-human behaviour separately from human users Build detection profiles that distinguish humans, service accounts, and AI agents so machine-speed access to unfamiliar systems is not automatically treated as noise or generic takeover activity. Different actor types need different normal ranges.
• Map privilege to the data an identity can reach Review whether AI tools or agents can access full customer, finance, or engineering datasets without task-specific restriction. If they can, reduce the reachable dataset and isolate high-value repositories behind explicit approval paths.

Key takeaways

• Discovery alone cannot govern shadow AI because the real risk is runtime identity behaviour, not the installed application list.
• Hardcoded AI-service credentials turn convenience into standing access, which is why secret exposure must be treated as active identity risk.
• Behaviour-based controls, actor-specific baselines, and fast secret revocation are now core requirements for AI and NHI governance.

Key terms

• Shadow AI: Shadow AI is AI software or AI-enabled access that operates outside formal governance, visibility, or approval. In practice it can include unsanctioned tools, hidden agents, or approved tools used in untracked ways. The security issue is not the label but the uncontrolled identity and data access path behind it.
• Hardcoded Credential: A hardcoded credential is a secret embedded directly into code, installers, configuration files, or sample assets instead of being stored in a managed secret system. Once exposed, it becomes a reusable identity path that attackers can harvest, replay, and abuse until it is revoked.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, and business process exposure an identity can reach before containment occurs. It is a practical measure of privilege scope, access adjacency, and monitoring coverage. Smaller blast radius means fewer reachable assets and less damage if the identity is abused.
• Behavioural Baseline: A behavioural baseline is the normal pattern used to distinguish expected identity activity from suspicious activity. For AI agents and service identities, the baseline should consider timing, system access, and data movement rather than human work hours alone. Good baselines are actor-specific, not one-size-fits-all.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 governance in your organisation, it is worth exploring.

This post draws on content published by Abnormal AI: Key Insights on shadow AI governance and AI identity behaviour. Read the original.