What BodySnatcher Teaches Us About the Agent Identity Gap

Tim WilliamsJanuary 19, 2026

The ServiceNow vulnerability isn’t a cautionary tale about one company’s mistake. It’s a preview of what happens when we build agent infrastructure without identity-first architecture.

Tim Williams — CEO and Cofounder — AstraSync AI

The Discovery

Last week, AppOmni’s security research team published their findings on CVE-2025–12420, which they’ve dubbed “BodySnatcher.” It’s being called the most severe AI-driven security vulnerability discovered to date, and the label is warranted.

The exploit chain allowed an unauthenticated attacker to impersonate any ServiceNow user, including administrators, using nothing more than an email address. From there, they could execute AI agents with that user’s full privileges. AppOmni’s proof-of-concept demonstrated the creation of a backdoor admin account, role assignment, password reset, and complete platform access.

What makes this significant isn’t the specific technical flaw. It’s what the vulnerability reveals about the assumptions baked into how we’re building agent infrastructure across the industry.

The Trust Assumption Problem

The vulnerability stemmed from a collision of two design decisions that, individually, seemed reasonable.

ServiceNow’s Virtual Agent API used message authentication with a shared secret to validate incoming requests from external integrations. This simplified the developer experience for chatbot integrations, which is a legitimate goal. The auto-linking logic for AI agent providers trusted email addresses as sufficient proof of identity. If you supplied the shared token and a valid email, you were linked to that ServiceNow account. No MFA challenge. No verification that you actually controlled that email.

These choices made sense in the context of bot-to-bot communication, where the chatbot integration itself was the trust boundary. When ServiceNow extended this infrastructure to support AI agents, which can execute privileged workflows, create records, and take autonomous actions, the trust model didn’t evolve with the capability model.

As AppOmni’s Aaron Costello noted in his analysis: these were “point-in-time fixes” to a systemic architectural gap.

This Isn’t About Blame

It’s tempting to frame this as a ServiceNow failure. It isn’t.

ServiceNow responded within a week of disclosure, patched the vulnerability, notified customers, and credited the researchers publicly. That’s exactly how responsible disclosure should work.

More importantly, the patterns that enabled BodySnatcher aren’t unique to ServiceNow. They’re present across the industry:

Retrofitted authentication models. Platforms adding agentic capabilities to infrastructure designed for different trust assumptions.

Email as identity proxy. Systems treating “knows email address” as equivalent to “is that person.”

Shared secrets at scale. Authentication tokens that work across all customer instances.

Implicit trust in internal channels. Assumptions that messages arriving through “internal” APIs are already verified.

Any organisation building agent infrastructure today could make similar choices. The question isn’t whether human error will occur. It’s whether our architecture assumes it will and mitigates accordingly.

The Agent Identity Gap

BodySnatcher exploited what we at AstraSync call the “identity gap” in agent infrastructure.

Traditional identity systems answer the question: “Is this human who they claim to be?” They do this reasonably well through SSO, MFA, and identity providers.

Agent-to-agent communication introduces new questions these systems weren’t designed to answer:

Agent provenance. Who built this agent? What organisation owns it?

Capability verification. What is this agent authorised to do right now?

Runtime attestation. Is this the same agent that was verified yesterday, or has it drifted?

Trust chain integrity. Can I verify the full chain from developer to deployment?

In BodySnatcher, the attacker didn’t compromise a user’s credentials. They exploited a gap in how agent identity was established and verified. The platform had no way to distinguish between a legitimate AI agent integration acting on behalf of an authenticated user and an attacker who knew the shared secret and an email address.

This distinction matters because it determines what mitigations are effective. Better secrets don’t solve the problem. Better identity architecture does.

Why “Better MFA” Isn’t the Answer

AppOmni’s primary recommendation is to “require MFA when using account linking.” This would have made BodySnatcher harder to execute. It doesn’t address the structural problem.

Account linking assumes that agents should operate by impersonating human identities. The agent claims to be User X, the platform verifies that claim, and the agent then operates with User X’s privileges.

This model is fundamentally wrong for agentic systems.

Agents aren’t humans. They shouldn’t impersonate humans. They should have their own identities with explicit, verifiable delegation from humans who authorise their actions.

Consider what a proper trust model looks like:

Know Your Developer (KYD). Who built this agent? Are they verified? What’s their track record?

Know Your Owner (KYO). What organisation is responsible for this agent’s actions?

Know Your Agent (KYA). What is this agent’s unique identity? What are its declared capabilities and constraints?

Know Your Instructor (KYI). Who is directing this agent right now? Are they authorised to do so?

Counterparty verification. Can I, as the system being accessed, independently verify all of the above?

Under this model, an attacker with an email address gets nothing. They can’t claim to be an agent because they don’t have the agent’s cryptographic identity. They can’t claim instructor authority because the delegation chain is verified. They can’t exceed the agent’s PDLSS constraints because those are immutable and enforced by the counterparty.

Immutable Constraints: The Missing Layer

BodySnatcher’s AI agent could create records in arbitrary tables because its tools had no effective boundaries. AppOmni notes that the “Create the Record” tool was configured to run with “human supervision,” requiring confirmation before proceeding. The attacker simply sent a confirmation message.

This illustrates why configuration-based security fails. If the constraint exists within the agent’s context, it can be circumvented through that context.

We propose a different approach: PDLSS constraints that are cryptographically recorded at registration and independently verifiable by any counterparty.

Purpose. What category of actions is the agent authorised to perform?

Duration. For how long are the agent’s permissions valid?

Limit. What quantitative constraints apply? Maximum transaction values, API call rates, data volumes.

Scope. What specific resources can the agent access?

Self-instantiation. Can the agent create sub-agents, and under what constraints?

These constraints are not suggestions within the agent’s context. They are external boundaries that counterparties verify and enforce. A compromised agent remains bound by its declared PDLSS parameters because the counterparty won’t accept requests that exceed them.

Had PDLSS constraints been in place, the BodySnatcher attacker might have controlled an agent, but that agent couldn’t have created admin accounts if its Purpose excluded user management, couldn’t have operated for days if its Duration was measured in hours, and couldn’t have accessed the user table if its Scope was limited to specific resources.

The Regulatory Context

BodySnatcher arrived at a relevant moment.

The EU AI Act’s enforcement begins in August 2026. Among its requirements for high-risk AI systems: traceability, human oversight, and the ability to identify AI systems throughout their lifecycle.

If an AI agent can impersonate any user and take autonomous actions without leaving a verifiable audit trail, how does an organisation demonstrate compliance? How do they prove, after an incident, which agent took which action and under whose authority?

These aren’t theoretical questions. They’re the compliance requirements that enterprises are now working to address. BodySnatcher demonstrates why “we configured our platform correctly” isn’t a sufficient answer.

Lessons for Builders

For teams building agent infrastructure, BodySnatcher offers concrete lessons:

Audit your trust assumptions. Map every pathway through which an agent can take action. For each pathway, ask: what proof of identity is required? Is it sufficient for the capability being granted?

Don’t retrofit agent auth onto chatbot auth. The trust models are different. Chatbots follow deterministic flows with limited capability. AI agents can execute arbitrary privileged workflows. Design authentication accordingly.

Question the account linking model. Should agents impersonate human identities, or should they have their own identities with explicit delegation? The former is convenient. The latter is secure.

Plan for credential compromise. If your authentication model uses shared secrets, what happens when one leaks? Can you rotate without breaking all integrations? Can you scope the blast radius?

Build with verification, not trust. The principle of zero trust isn’t just for network architecture. Apply it to agent-to-agent communication. Verify every claim, every time.

What Comes Next

BodySnatcher won’t be the last vulnerability of its kind. As AI agents become more capable and more integrated into enterprise workflows, the attack surface expands. The incentives for attackers grow.

The industry’s response will determine whether we spend the next decade playing whack-a-mole with point-in-time patches, or whether we build the identity infrastructure that makes this class of vulnerability structurally difficult.

At AstraSync, we’re building that infrastructure. Not because we think we’re smarter than the teams at ServiceNow or any other platform. We build it because we believe agent identity is a systemic challenge that requires dedicated, protocol-level solutions, not features bolted onto existing authentication models.

AppOmni’s research is a gift to the industry. It shows, in concrete detail, what the agent identity gap looks like when exploited. The question now is what we build in response.

AppOmni’s full technical analysis of CVE-2025–12420 is available at appomni.com/ao-labs. We recommend it for anyone building or securing agent infrastructure.