TL;DR
Prompt injection is when attacker-controlled text enters a language model's context and changes what it does. OWASP ranks it LLM01, the top risk for LLM applications.
In agentic AI systems, an injection is not just a bad answer. The agent can run shell commands, drive a browser, and push code, so an injection becomes an executed action with the victim's privileges.
The most dangerous variant in collaborative products is stored, indirect prompt injection: attacker text that persists and loads into another user's agent context as trusted configuration.
The CodeAnt AI Security Research Team demonstrated exactly this on Manus, turning one shared-project instruction into code execution in another user's sandbox and, ultimately, a remote-desktop takeover. It was reported through Meta's bug bounty and fixed on 16 September 2026. Read the full technical writeup.
You cannot fix this with a better safety classifier. You prevent it by isolating trust in the context, constraining egress and tool capability, and keeping secrets out of the agent's environment.
At a Glance
Topic | Prompt injection in AI agents (OWASP LLM01) |
Attack class | Stored / indirect prompt injection via shared-project instructions |
Real-world example | Manus: a shared-project owner ran code in other members' sandboxes and took over a live desktop |
Root cause | Owner-authored instructions loaded into every member's agent context as trusted config |
Key enabler | A static credential readable in the sandbox environment |
Status of the example | Reported via Meta bug bounty, fixed 16 September 2026 |
Full technical writeup |
The security conversation around AI agents is stuck on the wrong thing. Everyone argues about jailbreak prompts, while these products hand a language model a root shell in a VM with live credentials in the environment. The question that actually matters is quieter: whose text ends up in that VM, and who decided it was trustworthy?
This guide answers it for developers. It explains what a prompt injection attack is, how direct, indirect, and stored prompt injection differ, why agentic AI security breaks the assumptions most teams hold, and how to prevent it, grounded in a real finding the CodeAnt AI Security Research Team reported to Meta and got fixed.
What Is Manus AI, and How Does the Agent Sandbox Work?
Simply, Manus is an agentic AI assistant. You give it a task and, instead of only answering, it plans and executes autonomously in a cloud sandbox that spins up for your session. That sandbox is not a restricted interpreter. It is a real VM with a shell, a filesystem, a browser, and a NEKO remote-desktop server so the agent can drive a GUI when it needs to click things.
Two properties of that design matter for security.
The sandbox environment is full of secrets. The agent needs an LLM key to think, a control-plane host to talk to, and credentials for the desktop server it drives. All of it sits in
os.environ, oneprintaway from anything running in the box.Manus has shared Projects. These are collaborative workspaces you invite people into. A project carries a persistent
instructionfield: standing orders for the agent, applied to every task run inside that project.
Those two facts, secrets in the environment and a shared instruction applied to every member, are the entire attack surface.
Is Manus AI Safe to Use?
The specific vulnerability in this guide, a stored prompt injection through shared Projects, was reported through Meta's bug bounty and fixed on 16 September 2026, so that chain is closed.
The broader answer is the honest one for any agentic platform, i.e., safety is architectural, not a single patch. Any product that runs code in a live VM, mixes multiple users' text into one agent context, and keeps secrets in the environment carries the same class of risk. If you use Manus or any agentic assistant, treat instructions authored by other users as untrusted, review what your shared workspaces can execute, and assume anything readable in the sandbox environment can be read by a payload running there.
What Is a Prompt Injection Attack? (OWASP LLM01)
A prompt injection attack is when attacker-controlled text enters a language model's context and changes what the model does. OWASP ranks it LLM01, the number-one risk in its Top 10 for Large Language Model Applications, because it is easy to attempt and hard to fully prevent.
The reason it is so stubborn is structural. A language model has no separate, privileged channel for trusted instructions and an untrusted channel for data. It sees one stream of tokens. If an attacker gets their text into that stream, the model may treat it as an instruction. In a chatbot, the worst case is a bad answer. In an agentic system that can run commands, drive a browser, and push code, the worst case is that the model performs an attacker's action with the victim's privileges.
Direct, Indirect, and Stored Prompt Injection Explained
Not all prompt injection is the same, and the distinction is the whole story.
Direct prompt injection. The attacker types malicious text straight into the model, such as "ignore your previous instructions." This is the variety safety filters are trained to catch.
Indirect prompt injection. The attacker plants text in content the model will later read on its own: a web page, a document, a code comment, or a shared field. The model ingests it during a normal task. The attacker never talks to the model directly.
Stored prompt injection. The injected text persists and fires repeatedly, the way stored cross-site scripting differs from reflected. Once planted, it runs on every future task until it is removed.
The Manus example below is a stored, indirect prompt injection: the malicious text lives in a project's persistent instruction field and loads into every member's agent context, on every task, as trusted configuration. No wording trick was needed, because the platform itself decided the attacker's text was trustworthy.
Why Agentic AI Security Is Different: The Developer Pain Points
If you have shipped a chatbot, agentic AI security will surprise you. These are the pain points that make it a different problem.
The model has real hands. A chatbot returns text. An agent runs commands, edits files, drives a browser, and pushes to a repo. A successful injection is an executed action with the user's privileges.
Context is assembled from many sources, and trust blurs. Agent context is stitched from the user's message, tool output, retrieved documents, and, in collaborative products, other users' text. If any one is attacker-controlled and treated as trusted, the boundary is gone before the model runs.
You cannot win a wording fight against a model. The model re-rolls its judgment on every request, and staged payloads make the wording irrelevant: a benign instruction that fetches and runs code later means the classifier never sees the real attack.
Secrets live where the code runs. Agent sandboxes hold LLM keys, control-plane hosts, and service credentials in the environment. Any code the agent runs can read them.
Collaboration multiplies the attack surface. The moment one user can configure a workspace that another user's agent acts inside, one person's text can become another person's executed action.
These are not Manus-specific. They are the default failure modes of agentic products, which is why the case study generalizes.
Case Study: How the Manus Prompt Injection Attack Worked
The CodeAnt AI Security Research Team reported this to Meta, and it was fixed on 16 September 2026. This is the condensed version. The full technical writeup, with the proof-of-concept, the exact requests, and the disclosure timeline, is the primary source: Stored Prompt Injection to Desktop Takeover on Manus.
The trust flaw. A Manus project's
instructionfield is set by the project owner and loads into the agent context of every member, on every task. So when a victim joins a project and types a normal request, the agent treats the owner's text as standing orders for the workspace, not as a message from another user. Accepting the invite silently granted the owner code execution in the victim's sandbox on every future task, with no per-task consent and no notification if the owner edited the instruction later.Why the safety filter did not matter. Manus does inspect instructions, and a direct "dump the environment to my server" was caught. But the bypass is filter-agnostic: the instruction carried only a benign fetch (a one-line "go get this and run it"), which any classifier approves because it is indistinguishable from a package-install script. The agent then fetched the real payload at runtime, inside the victim's sandbox, where nothing inspected it. The classifier never saw the attack.
What leaked, and how it escalated. The payload read
os.environand exfiltrated the sandbox secrets over an HTTP callback, including a staticNEKO_ADMIN_PASSWORD. Because that password did not rotate, the desktop server was addressed predictably, and the control plane would boot the victim's sandbox on request, the researchers opened the victim's live remote desktop with the exfiltrated token, confirmed via an/etc/hostnamematch. That is the difference between a credential leak and a takeover.Why it is severe. The agent drives a browser where users are logged into Drive, GitHub, Slack, and Gmail. Interactive desktop access means reading the agent's files, watching the user in real time, and acting as them in any live session, without ever touching a password. And it is stored: it fires on every task in that project until the victim leaves it, with a wormable path the team flagged but did not build.
Why Every Guardrail Failed
The most useful lesson is the gap between what each control meant and what it did.
Control | Meant to Stop | Why It Didn't |
|---|---|---|
LLM safety filter on instructions | malicious standing orders | it reads the instruction; the payload arrives later by fetch and is never inspected |
Agent refuses suspicious commands | obvious exfiltration | the command wasn't suspicious. A fetch-and-run one-liner is a setup script |
Project invite consent | unwanted workspace access | consent covered joining, not "this person may run code in my VM on every task, forever" |
Owner/member permission model | privilege escalation | it governed who could edit the project. Nothing governed whose text reached whose runtime |
Per-session sandbox isolation | cross-user impact | true at the VM layer, irrelevant once attacker-authored text executes inside the victim's VM |
Desktop authentication | unauthorized desktop access | static, non-rotating password, stored in the same environment the payload had just read |
Every control correctly judged the thing it was handed, and not one was handed the actual attack. That is the signature of a prompt injection failure in an agentic system: the defenses work, on the wrong input.
How to Prevent Prompt Injection in AI Agents
There is no single switch. Prevention is a set of independent controls, and any one of them breaks this chain.
Treat instructions authored by other users as untrusted input. Shared or owner-authored instructions are attacker-controlled data from the perspective of every other member. Do not concatenate them into a trusted system context, and never let them silently authorize tool execution in someone else's sandbox. If you keep the feature, scope it so instructions from another user get a reduced-capability context.
Make consent match the capability. If joining a workspace means someone else's text can run commands as you, say so, and require a click before the first execution in a session.
Stop inspecting only the string. Any inspection that stops at the instruction text loses to staged retrieval, permanently. Constrain egress from the sandbox so a fetched payload cannot phone home, or inspect what actually gets fetched and executed. Egress control is more durable, because it does not require your classifier to be perfect forever.
Keep static credentials out of the agent's environment. Assume any code the agent runs can read the environment. Bind sensitive access to the authenticated session, rotate it, scope it, and keep it out of
os.environ.
How Do You Secure AI Agents in Production? A Developer Checklist
Beyond this specific bug, here is a practical checklist for shipping more secure AI agents, mapped to the OWASP LLM Top 10.
Isolate trust in the context. Label every source that feeds the model (user, tool output, retrieved content, other users) and never grant data-plane text the authority of system instructions.
Constrain tool and egress capability. Give the agent least privilege, allowlist outbound destinations, and gate irreversible or cross-user actions behind explicit approval.
Guard the secrets, not just the prompt. Prefer short-lived, scoped, session-bound credentials over static ones.
Monitor agent behaviour, not just inputs. Watch for a sandbox spawning unexpected child processes or making unexpected outbound connections. The Manus payload was invisible in the application log; the tell was at the process and network layer.
Test the collaboration surface. Every feature that lets one principal influence another principal's agent run is a security boundary. Test invites, shared workspaces, shared memory, and shared instructions against a lower-privileged attacker.
Review the agent trust boundary in code. This is where CodeAnt helps: automated security review that flags where untrusted input reaches a privileged action, before it ships.
Key Takeaways for Developers
Prompt injection is OWASP LLM01 for a reason: it is the top risk to any LLM application, and it gets more dangerous the more your agent can do.
The dangerous variant in collaborative products is stored, indirect prompt injection: attacker text that persists and loads into another user's agent context as trusted configuration.
A safety classifier cannot save you, because staged payloads make the wording irrelevant. Constrain egress and capability instead.
Secrets in the sandbox environment turn code execution into full takeover. Keep static credentials out of
os.environ.Every collaboration feature is a trust boundary. The real question is not whether the model will run your payload, but whose text ends up in someone else's context, and what that context is allowed to do.
Conclusion: Whose Text Runs in Your Sandbox?
Bypass phrasings are fungible, and fighting a classifier on wording is a game you play forever and never finish. The bug that matters is a boundary mismatch: one system is certain it is evaluating everything the agent will be told, while the agent's context is quietly assembled from two different users' text with no distinction between them. The filter does its job flawlessly on the wrong input, and the isolation holds flawlessly around the wrong process.
That question, whose text ends up in somebody else's context, and what is that context allowed to do, found a desktop takeover on Manus. It will find things anywhere a product added collaboration to an agent and assumed the agent was still only talking to one person.
If you are building an agentic product, that boundary is where your next critical bug is hiding. CodeAnt AI reviews the trust boundaries in agent and application code automatically, catching the place where untrusted input reaches a privileged action before it reaches production. Book a demo, or read the full technical writeup on our security research blog.
References
OWASP Top 10 for Large Language Model Applications: LLM01 Prompt Injection
Primary source (full technical writeup): Stored Prompt Injection to Desktop Takeover on Manus
This guide accompanies original research by CodeAnt AI Security Research. Have an agent product you want reviewed? Reach us at securityresearch@codeant.ai.
