What happened
On October 1, 2026, Salt Labs published its Manus research and said the responsibly disclosed vulnerability had been resolved.
In the controlled proof of concept, the test user asked Manus to check email, and one attacker-supplied message caused code execution inside the agent environment and exposed credentials available to that environment. The researchers reported that an obvious instruction and Base64-obfuscated code were detected, while JSFuck symbol-only obfuscation passed through and the warning arrived after execution.
Agent or framework: Manus was the agentic AI platform tested. Underlying model: The cited sources did not identify an underlying model or version. Operator configuration: The proof of concept connected Manus to Gmail through MCP-based tooling with the test user’s authorised Gmail access token. Mechanical action: Manus provisioned a dedicated cloud sandbox, processed the email, and executed the resulting operations against connected services before the warning could stop the action.
Salt Security said the vulnerability was responsibly disclosed, resolved and no longer exploitable when the research was published. The cited sources did not publish a CVE, malicious-domain or IP indicators, affected enterprise count or evidence that the chain was exploited against real users.
Why this matters now
The Manus flaw is fixed and the research did not establish real-world exploitation. Its importance is architectural: untrusted email content reached an agent with authorised access to connected services, and a warning occurred after mechanical execution. That failure mode applies to any agent whose content inputs and privileged tools share one automated workflow.
Traditional email security, model guardrails and API controls each see only part of the path. Security leaders need one policy decision spanning the content source, agent runtime, MCP tooling, service identity, token scope and downstream action. Detection that cannot interrupt execution is insufficient for password resets, repositories, cloud administration, financial workflows or production changes.
The research also changes assurance questions for AI suppliers. Enterprises need to know which models and runtimes process untrusted content, where credentials are stored, whether tools run in isolated environments, which actions require approval and how providers prove that a disclosed prompt-injection chain has been eliminated.
The decision for security leaders
Govern agents as privileged non-human identities. The owner should document each agent’s content sources, tools, tokens, downstream systems, approval boundaries and maximum business impact rather than approving a generic AI use case.
Require enforcement between model output and tool execution. High-impact actions should use deterministic policy checks, least-privilege service identities, transaction limits and human approval where delay is acceptable. A model-generated warning that arrives after execution is not a preventive control.
Demand supplier evidence describing the corrected attack path, credential isolation, sandbox boundaries, security-test coverage and integration-specific exposure. For other connected agents, use this proof of concept as a test case rather than assuming the Manus fix resolves an architectural class.
Evidence of closure
- Agent register records content sources, tools, identities, token scopes and accountable owners.
- Policy test proves high-impact tool calls are blocked or approved before execution.
- Credential review confirms short-lived, task-scoped tokens isolated from the agent runtime.
- Supplier assurance documents the fixed chain, affected integrations and residual limitations.
The Security.io assessment
The finding is not evidence that Manus users were broadly compromised. It is a controlled demonstration of how low-trust content can traverse an agent workflow and reach high-trust credentials or connected actions. The disclosed chain was fixed before publication.
The decisive control gap was temporal and architectural: detection occurred, but execution had already happened. Enterprise agent reviews should therefore measure whether policies can block tool calls and credential use synchronously, not only whether the model recognises malicious text.
Attribution posture: This was a controlled proof of concept, and the cited sources identified no real-world attacker or victim exploitation.
Security.io assigns medium confidence. The mechanics are supported by original research and independent reporting, while the underlying model, affected-version scope, CVE status, provider-side technical fix and independent reproduction were not published in the cited sources.
Questions for the morning meeting
- Which enterprise agents can read email or invoke connected services without per-action approval?
- Are agent credentials isolated, short-lived and scoped to one workflow?
- Can security stop an agent action synchronously rather than alert after execution?