IdentityMesh shows how agentic systems collapse identity boundaries

At a glance

What this is: IdentityMesh is a lateral movement pattern in agentic systems where one AI agent collapses multiple identities into a single operational entity and crosses system boundaries.

Why it matters: It matters because IAM, NHI, and autonomous governance teams cannot rely on per-system authentication alone when the agent itself becomes the bridge between trusted environments.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Lasso Security's research on IdentityMesh and agentic lateral movement

Context

IdentityMesh is a cross-system attack pattern that appears when an AI agent treats several authenticated tools and applications as one workflow instead of separate trust zones. In practical IAM terms, the problem is not just tool access, but the agent's ability to carry context from one system into another without a fresh authorisation decision.

That model breaks the assumptions behind MCP security, browser session isolation, and conventional delegated access. Once read operations, write operations, and malicious prompt content are combined inside a single agent, the identity boundary becomes the attack surface rather than the protection layer.

Key questions

Q: How should security teams stop AI agents from moving data between trusted systems without approval?

A: Security teams should treat each system boundary as a separate trust decision, even when one agent handles the workflow. Require explicit approval for any action that moves data from one authenticated environment into another, and restrict the agent from writing to downstream systems unless that transfer is separately authorised and logged.

Q: Why do agentic systems create a bigger lateral movement risk than ordinary automation?

A: Agentic systems create bigger lateral movement risk because they can combine read, reasoning, and write actions inside one runtime context. That lets malicious input influence a later action in another system, which turns normal access into cross-system propagation instead of a single isolated task.

Q: What do security teams get wrong about browser-based AI assistants?

A: They often treat browser-based assistants as user interfaces when they are really cross-origin identity mediators. If the assistant can act across authenticated tabs and services, then every downstream move must be governed as a new authorization decision, not as a continuation of the original session.

Q: What is the difference between delegated access and identity fusion in agentic AI?

A: Delegated access is intended and bounded, with clear scope and separate control points. Identity fusion happens when an agent merges several credentials or sessions into one operational entity, so a request in one system can trigger unauthorised action in another without a fresh trust check.

Technical breakdown

How identity mesh forms across MCP and browser sessions

IdentityMesh emerges when an agent binds multiple authenticated systems into one operational context. In MCP architectures, the model layer interprets instructions, the context layer preserves memory, and the protocol layer executes tool calls, but the agent often carries identity state across all three. That means a read from email, a lookup in a knowledge base, and a write into a ticketing system can be treated as one continuous task even when those systems were meant to remain isolated. The result is not credential theft in the classic sense. It is identity fusion, where separate authorisations become one exploitable chain.

Practical implication: Separate system identities and enforce explicit trust boundaries between tools that can read data and tools that can write or export it.

Why indirect prompt injection turns benign input into cross-system action

Indirect prompt injection works because the attacker hides instructions inside content the agent is already authorised to process, such as tickets, emails, or issue comments. The agent does not need to be directly compromised. It simply reads the malicious text as if it were normal workflow input, then reuses that instruction when moving into another authenticated system. This is especially dangerous in multi-tool agents because the attacker is not asking for one action in one place. The attacker is steering an operation path that spans several systems and turns legitimate access into unauthorised propagation.

Practical implication: Inspect any content source that can influence downstream tool use and block agent-driven reuse of untrusted instructions across systems.

Why read and write tools create the lateral movement path

The attack chain depends on a simple but dangerous combination: tools that can read sensitive data and tools that can write, post, or transmit data elsewhere. A read tool exposes the raw material, and a write tool becomes the exfiltration or distribution channel. In the scenarios described, that can mean pulling information from Slack or Notion and then publishing it into GitHub, a support channel, or a public-facing browser action. The security failure is not just broad access. It is the absence of a control that prevents data gathered under one identity context from being repurposed in another.

Practical implication: Classify tools by direction of data flow and restrict cross-system write permissions whenever the source data was gathered under a different trust context.

Threat narrative

Attacker objective: The attacker wants to convert trusted agent activity into unauthorised cross-system movement that leaks data or spreads malicious content.

1. Entry begins when an attacker plants malicious instructions in a ticket, email, GitHub issue, or other trusted external input that the agent will later process.
2. Escalation occurs when the agent reads the content, retains the instructions in context, and uses the user's authenticated access across multiple systems as one merged identity.
3. Impact follows when the agent copies, posts, or exports sensitive information into a different system, enabling data exfiltration, phishing, malware distribution, or remote code execution.
4. The attacker objective is to make a legitimate AI-assisted workflow perform cross-system actions that the user never explicitly authorised.

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

IdentityMesh is not a tool failure, it is a boundary failure. The attack works because the agent treats separate authenticated systems as one operational identity, so the security boundary disappears at runtime. That means the control problem is not only permissions, but the assumption that permissions remain separable once the agent starts chaining read and write actions. Practitioners should treat cross-system identity fusion as a distinct governance problem, not a variant of ordinary access sprawl.

Single-identity thinking is now too weak for agentic workflows. The article shows that the real risk appears when an agent can move from one authenticated context to another without a fresh trust decision. That is a structural issue for MCP, AI browsers, and custom multi-tool agents alike. The implication is that identity governance must stop assuming a stable one-to-one relationship between user intent, system context, and downstream action.

Read access plus write access creates identity blast radius. Once an agent can consume untrusted content and then write into another system, the blast radius is no longer limited to the initial inbox, ticket, or browser tab. This is the named concept that best captures the failure mode: identity mesh means the merged operational entity becomes the transport layer for compromise. Practitioners should map where read and write privileges intersect across agent workflows.

AI browser workflows blur delegated access and direct user action. The browser scenario shows how ordinary authenticated sessions become execution channels for cross-origin misuse when the agent operates in a default-helpful mode. This complicates attribution, monitoring, and policy enforcement because the system action looks like normal user behaviour. Security teams should treat browser-integrated agents as identity mediators, not as simple productivity features.

Conventional authentication does not stop an agent from misusing authorised access. The attack does not depend on stolen credentials in every case. It depends on the agent's ability to repurpose valid access across systems that were never meant to share one operational context. That is why the correct governance lens is cross-system authorization integrity, not just login security. Practitioners should evaluate whether their controls can preserve system boundaries after authentication has already succeeded.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• The next control question is not whether agents will proliferate, but whether governance can keep pace with their expanding access patterns, as explored in OWASP Agentic AI Top 10.

What this signals

Identity mesh is becoming a practical governance blind spot, not an edge-case exploit. As AI agents are connected to more email, chat, ticketing, and developer tools, the chance that one session can cross a boundary without detection rises sharply. With 96% of technology professionals already identifying AI agents as a growing security threat, the programme question is whether your logging and approval model can still explain who moved what, from where, and into which system.

Cross-system provenance will matter more than raw access counts. A team can know an agent has access and still miss the point if it cannot reconstruct the path of data across systems. That is why identity governance for agents has to move from static entitlement review to workflow tracing, boundary enforcement, and auditable source-to-destination context. The useful question is no longer how many tools an agent can touch, but whether it can be made accountable for each hop.

Identity mesh: this is the point where multiple authenticated systems collapse into one operational pathway, and the implication is that traditional session-based monitoring will undercount the risk. Teams that keep using single-system access reviews will miss the cross-origin behaviour that actually drives exfiltration and phishing.

For practitioners

• Map cross-system identity fusion paths Identify where a single agent can read from one system and write to another using the same user or service context. Prioritise workflows that connect ticketing, chat, email, knowledge bases, and developer tools because those combinations create the widest identity mesh.
• Disable unrestricted agent autonomy for cross-origin actions Require explicit approval before an agent moves information from one authenticated system into a different system, especially when the destination is public, shared, or externally reachable. Do not rely on the original login session as proof that the second action is safe.
• Separate read and write privileges by workflow Limit agents so they can collect context from a source system but cannot write to another system unless the destination action is separately authorised. This reduces the chance that malicious content becomes an outbound post, ticket, or code comment.
• Review browser-integrated agents as identity mediators Treat AI browsers as cross-origin execution environments, not passive interfaces. Restrict their access to sensitive mail, developer tools, and admin consoles until you have logging that can show which source content led to which downstream action.
• Instrument agent workflows for data provenance Log the originating system, the intermediate context, and the final target system for every agent action that crosses a boundary. Without provenance, it is difficult to prove whether a cross-system write was user intent or a prompt-driven escalation.

Key takeaways

• IdentityMesh shows that agentic lateral movement can emerge from merged identity contexts, not just stolen credentials.
• The article's browser, support, and custom-agent scenarios illustrate how one authenticated workflow can become a cross-system exfiltration path.
• The control that matters most is boundary preservation across read and write actions, because that is what stops trusted input from becoming unauthorised propagation.

Key terms

• Identity Mesh: A merged operational state where one AI agent effectively carries multiple authenticated identities across different systems. In practice, this collapses trust boundaries that were assumed to be separate, allowing a single workflow to read in one system and act in another without a fresh authorization decision.
• Cross-System Lateral Movement: The movement of an attacker or malicious workflow from one trusted environment into another using legitimate access paths. In agentic systems, this often happens when the agent is allowed to repurpose context or data across tools, turning normal interoperability into an attack path.
• Indirect Prompt Injection: Malicious instructions hidden inside content that the agent is already permitted to process, such as tickets, emails, or documents. The attack is delayed and indirect because the content looks legitimate at first, then influences later agent behaviour when the workflow changes systems.
• Identity Fusion: The point at which several separate authorizations are treated as one operational unit by an AI agent. That fusion makes it possible for a task started in one authenticated context to trigger unintended actions in another, which is the core governance failure IdentityMesh exposes.

Deepen your knowledge

IdentityMesh, cross-system authorization, and agent boundary control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for MCP, AI browsers, or multi-tool agents, it is worth exploring.

This post draws on content published by Lasso Security: IdentityMesh: Exploiting Lateral Movement in Agentic Systems. Read the original.