What is living off the agent (LOTA)?

Living off the agent is an attack pattern where an adversary influences an AI agent through content it processes, such as an email, a ticket field, or a shared memory entry, and then uses the agent's own authenticated connections to reach data and systems. It is the AI counterpart of living off the land: no malware is dropped, because the agent's legitimate access does the work. The term was popularized by Cloud Security Alliance research published in May 2026.

How is LOTA different from traditional lateral movement?

Traditional lateral movement requires stolen credentials or exploited hosts and generates network and authentication anomalies. In LOTA the attacker never holds a credential. The agent calls APIs with its own tokens, so logs show a trusted identity doing something it is allowed to do. The difference is in intent and sequence, not in permissions, which is why classic EDR and network detection often miss it.

Can prompt injection filters stop LOTA?

Filters reduce risk but cannot be the only control. Injected instructions can be paraphrased, split across fields, or encoded, and an agent that must read untrusted content will eventually read a payload that passes the filter. Durable defense limits what a hijacked agent can do: scoped short-lived credentials, least privilege per task, human approval for sensitive actions, and isolation between agents and memory stores.

What logs do I need to detect LOTA?

You need agent-level telemetry that joins the triggering input, the model's tool-call decisions, and the downstream API calls under one session ID. Useful fields include the content source and its trust level, the tool name and arguments, the identity the call ran under, the delegation chain between agents, and the resulting data volume. Without the input-to-action link, a SIEM sees only normal API traffic.

Is the ServiceNow Now Assist issue a real LOTA example?

It is the best documented public example of the pattern. AppOmni reported in November 2025 that a second-order prompt injection could cause one Now Assist agent to recruit a more privileged agent through default agent discovery settings. AppOmni described it as expected behavior under default configuration, not a model bug, which is exactly why configuration review matters.

Where should I start if I run AI agents in production?

Inventory every agent, the identities it uses, and every source of content it reads that an outsider could write to. Then remove standing credentials, scope tokens per task, and add approval gates for actions that send data outside your boundary. Running a scan of your exposed AI endpoints is a quick way to find agents you did not know were reachable.

Living Off the Agent (LOTA): Defense Guide

Living off the agent (LOTA) is what happens when an attacker stops bringing tools into your environment and instead borrows the AI agents you already deployed. A single poisoned email, ticket field, or memory entry can steer an agent that holds real OAuth tokens and API access, and every action it takes looks like normal business activity. This guide explains how LOTA works, where it has already shown up, how it differs from classic lateral movement, and which controls and detections reduce the risk in practice.

Key Takeaways

LOTA is the agent-era equivalent of living off the land: the attacker uses the agent's legitimate credentials and tools, so there is no malware to detect.
The entry point is any content an agent reads that an outsider can write to: email, calendar invites, tickets, CRM fields, documents, shared memory, and tool registries.
Cloud Security Alliance research counted lateral movement in 8 of 21 documented multi-stage agentic incidents from 2025 to 2026, up from 3 of 12 in 2024 and none in 2023.
The ServiceNow Now Assist agent discovery issue shows the pattern with default settings and no infrastructure compromise.
Prompt injection filters are a weak primary control. Limiting what a hijacked agent can reach is the control that holds.
Detection depends on joining the triggering input, the tool call, and the downstream API activity into one record.
Treat each agent as a distinct non-human identity with scoped, short-lived credentials and explicit approval gates for high-impact actions.

What Is Living Off the Agent?

Living off the land (LOTL) describes attackers who use binaries already present on a host, such as PowerShell or certutil, so that endpoint tools see only trusted software. The Cloud Security Alliance research note on LOTA applies the same logic to AI agents. The binaries and scripts are replaced by natural language instructions injected into content the agent processes, and the "land" is the agent's connected systems.

This is worse than LOTL in one specific way. A PowerShell session on a laptop is bounded by that user's endpoint. An enterprise agent integrated with Microsoft 365, Google Workspace, Salesforce, or an internal ticketing system holds OAuth tokens, document permissions, and API credentials on behalf of many users, and it is designed to act on them without a human in the loop. Compromising its behavior is often cheaper than compromising any one of those accounts.

A caveat on the sourcing: the CSA documents describe themselves as preliminary research and note AI-assisted drafting without formal CSA review. The pattern they describe is consistent with independently disclosed vulnerabilities and with well understood indirect prompt injection, but you should treat the incident counts as indicative, not as audited statistics.

LOTA Attack Anatomy

A LOTA attack has four stages. Each maps to a control point, so it helps to think about them separately.

1. Plant. The attacker writes adversarial text somewhere an agent will later read. They do not need access to the agent itself. They need write access to any upstream data source, which for many enterprises includes inbound email, public web forms, support tickets, shared documents, and third-party SaaS records.

2. Ingest. The agent retrieves that content as part of a legitimate task: summarizing an inbox, triaging a ticket, enriching a CRM record. Large language models do not reliably separate instructions from data, so the planted text competes with the system prompt for control.

3. Pivot. The hijacked agent calls tools it is allowed to call. This is the lateral movement step. It might query a different SaaS application, read files it can access, call another agent, or write to a shared store that other agents read from.

4. Act. The agent exfiltrates data, changes records, escalates roles, or plants the next payload. Each call uses the agent's own identity, so authentication logs show success under a trusted principal.

Injection surfaces that matter most

In practice, the surfaces below create the most exposure because they combine outsider write access with broad agent read access:

Email and calendar content. Inbound messages from anyone are processed by assistants with mailbox and file access.
SaaS record fields. Free text in tickets, CRM notes, and case descriptions is often readable by many agents.
Shared and persistent memory. A poisoned memory entry persists across sessions and users. See our analysis of agent memory poisoning and the MemGhost memory attack pattern.
Tool and server registries. A malicious or altered tool description can steer an agent before any user content is read. See MCP tool poisoning.
Agent-to-agent channels. Messages between agents are often trusted by default, which turns one low-privilege agent into a recruiting path for a higher-privilege one.

Real Incidents and Evidence

ServiceNow Now Assist agent discovery

The clearest public case is the second-order prompt injection that AppOmni disclosed in November 2025. According to AppOmni's write-up, Now Assist agents are grouped into the same team by default and are discoverable once published. An attacker places a malicious instruction in a field that a benign agent later reads. That agent, following the injected text, discovers and recruits a more capable agent on its team, which then performs the harmful action, such as exporting records or changing roles.

Two details make this a textbook LOTA example. First, no infrastructure was compromised and no credentials were stolen. Second, AppOmni's researcher characterized it as expected behavior under default configuration options rather than a bug in the model. Agents ran with the privilege of the user who started the interaction, not the party who planted the text, which is the gap the attack exploits. The fix is configuration discipline: supervised execution, disabled autonomous overrides, and separated agent duties.

What the CSA incident data suggests

The CSA note reviewed 21 documented multi-stage agentic incidents across 2025 and 2026 and found lateral movement in eight. Earlier periods show three of twelve in 2024 and none in 2023. The sample is small and the classification is the authors' own, so we would not quote the percentages as a trend line. What the numbers do support is a directional claim: as agents gain tool access, attackers increasingly use them as pivots, not just as sources of leaked text.

A common pattern in agent assessments is a read-only assistant with a quiet write path. A summarization agent that can only "read" mail but can also create calendar events, post to a chat channel, or call a webhook has an exfiltration route. We have seen this repeatedly: the tool inventory looked harmless until we listed every side effect, including ones the designers considered incidental. For a deeper look at how unauthenticated fetch paths turn into pivots, see our AI agent SSRF guide.

LOTA vs Traditional Lateral Movement

| Dimension | Traditional lateral movement | LOTA | |---|---|---| | Attacker holds credentials | Yes, stolen or forged | No, the agent's own tokens are used | | Tooling | Remote execution tools, scripts, malware | Natural language in agent-readable content | | Speed | Bounded by operator effort | Machine speed, parallel across sessions | | Detection signal | Odd logins, new hosts, unusual protocols | Normal API calls from a trusted identity | | Attribution | Source host and account | Ambiguous: user, agent, or planted text | | Containment | Isolate host, rotate credentials | Revoke agent tokens, purge poisoned content and memory |

The deniability point deserves attention. When an agent acts under a user's delegated token, an investigator must determine whether the user asked for the action, the agent decided on its own, or injected content directed it. Without prompt and tool-call records, that question cannot be answered. Our guide to AI agent breach forensics covers what to capture before an incident.

Enterprise Defense Framework

No single control stops LOTA, because the underlying weakness is that models cannot reliably tell instructions from data. The strategy is to assume the agent will eventually follow a hostile instruction and to make that outcome low impact.

1. Constrain identity and credentials

Give every agent its own identity, separate from any human user. Issue short-lived, narrowly scoped tokens per task and avoid standing credentials. If a summarization agent needs read access to one mailbox folder for one run, that is the token it should receive. The principles in our AI agent authorization guide and non-human identity security apply directly.

2. Break implicit trust between agents

Do not let agents discover and call each other by default. Require explicit allow-lists of which agent may invoke which, and authenticate those calls. Where possible, pass delegated authority down only as far as the original requester holds it, so a low-privilege trigger cannot reach high-privilege tools through a peer. This is the control the ServiceNow case turns on.

3. Track input provenance

Label content by trust level when it enters the context: system, authenticated user, internal system, or external. Policies can then say that a tool call with side effects is not permitted when the most recent instruction-bearing content was external and unverified. This is a design constraint, and it is far more reliable than trying to detect malicious wording.

4. Gate high-impact actions

Require human approval or a second, independent check for actions that move data outside your boundary, change roles, or delete records. Keep the approval prompt specific: show the destination, the data, and the reason, not a generic "allow tool use?" dialog that users learn to click through.

5. Isolate memory and shared stores

Scope memory per user and per task where you can. Treat writes to shared memory as untrusted input for every future reader. Add expiry and review for persistent entries, and log who or what wrote them. See our write-up on agentic blast radius containment for segmentation patterns.

6. Harden the tool layer

Pin and review MCP servers and tool descriptions, restrict egress by destination domain (not by HTTP method), and remove tools an agent does not need. Read-only web access can still write through GET requests to attacker-controlled URLs, so network egress rules are part of agent defense. Our MCP security guide lists the review points.

Tradeoffs to acknowledge

These controls cost something. Approval gates slow workflows and can cause fatigue. Narrow tokens add orchestration complexity. Strict provenance rules will block some legitimate automations until teams re-design them. We recommend starting with the highest-blast-radius agents and relaxing controls only where the measured risk is low, rather than trying to retrofit every agent at once.

Detection: What LOTA Looks Like in Logs

Because every call is authorized, detection has to look at behavior and sequence. Useful signals include:

Input-to-action linkage. A session that ingests external content and, within the same session, calls a tool it has not used for that workflow before.
Unusual delegation chains. An agent invoking a peer it has never invoked, or a low-privilege agent triggering a high-privilege one.
Volume and scope changes. An agent that normally reads a handful of records suddenly enumerating hundreds, or reading across tenants or mailboxes.
Outbound destination novelty. A first-seen domain in a webhook, email recipient, or fetch call from an agent session.
Role or permission changes initiated by an agent identity. These should be rare enough to alert on every instance.

A practical starting point is a SIEM rule that correlates the agent session ID, the content source tag, and the tool-call record, then alerts on side-effecting calls following external content. Research on agent detection and response is maturing, including work that treats agent sessions as a telemetry class of their own, but the minimum viable version is logging discipline: capture prompts, tool calls with arguments, identity used, and the delegation chain, and retain them long enough to investigate. Our runtime security guide goes deeper on instrumentation.

Mapping LOTA to Frameworks

Mapping helps you reuse existing risk and audit processes instead of inventing a parallel one.

MITRE ATT&CK. The pivot step aligns with Lateral Movement (TA0008), credential-based abuse maps to Credential Access (TA0006) and valid accounts techniques, and the final step often lands in Exfiltration (TA0010). MITRE ATLAS adds AI-specific techniques such as prompt injection and AI agent tool abuse.
OWASP. The OWASP Top 10 for LLM Applications covers prompt injection and excessive agency, both central to LOTA. Our OWASP Agentic Top 10 guide maps agent-specific risks such as tool misuse, identity abuse, and inter-agent trust.
NIST AI RMF. The NIST AI Risk Management Framework supports this under Map (inventory agents and their data and tool access), Measure (test with adversarial scenarios), and Manage (apply controls and incident response). The Generative AI Profile adds guidance relevant to prompt injection and information security.

A 30-Day Starting Plan

Week 1: Inventory. List every agent, its identity, its tools, and every content source it reads. Mark sources that outsiders can write to.

Week 2: Cut standing access. Replace long-lived tokens with scoped, short-lived ones for the three highest-impact agents. Disable default agent-to-agent discovery where the platform allows it.

Week 3: Add gates and logs. Introduce approval for external sends and role changes. Ensure session-level logs join input, tool call, and identity.

Week 4: Test. Run adversarial exercises that plant instructions in your real intake channels and verify what the agent does. Our agent security testing guide outlines test cases.

Conclusion

Living off the agent works because enterprises have connected capable, credentialed software to content that strangers can write. LOTA is not a model defect that a better filter will remove. It is a trust boundary problem, and the controls that work are the familiar ones applied to a new kind of identity: least privilege, short-lived credentials, segmentation, approval for high-impact actions, and logs that let you reconstruct why something happened.

Start by finding out which of your agents are reachable and what they can touch. Run a Securetom scan to identify exposed AI endpoints, then use the inventory to prioritize the controls above. You can also review how Securetom compares to other tools on our compare page.

Living Off the Agent (LOTA): Defense Guide

What Is Living Off the Agent?