Security Model
Relevant source files
The following files were used as context for generating this wiki page:
M31 Autonomous (M31A) implements a multi-layered security architecture designed to mitigate the risks associated with an AI agent executing code and shell commands. The model operates on the principle of defense-in-depth, combining process-level sandboxing, permission gating, network protections, and automated source scanning.
The security scope covers the entire task lifecycle, from credential management in the OS keychain to the runtime verification of generated code. By default, the system prioritizes user control through explicit permission prompts for high-risk operations.
Sources: SECURITY.md:15-18, README.md:168-185
Core Security Layers
The security model is organized into several distinct layers that protect different aspects of the system.
| Layer | Mechanism | Purpose |
|---|---|---|
| Permission Gating | Modal prompts (allow/deny/always) | Ensures human-in-the-loop control for all Bash commands. |
| Sandboxing | Landlock (Linux), sandbox-exec (macOS) | Restricts filesystem access for subprocesses to specific directories. |
| Network Protection | SSRF & DNS Rebinding protection | Prevents the agent from accessing internal networks or performing TOCTOU attacks. |
| Credential Safety | OS Keychain integration | Encrypts API keys and prevents plaintext storage on disk. |
| Content Scanning | Security Heuristics | Scans generated code for hardcoded secrets or dangerous anti-patterns. |
Sources: SECURITY.md:20-31, README.md:170-184
Permission and Rate Limiting
M31A utilizes a token-bucket rate limiter to prevent runaway tool execution. Normal tools are limited to 20 burst/10 sustained tokens, while "dangerous" tools are restricted to 5 burst/2 sustained tokens. All Bash commands require explicit permission unless configured otherwise, and high-risk commands (e.g., rm, chmod, git reset) are subject to additional blocklist checks.
Sources: SECURITY.md:22-26, README.md:179-183, internal/engine/workflow/prompts/tool-use.md:9-11
Process Sandboxing
The system applies platform-specific sandboxing for the Bash tool to isolate the execution environment.
The sandboxing architecture ensures that subprocesses have restricted access to the filesystem. On Linux, Landlock restricts access to the work directory and essential system paths. On all platforms, environment scrubbing removes sensitive API keys and tokens from the subprocess environment before execution.
Sources: SECURITY.md:35-46, scripts/validate-release.sh:424-434
Network & SSRF Protection
M31A implements protections for web-based tools (WebFetch and WebSearch) to prevent Server-Side Request Forgery (SSRF) and DNS Rebinding attacks.
- SSRF Protection: The
WebFetchtool explicitly blocks requests to private, loopback, and link-local IP addresses (e.g.,127.0.0.1,10.x.x.x,169.254.x.x). - DNS Rebinding:
WebSearchuses a DNS cache with a 5-minute TTL to prevent Time-of-Check to Time-of-Use (TOCTOU) attacks where an attacker changes a DNS record after initial validation.
Sources: SECURITY.md:28-29, scripts/validate-release.sh:408-413, README.md:181-182
Automated Security Verification
During the Verify phase of the workflow, the engine performs automated security scans on any files created or modified during the task.
Security Heuristics
The engine scans for specific patterns that indicate security vulnerabilities or hardcoded credentials.
Monitored Anti-Patterns
The system tracks several classes of security findings:
| Severity | Pattern Example | Description |
|---|---|---|
| High | sk-, api_key, TLS_INSECURE | Hardcoded secrets or disabled encryption. |
| Medium | eval(, exec(, TODO: security | Dynamic code execution or explicit security debt. |
| Low | innerHTML, 0.0.0.0 | Potential XSS or overly broad interface binding. |
Sources: internal/engine/workflow/verify_report.go:73-95, internal/engine/workflow/verify_report.go:167-171
Credential Management
API keys for providers (OpenRouter, Zen, Nvidia) are never stored in plaintext. M31A integrates with the native OS keychain for secure storage.
- Linux: Uses
dbus/ Secret Service. - macOS: Uses the system Keychain.
- Windows: Uses Credential Manager.
Path traversal protection is applied to keychain service names to prevent unauthorized access to sensitive system secrets.
Sources: README.md:177-178, scripts/validate-release.sh:460-466, SECURITY.md:30
Conclusion
The security model of M31A is designed to provide a "safe-by-default" experience for developers. By combining OS-level sandboxing with heuristic scanning and strict permission gating, it ensures that while the AI agent has the power to modify codebases and run commands, it remains constrained within boundaries defined by the user and the system's security policies.
Sources: SECURITY.md:49-52, README.md:187