By NHI Mgmt Group Editorial TeamBased on Reco AI: “OWASP Top 10 for LLM Applications: What Every Security Team Needs to Know” (September 24, 2026)

TL;DR: EchoLeak shows how a crafted message can force Microsoft 365 Copilot to leak data from its context with no click, and Reco AI frames the issue as a gap in how enterprises map agent access before exposure is exploited. The broader problem is that AI agent security still depends on understanding which tools, data, and permissions sit inside the runtime boundary, not just the prompt.


At a glance

What this is: This is Reco AI’s analysis of EchoLeak, a zero-click prompt injection path that can expose Microsoft 365 Copilot context and highlights how agent runtime access creates a different security boundary than the prompt itself.

Why it matters: It matters because IAM, PAM, and AI agent governance teams need to control what an agent can access, not just what it is asked, or exposed context becomes a direct exfiltration path.


Context

EchoLeak is a zero-click prompt injection issue in which a crafted message can cause Microsoft 365 Copilot to leak information from its runtime context. In practice, the risk is not limited to the prompt content itself. The attack matters for AI agent governance because the agent’s effective privilege boundary extends to whatever data and tools sit inside that runtime context.

The governance gap is familiar to IAM and NHI teams, even if the actor feels new. Organisations often review prompts, policies, and user approvals, but they do not always inventory the agent’s reachable data, delegated permissions, and embedded tool access with the same rigor. That mismatch turns a context leak into an identity exposure problem.


Key questions

Q: What breaks when AI agents can process untrusted messages inside a privileged runtime?

A: The trust boundary breaks first. If an AI agent can interpret untrusted input while holding delegated access to sensitive data, the message no longer needs a human click to become dangerous. Security teams should assume the runtime context itself can be manipulated and should limit what that context can see, combine, or disclose.

Q: Why do zero-click defenses fail for AI agent context exposure?

A: Because zero-click defenses were built around user interaction, not autonomous or agent-mediated interpretation. When the agent processes the payload directly, the attacker is targeting the runtime boundary and the inherited permissions inside it. That means the control objective shifts from blocking the click to constraining the agent’s effective access.

Q: How do security teams know if an AI agent has too much access?

A: Look for agents that can reach multiple systems without task-specific limits, use persistent tokens, or touch high-value services such as email, chat, cloud consoles, and file stores. A healthy deployment leaves a clear audit trail of what the agent can do, what it actually did, and which credentials it used.

Q: What should teams do first after finding exposed AI agent context risk?

A: Start by removing unnecessary connectors, memory access, and broad session permissions from the agent. Then isolate the remaining trusted context from untrusted input so a crafted message cannot reach the same authority plane as sensitive data. That sequence reduces the attack surface before more advanced controls are added.


Technical breakdown

Why context is the real attack surface in AI agents

In agentic systems, the prompt is only the trigger. The context window, connected tools, and delegated permissions form the actual execution boundary, because the model can reason over whatever the runtime exposes. If an attacker can inject text that changes how the agent interprets that context, the security problem becomes one of access scope, not just content filtering. Zero-click attacks succeed when the system accepts untrusted input into a trusted runtime without a strong separation between instruction, context, and authority.

Practical implication: map every data source and tool an AI agent can reach before you treat it as safe for production use.

How prompt injection turns delegated access into data exposure

Prompt injection works by smuggling attacker-controlled instructions into a context the model already trusts. The model does not need new login credentials if the agent session already holds them indirectly through connected services, memory, or inherited permissions. That is why AI agent security cannot stop at prompt sanitisation. The issue is whether the agent can be induced to apply existing authority in the wrong direction, at the wrong time, or toward the wrong destination.

Practical implication: classify agent permissions as an access control problem, not a content moderation problem.

Why zero-click defenses miss runtime-boundary failures

Traditional zero-click thinking assumes the dangerous event is a message being opened or rendered. For AI agents, the dangerous event is the runtime interpreting that message inside a privileged context. The failure mode is exposure without interaction, but the deeper issue is that the agent boundary is porous when tools, memory, and connected data are not isolated from untrusted input. Once context crosses that boundary, the agent can become an exfiltration path rather than a safeguard.

Practical implication: enforce isolation between untrusted inputs and the agent’s privileged context, including memory, connectors, and downstream actions.


Threat narrative

Attacker objective: The attacker aims to extract sensitive information from the AI agent’s trusted context without needing the user to approve or interact with the payload.

  1. Entry occurs through a crafted message that reaches Microsoft 365 Copilot without requiring a victim click.
  2. Credential or context access follows when the agent interprets that message inside its trusted runtime and exposes information already available to the session.
  3. Impact is data exfiltration from the agent context, proving that the runtime boundary can leak sensitive information even in a zero-click scenario.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

AI agent context is the security boundary, not the prompt. EchoLeak shows that the dangerous asset is the runtime context holding tools, memory, and delegated access. Prompt controls help only at the edge; they do not govern what the agent can already see or use. The practitioner conclusion is that agent governance must start with a complete inventory of context-bearing privileges.

Zero-click defense assumptions collapse when the model can act on trusted context. Zero-click controls were designed for user interaction paths, where a malicious message still depends on a human action. That assumption fails when the actor is an AI agent because the message can be processed directly inside a privileged runtime. The implication is that security teams must rethink where authorization actually happens, not just add more filters.

Delegated access without context isolation creates an identity blast radius. Once an agent can combine multiple reachable resources inside one session, the blast radius is defined by context, not by the visible prompt. That makes traditional access review too late if the reachable scope is already too broad. The practical conclusion is that agent permissions need to be modeled as a composite identity surface.

Runtime exposure is the named concept practitioners should watch. Runtime exposure describes the gap between what an AI agent is asked to do and what its current context allows it to touch, combine, and leak. EchoLeak demonstrates that this gap is where zero-click attacks become identity incidents. The practitioner conclusion is to govern runtime exposure as a first-class control objective.

AI agent governance needs the same discipline that NHI teams apply to secrets and service accounts. The source problem is not novel orchestration, but the reuse of privileged context across dynamic interactions. OWASP-NHI and NIST zero-trust thinking both point to the same requirement: narrow what is reachable, isolate what is untrusted, and treat delegated access as live authority. The practitioner conclusion is to govern agent context with the same seriousness as any other high-risk non-human identity.

From our research library:

What this signals

Runtime exposure: AI agent risk is shifting from prompt content to the scope of the context the agent can already reach. That means programme owners need to classify connectors, memory, and downstream tools as part of the identity boundary, not as incidental plumbing.

Access review alone is too slow for systems that can process untrusted input inside a privileged runtime. The control point moves to authorisation design, where teams decide what an agent can touch before a session begins and what must remain out of reach throughout execution.


For practitioners

  • Inventory agent runtime context Map every data source, connector, memory store, and downstream tool that Copilot or other AI agents can reach during a session. Classify which of those resources are sensitive enough that a context leak would become reportable exposure.
  • Separate untrusted input from privileged context Keep user-supplied content, external messages, and retrieved content out of the same trust zone as the agent’s operational permissions. Where that separation is impossible, reduce the agent’s reachable scope until the boundary is explicit.
  • Treat delegated agent access as live authority Review whether the agent inherits access that outlives the task, and remove any broad session-wide permissions that are not required for a narrowly defined outcome. The goal is to stop the agent from carrying more authority than the task justifies.
  • Log and alert on context-driven data exposure Instrument agent sessions so teams can detect when a message, retrieval result, or memory item causes information to move across an unexpected boundary. Without those signals, a zero-click leak looks like normal agent behaviour.

Key takeaways

  • EchoLeak shows that AI agent exposure is a runtime-boundary problem, not just a prompt-safety problem.
  • Zero-click attacks become more damaging when the agent already holds delegated access to sensitive context and connected tools.
  • The limiting control is scope, isolation, and authority design around the agent session, not message filtering alone.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseEchoLeak is fundamentally about an agent using trusted context and delegated privilege in the wrong boundary.
Recommendation — Constrain agent authority so trusted context cannot be repurposed into data exposure or unwanted actions.
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationThe article centres on how a privileged runtime accepts and acts on untrusted input inside an AI agent context.
NHI-05 — Overprivileged NHIThe attack becomes severe when Copilot-like agents retain broader access than the task requires.
NHI-08 — Environment IsolationEchoLeak shows why untrusted input and privileged agent context must not share the same trust zone.
Recommendation — Authenticate and isolate agent inputs so untrusted messages cannot influence privileged runtime decisions. Reduce agent permissions to the minimum reachable scope needed for the session outcome. Separate untrusted content from privileged agent context to prevent cross-boundary leakage.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThis article is about governing the permissions an AI agent can exercise at runtime.
Recommendation — Review and tighten agent entitlements so runtime access matches the intended business task.

Key terms

  • Runtime exposure management: A security approach that prioritises what is actually exploitable in live environments rather than treating every finding as equally urgent. It combines runtime context, asset criticality, and control enforcement so teams can focus on exposure that changes production risk.
  • Context Window: The context window is the text a model receives at one time, including prompts, retrieved documents, and conversation history. Security teams care about it because it becomes the practical boundary between trusted instructions and untrusted content, especially when the application assembles that text automatically.
  • Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
  • Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on September 30, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org