We take the security of ManusGPT seriously. Given that ManusGPT operates with real OS-level access (shell execution, file system manipulation, mouse/keyboard control), security vulnerabilities can have significant real-world impact.
Preferred Method: Use GitHub Security Advisories to submit a private vulnerability report. This ensures only maintainers can see the report while it's being investigated.
Alternative Method: Open a GitHub Issue with the [SECURITY] tag in the title. Example:
[SECURITY] Permission gate bypass allows unauthorized file deletion
Please include the following in your report:
- Description of the vulnerability and its potential impact
- Steps to reproduce the issue (as detailed as possible)
- Affected versions of ManusGPT
- Proof of concept (code, screenshots, or screen recordings)
- Suggested fix (if you have one β optional but appreciated)
- Environment details (OS, Node.js version, Electron version, LLM provider)
- Acknowledgment β We will acknowledge your report within 48 hours.
- Assessment β We will evaluate the vulnerability and determine its severity.
- Resolution β We will develop and release a fix as soon as possible.
- Credit β With your permission, we will credit you in the security advisory and release notes.
- Coordination β We will work with you to coordinate a responsible disclosure timeline.
- Do NOT publicly disclose the vulnerability before a fix has been released.
- Do NOT exploit the vulnerability for any purpose other than demonstrating it for the report.
- Allow reasonable time for us to develop and deploy a fix (typically 90 days for critical, 30 days for high/medium).
- Destroy any proof-of-concept materials after the issue is resolved.
| Version | Supported | Security Updates |
|---|---|---|
v2.0.x (latest) |
β Yes | Active |
v1.x.x |
β No | End of life |
Pre-release (main branch) |
Monitoring |
Security fixes are applied to the latest release branch. Older versions receive security updates only for critical vulnerabilities.
ManusGPT operates in a unique security context β it is an autonomous agent with genuine OS-level capabilities. Our security model is designed around defense in depth:
User Request
β
βΌ
βββββββββββββββββββββββββββ
β PERMISSION GATE β
β β
β ALLOW β Auto-execute β
β ASK β Prompt user β
β DENY β Block action β
βββββββββββββββββββββββββββ
β
βΌ
Tool Execution
Every tool invocation passes through the 3-tier permission system. Users can configure per-tool, per-action, and per-context rules. Sensitive operations (file deletion, system commands, God Mode) default to ASK or DENY.
A dedicated filter detects and blocks obviously destructive commands before they reach the permission gate. This includes:
- Recursive deletions (
rm -rf /) - Disk formatting commands
- Kernel-level modifications
- Credential dumping
- Network exfiltration patterns
This layer operates before user confirmation β even if a user accidentally allows a dangerous command, it will be intercepted.
The Identity Guard protects the agent's core reasoning from adversarial manipulation:
- 30+ injection patterns detected (prompt injection, jailbreak attempts, role confusion)
- Output sanitization to prevent the agent from echoing malicious instructions
- Context boundary enforcement to prevent data leakage between sessions
- Tool output validation to detect and sanitize adversarial payloads returned by tools
| Boundary | Enforcement |
|---|---|
| Main β Renderer | Electron's contextIsolation + sandbox enabled. IPC bridge only exposes approved channels. |
| Agent β OS | All OS interactions route through the Permission Gate. No direct system access from the renderer process. |
| LLM β Agent | LLM outputs are parsed through a schema validator. Malformed or unexpected tool calls are rejected. |
| Sessions | Each session has isolated memory and context. Cross-session search is explicit and user-controlled. |
- LLM outputs are probabilistic β cleverly crafted prompts may bypass injection detection. This is an inherent limitation of current AI technology.
- God Mode is inherently dangerous β real mouse/keyboard control means the agent can interact with anything on screen. The Permission Gate is the primary defense.
- Browser automation can access authenticated sessions β if the user is logged into websites, the agent's browser tool can interact with them. Users should be aware of this when granting browser permissions.
- Local LLMs have no content filter β models running via Ollama, LM Studio, or node-llama-cpp do not have the safety filters present in cloud-hosted models.
We recommend the following configuration for maximum security:
{
"permissions": {
"bash": "ASK",
"python": "ASK",
"editor": "ASK",
"browser": "ALLOW",
"system_control": "DENY",
"god_mode": "DENY"
},
"identityGuard": {
"enabled": true,
"strictMode": true
},
"catastrophicRejection": {
"enabled": true
}
}Security is a shared responsibility. We are grateful to researchers and users who help keep ManusGPT safe. If you have questions about our security practices, please don't hesitate to reach out.
ManusGPT Security Team
ManusAgents