# Breaking the Lethal Trifecta: How Asana Thinks About Agentic AI Security > Learn how Asana builds agentic AI responsibly when the industry hasn't figured out the fundamentals. Source: https://asana.com/inside-asana/how-asana-thinks-about-agentic-ai-security ## Breaking the Lethal Trifecta: How Asana Thinks About Agentic AI Security _Agentic AI introduces a class of security risk the industry hasn't solved. Here's how we think about it at Asana, and the security invariants we hold across our AI features._ ## **The problem** Agentic AI systems don't just answer questions. They read documents, take actions, and coordinate across tools. The more they can do, the larger their attack surface. Unlike conventional code, LLMs have a property that makes this fundamentally hard: **they can't reliably tell instructions apart from data.** Everything fed to an LLM lands in the same stream, so a carefully crafted piece of data can hijack the model the same way a legitimate instruction would. This is the root of prompt injection, what Simon Willison[calls](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) "the original sin" of LLM-based applications. It's not theoretical. Researchers have demonstrated this attack class against[Microsoft 365 Copilot](https://simonwillison.net/2025/Jun/11/echoleak/),[GitHub's MCP server](https://simonwillison.net/2025/May/26/github-mcp-exploited/),[Slack AI](https://simonwillison.net/2024/Aug/20/data-exfiltration-from-slack-ai/), and many others. Bruce Schneier[put it bluntly](https://www.schneier.com/blog/archives/2025/08/we-are-still-unable-to-secure-llms-from-malicious-inputs.html): the industry doesn't yet have robust defenses against this class of attack. So how do you build agentic AI responsibly when the industry hasn't figured out the fundamentals? ## **The Lethal Trifecta** Willison distills the core risk into three capabilities that, in combination, create the conditions for harm: - **Access to sensitive data.** The agent can read confidential or private information. - **Exposure to untrusted content.** The agent processes input that may contain hidden adversarial instructions. - **The ability to externally communicate.** The agent can send information outside the system. A useful refinement on the third leg: it's really the ability to **create side effects**, not just outbound communication. Exfiltrating data to an attacker's server is the canonical example, but a malicious instruction that quietly retitles every project in a workspace, or sends sensitive content to the wrong internal channel, is the same shape of problem. We use "external communication" as shorthand, but the broader version is what we actually defend against. Any one leg of the trifecta is manageable. Even two together usually are. But when all three converge, you have a viable attack path. The important insight: **breaking any one leg substantially reduces the overall risk.** We don't need to solve prompt injection perfectly. No one has. We need to make sure all three conditions can't easily coexist. [Korny Sietsma builds on this](https://martinfowler.com/articles/agentic-ai-security.html), mapping the trifecta to mitigations like sandboxing, task decomposition, least privilege, and human-in-the-loop. These are the building blocks. The question is how to operationalize them. ## **Context, Checkpoints, and Controls** We organize our thinking around three pillars that map directly to the lethal trifecta. Each constrains one leg. Asana has several AI surfaces. AI Teammates are agentic participants with their own membership and permissions in the workspace. Other AI features operate as the user, with the boundary being what that user can already access. The invariants below focus on the agentic case, where the surface is largest, and we'll call out where the implementation differs by surface. ### **Context: Manage what AI can see** _Trifecta leg: Access to sensitive data_ For agentic AI to be useful, it needs context. The challenge is giving it enough to be helpful without handing it a skeleton key. Our foundational invariant is the principle of least privilege, with the exact expression depending on the surface. For AI Teammates, which have their own membership separate from any individual user, the boundary is the intersection of the Teammate's permissions and the user's. For AI features that operate as the user, the boundary is simply that user's own access. In every case, the same server-side authorization layer that governs every other interaction in Asana governs the AI's access. AI features don't get elevated permissions. They operate within Asana's access control system, not around it. Defining context involves more than regulating internal data access within Asana; it equally encompasses the external integrations an agent can interact with. While integrations currently require explicit user authorization, we are developing granular, agent-specific control paths. This allows organizations to restrict integration privileges for AI Teammates handling high-risk inputs. Our core architectural invariant is clear: the boundary of what an AI can _see_ must be dynamic and driven by data owners, rather than being a hardcoded product default. Even if an attacker smuggles malicious instructions into the AI's context, what the AI can actually _see_ is bounded by the same permission model as everything else. ### **Checkpoints: Filter what AI listens to** _Trifecta leg: Exposure to untrusted content_ This is the hardest leg. In a work management platform, most of what AI reads is user-generated content: tasks, comments, attached documents. Some of it comes from outside the organization. You can't refuse to read it. We instead establish **checkpoints**: places where we distinguish trusted intent from arbitrary content, and where humans can intervene if something looks wrong. - **Source-aware instruction handling.** AI features tag content by author trust and by source, so the model can weight instructions from authorized users above instructions encountered in arbitrary content along the way. This narrows the attack surface for prompt injection but doesn't close it; the model still reads everything in its context, and the security guarantee is partial rather than absolute. We discuss the limits of this approach below. - **Logging and forensic investigation.** Every model call is logged with its inputs, outputs, actor, feature context, and downstream events, including which work-graph objects an automation touched and which URLs appeared in output. We alert automatically on operational signals like error rates and cost spikes. For security-relevant anomalies, those same logs support post-hoc investigation by humans. As Willison notes, even pattern-based detection that catches most attacks would be a failing grade on its own; visibility and the ability to investigate are the durable foundation we build on, not the wall. - **Human-in-the-loop design.** AI features surface their work for human review rather than taking irreversible actions silently. - **Task decomposition and scoped actions.** Complex workflows are broken into smaller stages, and the actions available to AI features are intentionally constrained rather than open-ended. None of these is individually bulletproof. Together, they form defense in depth. ### **Controls: Restrict what AI can act on** _Trifecta leg: The ability to create side effects_ The third leg is where most real-world attacks land. If an attacker convinces an AI to embed sensitive data in a URL, send it through an integration, or change a record that other people rely on, the attack succeeds. We invest in several categories of control here: - **Treat LLM output as untrusted.** Generated content doesn't get a trust bump because it came out of an Asana AI. It flows through the same validation and rendering paths as any other user-generated content. - **Mandatory human approval for high-impact actions.** Certain action categories always require explicit human approval, regardless of how confident the AI is or how routine the request looks. For AI Teammates, this includes actions that elevate access (changing permissions, adding members) and actions that destroy data (deletions). The AI can propose these; it cannot execute them on its own. - **Link handling guardrails.** External URLs in AI-generated content are processed before they reach a user. New URLs that didn't appear in the input get extra scrutiny and surface in their full, unobscured form rather than as relabeled anchor text, so the AI can't be weaponized to dress up an exfiltration endpoint as a friendly "click here for the summary." - **No general-purpose outbound HTTP.** AI features don't have an open-ended "make a request to any URL" primitive. External integrations go through scoped channels with their own authorization. - **Action audit trail**. Every write, mutation, and outbound action an AI feature takes is logged alongside the model call that prompted it, so an investigator can reconstruct what an AI did, not just what it was asked. The goal isn't to make external communication impossible. AI features need to reference links, update tasks, and produce useful output. The goal is to make sure they can't do so _covertly_ in a way the user didn't intend. ## **A pattern for AI-emitted values** Inside this frame, the same concrete sub-problem keeps coming up: an AI feature produces something (an object ID, a recipient, a URL) and downstream code acts on it, often with broader permissions than the AI itself. Hallucinations and prompt injections land in the same place: a value the model emits gets trusted. We use a four-part pattern as a design-review checklist for these values: - **Restrict** what the AI is allowed to produce in the first place, before validation has to run. - **Validate** every AI-produced value server-side against the same authorization layer as everything else. The model is treated as an untrusted client. - **Justify** the choice by keeping enough structured context to explain _why_ the AI chose what it did. That's what makes investigation, evals, and incident response possible later. - **Escalate** with friction, fallback, or human review when a value is high-risk or outside the expected scope. The thread running through it: **model behavior shouldn't be the primary security control.** Better prompts and "we told the model not to do that" are useful defense in depth, but the durable controls sit in the system around the model. ## **Grounded in principles** These choices aren't ad-hoc. They flow from[Asana's published AI principles](https://asana.com/ai-principles). **People are accountable for decisions** drives the checkpoint-oriented design. AI assists, but humans stay in the loop and are accountable. **We are committed to safety,**which justifies the investment in layered controls even when they add friction. The alternative compounds risk as AI features take on more complex work. **We promote transparency,** which is why we're writing this post. We haven't solved agentic AI security. But being open about how we reason about these risks and the mitigations we run helps the broader community make progress on a shared challenge and invites the scrutiny that makes us better. ### **The honest limits** **Prompt injection is still fundamentally unsolved**, and indirect prompt injection (the adversarial instructions arrive embedded in content the AI fetches during its work, rather than content a user hands it directly) is the variant where the industry has been hit hardest in 2026. **Source-aware tagging** helps but doesn't fully close this gap, because the model still has to choose to respect the tags. Our checkpoints reduce the risk significantly; they don't eliminate it. As long as instructions and data share a context window, adversarial input retrieved through search, public forms, or integrations will sometimes slip through. We treat this as an active, ongoing area of investment, with closer scrutiny of any path that lets externally-authored content reach an agentic feature. Work on [design patterns for securing LLM agents](https://simonwillison.net/2025/Jun/13/prompt-injection-design-patterns/) points at promising directions, but industry consensus is still emerging. **The threat landscape moves fast.** New vectors keep appearing, from[invisible image-based prompt injection](https://brave.com/blog/unseeable-prompt-injections/) to multi-step exfiltration chains. We design controls to be layered and composable so new mitigations can be added as new threats emerge. It's an arms race, not a problem you solve once. The[OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) is a useful running reference. We don't see these gaps as reasons to slow down. We see them as reasons to be deliberate. The lethal trifecta tells us the stakes. Context, Checkpoints, and Controls give us a framework for action. And because no team solves this alone, we're actively investing alongside our research and customer partners to harden these surfaces as the threat landscape evolves. #### **References** - Simon Willison,["The lethal trifecta for AI agents,"](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) June 2025 - Korny Sietsma,["Agentic AI and Security,"](https://martinfowler.com/articles/agentic-ai-security.html) Martin Fowler, October 2025 - Bruce Schneier,["We Are Still Unable to Secure LLMs from Malicious Inputs,"](https://www.schneier.com/blog/archives/2025/08/we-are-still-unable-to-secure-llms-from-malicious-inputs.html) August 2025 - [Asana AI Principles](https://asana.com/ai-principles) - OWASP,["Top 10 for LLM Applications"](https://genai.owasp.org/llm-top-10/) - [Improving Asana’s Pageload Performance](/inside-asana/improving-asanas-pageload-performance) Engineering #### Senior Engineering Manager Asana serves 2.5 million pageloads a day, peaking at 3.5 million. Each one is a user's first impression of the product — the moment between intent and action — and for a tool team ... - [How Asana Built A Resilient ID Allocation System](/inside-asana/how-asana-built-resilient-id-allocation) Engineering Every object in Asana—every task, project, comment, and attachment—needs a unique identifier. At Asana, these IDs are sequentially incrementing integers, allocated in blocks from ... - [The Athletic Position](/inside-asana/the-athletic-position) Engineering I. Before the Ball Leaves their StringsThere is a moment from the 1988 French Open final that most people who talk about tennis haven’t had to think about carefully.Steffi Graf pl ... - [How Asana leverages AWS Inspector for total visibility over infrastructure vulnerabilities](/inside-asana/asana-leverages-aws-inspector-visibility-infrastructure-vulnerabilities) Engineering #### Software Engineer Scanning for vulnerabilities across multiple AWS accounts, eliminating noise, and turning vulnerability findings into actionable work is a challenging but important undertaking. A ... - [Breaking the Lethal Trifecta: How Asana Thinks About Agentic AI Security](/inside-asana/how-asana-thinks-about-agentic-ai-security) Engineering - [Staff Security Engineer](/author/varun-prusty) Agentic AI introduces a class of security risk the industry hasn't solved. Here's how we think about it at Asana, and the security invariants we hold across our AI features.The pr ... - [Engineering](/inside-asana/engineering-spotlight)