0-click AI agent exploits expose enterprise control gaps

At a glance

What this is: Zenity Labs’ research shows that 0-click attacks against enterprise AI agents can trigger unauthorised access, data exfiltration, memory manipulation, and conversation hijacking across multiple platforms.

Why it matters: This matters because AI agents are increasingly part of identity and access paths, and their runtime behaviour can bypass the assumptions built into human IAM and static NHI controls.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).

👉 Read Zenity's research on 0-click AI agent exploit methods

Context

0-click AI agent exploits are attacks that do not require a user to click, approve, or otherwise interact before the agent is manipulated. In this case, the core problem is not a broken model alone, but a governance gap: enterprise teams are exposing agents to emails, documents, CRM cases, and messaging inputs that can be weaponised into action.

For IAM and security teams, the issue sits at the boundary between human identity, NHI-style delegated access, and autonomous behaviour. When an agent can act on trusted input and then reach adjacent tools or data sources, the control model has to account for session scope, delegation paths, and abuse of the agent’s own privileges.

Zenity’s research is best read as a reminder that AI agent security is now an identity problem as much as a content or application security problem. The starting position across many enterprises appears to be permissive enough for the attack chain to begin with minimal interaction, which is atypical only in how visibly it demonstrates the failure.

Key questions

Q: How should security teams govern AI agents that can act on untrusted input without user clicks?

A: Treat every external message, document, or case as a potential execution trigger. Security teams should define which inputs an agent may consume, which actions those inputs may trigger, and where a human or policy approval must intervene before the agent can reach sensitive systems.

Q: Why do AI agents create more access risk than ordinary automation?

A: AI agents create more risk because they can interpret untrusted content, choose actions at runtime, and use delegated access across connected tools. Ordinary automation follows a fixed path, but an agent can be steered into unintended behaviour if its inputs, memory, or tool reach are too broad.

Q: What breaks when an AI agent can retain memory across sessions?

A: A retained memory layer can turn a one-time interaction into persistent compromise if malicious instructions or poisoned context survive beyond the original input. That makes the agent’s remembered state part of the security boundary, not just a convenience feature.

Q: Who is accountable when an AI agent exposes data or reroutes communications?

A: Accountability sits with the organisation that delegated access to the agent and failed to define its runtime limits. Governance frameworks such as OWASP NHI and Zero Trust require teams to know what the agent can reach, who owns those entitlements, and when those rights must be constrained.

Technical breakdown

0-click agent compromise through trusted input channels

0-click agent compromise usually starts with a message, email, document, support case, or calendar item that the agent is already allowed to process. The attack does not need a phishing click in the human sense. Instead, it abuses the fact that agents are designed to consume untrusted content and turn it into action. Once the input is interpreted, the agent may change memory, expose data, or invoke connected tools. That is why the boundary between ingestion and authorisation is the real weak point. Practical implication: treat every external input to an agent as a potential execution path, not just data.

Practical implication: classify and constrain every external input path before it can become an action path.

Agent memory manipulation and downstream data exposure

Many enterprise agents keep memory, conversation history, or contextual state that influences later behaviour. If an attacker can poison that state, the compromise persists beyond the initial interaction and may redirect later outputs or actions. Memory manipulation is especially dangerous because it can look like legitimate continuity while actually rewriting the agent’s behaviour. In platforms connected to drive storage, CRM records, ticketing systems, or collaboration tools, poisoned context can lead to data exposure across multiple services. Practical implication: separate transient session input from durable memory and audit what the agent is allowed to retain.

Practical implication: isolate durable memory from session input and review what context the agent is permitted to store.

Tool misuse across connected enterprise platforms

The highest-risk pattern in this research is not the model itself but the agent’s ability to move from one trusted platform to another. Once an attacker gains control of the agent’s behaviour, the agent can reach Drive, CRM, tickets, chat, or developer tools with the privileges already granted to it. That is classic delegated access abuse, but with a runtime decision layer that can be manipulated mid-session. The problem is amplified when the same identity is trusted across multiple systems. Practical implication: map each agent to its actual tool graph and privilege boundary, not to the brand name of the platform.

Practical implication: inventory the full tool graph behind each agent and restrict cross-platform privilege propagation.

Threat narrative

Attacker objective: The attacker’s objective is to turn a trusted AI agent into a bridge for unauthorised access, data theft, and conversation control across enterprise systems.

1. Entry occurs through trusted enterprise inputs such as email, documents, support cases, or chat messages that the agent is already permitted to consume.
2. Credential or context abuse follows when malicious content manipulates the agent’s memory, session state, or tool selection, causing it to act on attacker-controlled instructions.
3. Impact emerges as the agent exposes sensitive data, misroutes conversations, or performs unauthorised actions in connected systems using its own delegated access.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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

NHI Mgmt Group analysis

0-click AI agent compromise is an identity problem disguised as a content problem. The research shows that attackers do not need to defeat the model first when the agent already has trusted pathways into mail, documents, CRM, chat, and developer tools. That means the governing question is not only what the model can understand, but what the identity behind the model is authorised to do. The practitioner conclusion is that AI agent governance must start with delegated access, not with prompt hygiene alone.

Agent memory creates a new persistence layer for abuse. When an attacker can alter memory or conversation state, the compromise survives the initial input and can influence later actions across a session or even longer. That turns memory into a governance object, not just a product feature. Practitioners should treat retained context as a controlled asset because it can silently extend the blast radius of a single malicious interaction.

Runtime tool reach is the real control boundary for AI agents. The research across ChatGPT, Copilot Studio, Gemini, and Salesforce Einstein shows that the same identity can become dangerous once it can traverse multiple business systems without a fresh authorisation decision. This is where identity governance and application security converge, because the problem is not merely access to one platform, but the agent’s ability to move laterally through trusted integrations. The practitioner conclusion is to govern the tool graph, not just the agent label.

Assumption collapse: access review was designed for stable privilege, not for agents that can be manipulated through transient inputs. That assumption fails when an AI agent can be induced to act immediately on an attacker-controlled email, doc, or case and then use its delegated rights before any periodic review could matter. The implication is that certification cycles no longer describe the actual risk window for agentic behaviour; the relevant control plane has shifted to runtime decision and delegation boundaries.

Identity blast radius: once an agent is trusted across collaboration, CRM, and developer workflows, compromise in one channel can propagate across every connected system. That is a field-level governance problem because the blast radius is created by identity federation and tool chaining, not by the model’s intelligence. Practitioners should treat cross-platform delegation as a security design choice with measurable containment consequences.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 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.
• For a broader governance baseline, see OWASP Agentic AI Top 10 for the control patterns that map to runtime agent abuse.

What this signals

Identity teams need to plan for runtime abuse, not just static misconfiguration. The pattern in this research suggests that agent governance will increasingly resemble high-risk NHI control, where delegated rights matter less than the ability to narrow action scope at the moment of execution. For a broader control baseline, align agent policies with the OWASP Top 10 for Agentic Applications 2026.

Agent memory is becoming a policy object, not a product convenience. If retained context can drive later actions, then security teams need to decide what may persist, who can modify it, and how quickly it can be invalidated after suspicious behaviour. That is a stronger model than relying on user awareness or email filtering alone.

Cross-platform delegation will become the dominant containment problem for AI agents. Once an agent spans collaboration, CRM, and developer tooling, one compromise can cascade through multiple control planes. Programmes that already map privilege boundaries for NHI should reuse that discipline here, but extend it to runtime tool use and conversation state.

For practitioners

• Inventory every agent input and output path Map which external sources can influence each agent, including email, docs, tickets, chat, and calendar items. Then separate read-only ingestion from any path that can trigger tool execution or memory updates.
• Constrain agent tool graphs by business purpose Limit each agent to the smallest set of tools required for its job, and prevent broad cross-platform delegation where a single compromise could reach drive, CRM, and developer environments.
• Treat retained memory as governed state Classify conversation history, long-term memory, and context stores as security-relevant assets. Review who can write to them, who can read them, and what actions they can influence.
• Add runtime checks before sensitive actions Require step-up approval or policy evaluation before an agent can send external communications, modify records, or expose data from connected systems.
• Test agents with malicious input chains Run red-team scenarios that use emails, documents, and support cases to see whether the agent can be steered into unauthorised access or data leakage without user interaction.

Key takeaways

• 0-click AI agent attacks exploit trusted inputs and delegated access, which makes runtime governance more important than user interaction controls.
• The research shows that memory, context, and tool chaining can turn a single malicious message into a multi-system compromise.
• Practitioners should control agent inputs, tool reach, and retained state as security boundaries, not as product features.

Key terms

• Zero-click agent exploit: An attack that manipulates an AI agent without requiring a human to click, approve, or interact first. The agent consumes an untrusted input and turns it into action, which makes the ingestion path part of the security boundary.
• Agent memory: Stored context that influences how an AI agent behaves beyond a single prompt or message. In security terms, memory is a persistent state layer that can be poisoned, altered, or misused to shape later actions and broaden the impact of one compromise.
• Tool graph: The set of systems, APIs, and actions an AI agent can reach through its delegated access. A tool graph defines the real blast radius of the agent, because compromise of the agent can propagate across every connected capability it is trusted to use.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: AgentFlayer: 0Click Exploit Methods. Read the original.