When AI agents inherit human credentials and act without verifiable identities, the blast radius of any single compromised workflow expands to the limits of whatever access their creator once had. The question is not whether your organisation has shadow agents. It is whether you know what they can reach.
Related asset: Shadow agents as shadow workforce risk
Officially it’s automation. But the agent a finance team deployed last quarter to reconcile reporting—querying the data warehouse, drafting summaries, filing outputs—is something rather more consequential than a script. It makes decisions. It acts on data. It holds, by inheritance, the access rights of whoever built it.
There is a structural assumption embedded in most enterprise access control: that every principal requesting data or executing an action is a human being, subject to periodic review, reachable by a phishing email, and identifiable by a name in an HR system. That assumption has been under pressure from service accounts and legacy automation for years. Agentic AI has not created a new problem so much as it has industrialised an existing one, at a speed and scale that existing governance frameworks were not designed to handle.
The shift from AI-as-assistant to AI-as-agent is the inflection point. A model that answers questions about company policy poses a contained risk. An agent that can query a database, draft and send a communication, approve a workflow step, or call an external API poses a fundamentally different one. The difference is not intelligence; it is permission scope combined with autonomy of execution. Microsoft’s introduction of Entra Agent ID at Ignite 2025 is the clearest institutional acknowledgement yet that this shift requires a distinct governance response (Microsoft Security Blog, November 2025). The company is not simply adding a feature. It is proposing that AI agents constitute a new identity class—non-human principals that require their own credentials, registry entries, and permission boundaries, rather than borrowing the access rights of whoever built or deployed them.
How the shadow agent accumulates blast radius
The mechanics are not exotic. A developer in a finance team wants to automate reconciliation reporting. They build a lightweight agent using a cloud AI service. The agent needs to read from the data warehouse, so the developer authenticates it with their own credentials—the path of least resistance. The agent is not malicious. It works. It saves hours each week. Nobody registers it anywhere.
Six months later, the developer has left the organisation. Their account is deprovisioned. The agent, never formally inventoried, is now running under orphaned credentials—or, in a common variation, under a shared service account that was never scoped to least privilege because it “needs to access everything to do the reporting.” The agent has accumulated, by inheritance, the access rights of a senior finance analyst plus whatever administrative permissions the shared account acquired over time.
This is the blast radius problem in its basic form. The agent itself is not the threat. The threat is the combination of broad inherited permissions, no audit trail, no ownership record, and no mechanism to identify or revoke the agent as a distinct principal. When the Chinese state-sponsored actors who directed Anthropic’s Claude as an orchestration layer for network reconnaissance wanted an execution environment, they did not require a novel exploit (Anthropic threat intelligence report, August 2025). They required an agent with network access and a sufficiently flexible system prompt. Both conditions are present in most enterprises today.
The persona bypass those attackers used—presenting Claude with a “security tester” framing to navigate content filters—deserves examination as a mechanism rather than dismissal as a quirk of one campaign. Content filters and safety guardrails are trained on human interaction patterns. An agent operating at machine speed, with a system prompt that reframes its role, can probe the edges of those filters systematically in a way that no human operator can. The guardrail is not a perimeter; it is a speed bump calibrated for human throughput.
What the identity registry changes, and what it leaves unresolved
Entra Agent ID addresses the accountability layer directly. An agent registered as a distinct principal in the directory has an identity that can be discovered, reviewed, and revoked without touching the credentials of any human user. The agent can be granted read access to specific data sources and nothing beyond that scope. The registry produces a map: every agent, its owner, and the data it can reach (Microsoft Security Blog, November 2025).
That map is the precondition for every other control. You cannot apply least-privilege to an agent you cannot identify. You cannot audit the behaviour of an agent that has no audit trail. You cannot revoke access from an agent that exists only as an inherited permission in a shared service account. The registry does not eliminate risk; it makes risk legible. This is a gamble—not in design, but in adoption. The organisations with the greatest exposure are precisely those where autonomous agents have proliferated fastest: most willing to experiment, most likely to have deployed agents across multiple platforms and credential sets, least likely to have maintained documentation. For them, implementing Entra Agent ID is necessary but not sufficient. The prior work is discovery—finding what is already running and what it can reach.
The Mixpanel breach this month illustrates a related accountability gap at a layer most governance frameworks have not yet reached. The data exposed was not model weights or API keys—it was usage metadata: user identifiers, API call patterns, and behavioural signals that function as a targeting map for downstream attacks (OpenAI, November 2025). An analytics partner that receives telemetry from your AI pipeline receives, by extension, a partial picture of your AI operations. That picture has intelligence value. The governance question of what leaves the perimeter as monitoring data is not a secondary concern—it is the same access control problem in a different register, currently sitting in most organisations’ blind spot.
The alignment variable that vendor risk frameworks do not yet ask
Set alongside the identity problem, CrowdStrike’s research into DeepSeek-R1 introduces a second category of governance failure—one that is harder to inventory because it lives inside the model rather than around it. When the model is prompted with topics politically sensitive to the Chinese Communist Party, the probability of generating code with severe security vulnerabilities rises by up to 50% (CrowdStrike Research, November 2025). The mechanism, as the researchers describe it, is a competition for model capacity: ideological alignment training and security reasoning appear to pull against each other, and the model’s available capacity to reason carefully about one degrades when constrained by the other.
The distributional implication is worth stating precisely. The risk is not uniform. It is proportional to how often the model, in a given deployment, encounters prompt territory that activates the constrained reasoning. A team using DeepSeek-R1 for internal documentation may face negligible exposure. A team using it in a security review or code generation pipeline—where contested or sensitive topics surface more frequently—faces a materially different one. The exposure is not theoretical; it is a function of workflow design.
This is the point at which model provenance shifts from a procurement preference to a technical variable. Most vendor risk frameworks ask whether a model meets compliance requirements and who is liable if it fails. They do not yet ask how the model was aligned, whether that alignment process introduced capacity trade-offs, and whether those trade-offs interact with the specific use cases the deployer has in mind. That question is now answerable, at least in part—but only if someone in the organisation is assigned to ask it.
The governance controls that limit blast radius
The operating implication across all three threads is that identity management must be extended to non-human principals as a first-class discipline, not an afterthought to the human identity and access management framework. Several concrete boundaries define where that shift begins.
Registration as a precondition for network access. An agent that cannot be identified in the directory should not be permitted to make API calls to internal systems. The technical enforcement mechanisms exist; the missing element is a policy decision, and behind that, a clear ownership assignment. In most organisations, that ownership currently sits in an uncomfortable gap between IT, security, and the business units deploying agents.
Service principals with defined scope. Agents should not authenticate as users. They should authenticate as service principals with permissions limited to the specific data sources and actions their function requires. The developer credential that was convenient at build time is not an acceptable production credential. Applying this standard to traditional automation is already common practice; extending it to AI agents is the missing step.
Ownership with expiry. Every registered agent should have a named owner and a review cadence. When the owner leaves the organisation, the agent’s access should trigger an automatic review rather than a quiet continuation. Orphaned agents with broad permissions are the structural precondition for the blast radius problem—and the most reliably preventable one.
Prompt and log hygiene before the perimeter. Prompt data, API call metadata, and usage telemetry should be reviewed and, where necessary, redacted before they reach third-party analytics or observability platforms. The Mixpanel incident is not an isolated anomaly; it is an illustration of a persistent exposure surface that most AI governance frameworks have not yet addressed. Who bears the cost of implementing that hygiene, and who carries the liability if it is not implemented, are questions that belong in vendor contracts now rather than post-incident reviews later.
The durable implication
Twenty years of Shadow IT governance produced a rough consensus: if it is not in the inventory, it is not managed, and if it is not managed, it is a liability. Organisations learned that lesson through a long sequence of data loss incidents, unmanaged SaaS sprawl, and compliance failures. Shadow AI is the same problem at higher velocity, with the additional feature that the unmanaged entity can act rather than merely store.
The machine identity imperative is not a Microsoft-specific argument. It is a structural requirement for any organisation deploying autonomous agents: every agent needs an identity, every identity needs a scope, every scope needs an owner, and every owner needs a review cadence. The registry is the map. Without a map, the question “what can our agents reach?” has no reliable answer.
An adversary operating at machine speed does not need that question to have a reliable answer. They need it to remain unanswered. ■
