How to Read This Table

• Surface — the primary attack-reachable interface. CLI/TUI implies local-only; "Gateway" / "Web UI" / "webhook" implies anything that touches the network.
• Auth (default) — green where the harness ships with a non-bypassable identity check, amber where it's optional or shared-secret, red where there is no built-in auth on the network surface.
• Sandbox (default) — green if container/VM isolation is the out-of-the-box runtime; amber if available but opt-in; red if the agent runs with full user privileges unless you wrap it yourself.
• Plugin marketplace — every entry here is also a confirmed supply-chain attack vector. Treat marketplace installs the same way you treat npm install in production.
• Notable CVE — links go to vendor advisories / vendor write-ups in each per-platform tab. Absence (—) means no public CVE at time of writing; not a clean bill of health.

Audit Your Effective Permissions

Run /permissions inside Claude Code to inspect every active allow/ask/deny rule and the settings.json file each came from. Rules merge across managed > project > local > user scope; deny always wins.

Tip: rules evaluate deny → ask → allow — a single managed deny cannot be overridden by --allowedTools or local settings.

Inspect Repo-Shipped Config Before First Launch

Check Point's research (CVE-2025-59536 / CVE-2026-21852) showed that hooks, enableAllProjectMcpServers, and ANTHROPIC_BASE_URL inside a cloned repo's .claude/settings.json and .mcp.json could execute or exfiltrate credentials before the trust dialog. Always read these files manually before running claude in an unfamiliar checkout.

Tip: keep Claude Code updated (claude update) — the above CVEs were patched before 25 Feb 2026.

Use a Deny-First Permission Policy

Write explicit deny rules for secrets, VCS push, and network exfil tools in .claude/settings.json. Pair a Bash allow with targeted denies rather than Bash(*) blanket allow.

Tip: argument-constraint patterns like Bash(curl https://github.com/*) are fragile (redirects, variables, extra spaces bypass them). Deny curl/wget outright; rely on WebFetch(domain:...) for HTTP egress.

Never Use --dangerously-skip-permissions on Your Host

The flag (and equivalent bypassPermissions mode) disables every prompt; the agent runs with your full user identity. An October 2025 rm -rf incident walked from / and destroyed user-owned files. Restrict to disposable containers or CI runners.

Tip: at the org level, add "permissions": { "disableBypassPermissionsMode": "disable" } to managed settings so users cannot opt themselves in.

Enable OS-Level Sandboxing for Bash

/sandbox enables Seatbelt (macOS) or bubblewrap (Linux/WSL2) to enforce filesystem and network limits at the kernel level — these survive even a successful prompt injection.

Tip: avoid broad allowedDomains like *.github.com — the proxy does not inspect TLS, so domain fronting can exfiltrate data.

Allowlist MCP Servers, Block Auto-Init

MCP tool descriptions are read by the model and can carry injected instructions; a compromised server can exfiltrate file contents via tool responses. Pin servers explicitly and disable auto-trust of project MCP config.

Tip: in managed settings, set allowManagedMcpServersOnly: true so only org-approved MCP servers load regardless of repo .mcp.json.

Enforce Guardrails with PreToolUse Hooks

A PreToolUse hook that exits 2 (or returns permissionDecision: "deny") blocks a tool call even under bypassPermissions / --dangerously-skip-permissions. Use for non-negotiable rules: blocking writes to .git/, .claude/, secret files.

Tip: lock down hook config itself with ConfigChange hooks and allowManagedHooksOnly: true in managed settings — otherwise the model can rewrite its own guardrails mid-session.

Treat Untrusted Content as Injection Vectors

Indirect prompt injection rides in on READMEs, issue bodies, web pages, dependency comments, and MCP tool descriptions. Claude Code's WebFetch isolates fetched HTML in a separate context window, but you should still review proposed changes and never pipe untrusted text directly into the prompt.

Tip: keep first-time codebase trust verification on. claude -p (non-interactive) disables trust dialogs except when paired with --worktree.

Protect Credentials and Env Vars

Claude Code stores API keys encrypted via OS keychains, but env vars are not. CVE-2026-21852 exfiltrated tokens via ANTHROPIC_BASE_URL set in a repo-shipped settings.json. Keep secrets in a vault, not .env, and deny reads on dotfiles.

Tip: pin ANTHROPIC_BASE_URL in user/managed settings so a repo cannot redirect API traffic to an attacker proxy.

Centralize Policy and Monitor Usage

For teams, ship a managed settings file (/etc/claude-code/managed-settings.json on macOS/Linux, HKLM key on Windows) with allowManagedPermissionRulesOnly: true, disableBypassPermissionsMode: "disable", allowManagedHooksOnly: true, and forceRemoteSettingsRefresh: true. Pipe activity to OpenTelemetry for audit.

Tip: rotate any token Claude touched if a session shows unexpected outbound requests or sandbox violations, and report incidents via Anthropic's HackerOne program.

Enforce Privacy Mode and Zero Data Retention

Cursor uploads code chunks for embeddings, completions, and chat. Privacy Mode triggers Zero Data Retention (ZDR) contracts with model providers so no code is stored or used for training. On by default for team members; verify per-user.

Path: Cursor Settings → General → Privacy Mode.

Tip: for Teams/Enterprise, enforce Privacy Mode org-wide via the admin dashboard so it cannot be toggled off locally; pair with telemetry.telemetryLevel: "off".

Disable Auto-Run / YOLO Mode

Auto-Run lets the agent execute terminal commands without approval. Backslash Security demonstrated 4+ ways to bypass the denylist (base64, obfuscation, shell builtins) and Cursor deprecated the denylist in v1.3.

Path: Cursor Settings → Chat → Enable auto-run mode (toggle OFF). If required, configure Allowlist with a minimal set; never include rm, curl, wget, find, bash, sh, python, node, pip, npm.

Tip: treat the allowlist as defense-in-depth, not a boundary. Always review commands before approval.

Enable Workspace Trust Before Opening Unknown Repos

Cursor inherits VS Code's Workspace Trust but ships it disabled. A repo with .vscode/tasks.json runOptions.runOn: folderOpen runs on clone (Oasis Security "Open-Folder Autorun").

Tip: open unknown repos in a disposable VM or container; never as a trusted workspace.

Lock Down MCP Server Configuration

Both CurXecute and MCPoison abused ~/.cursor/mcp.json and <project>/.cursor/mcp.json. CurXecute is fixed in v1.3, case-sensitivity bypass in v1.7. Run a current version.

Paths to audit: ~/.cursor/mcp.json, <repo>/.cursor/mcp.json — chmod 600 on macOS/Linux; track in Git with mandatory PR review (add to CODEOWNERS).

Tip: use OAuth with minimum scopes; reference secrets via ${env:VAR_NAME} in mcp.json. Enterprise admins should publish a centralized MCP allowlist.

Harden Rules Files Against Hidden-Unicode Injection

Rules files (.cursorrules, .cursor/rules/*.mdc) apply to every AI interaction in the workspace, making them a supply-chain attack vector. Researchers demonstrated zero-width joiners and bidirectional control characters that silently instructed the model to insert backdoors.

Check: pre-commit hook that rejects rules files containing Unicode categories Cf (format) or characters in U+200B-U+200F, U+202A-U+202E, U+2066-U+2069.

Tip: add .cursorrules and .cursor/rules/ to CODEOWNERS, require human review on every change, render with a hex viewer when in doubt.

Exclude Secrets via .cursorignore (with Caveats)

.cursorignore blocks Tab, semantic search, inline edit, and @mention access. Critically, Cursor docs state: "terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore" — the agent can still cat ignored files.

Tip: defense-in-depth only. Combine with OS-level secret stores (Keychain, Vault, AWS Secrets Manager) and pre-commit secret scanning (gitleaks, trufflehog).

Restrict Indexing Scope

Indexing uploads chunks to compute embeddings. Reducing index surface limits blast radius if a workspace contains secrets or proprietary IP.

Path: Cursor Settings → Features → Codebase Indexing — disable on sensitive repos, or use .cursorindexingignore for node_modules, dist, vendor, build artifacts. Consider disabling Shadow Workspace if not required.

Tip: for highly sensitive monorepos, turn indexing off entirely and rely on explicit @file/@folder references.

Run the Agent in a Sandbox / Isolated User Account

Even with auto-run off, accidental approvals or rule injection can yield code execution at developer privileges. Cursor 2.5+ supports Sandbox Mode with network restrictions; combine with OS-level isolation.

Implementation: dedicated macOS user account or Linux container (Docker/Podman, non-root, no host SSH keys mounted); on macOS use App Sandbox / TCC restrictions to deny access to ~/.ssh, ~/.aws, ~/Library/Keychains. On Linux, AppArmor / bubblewrap profiles.

Tip: never run agent mode as root or with cloud admin credentials in the environment.

Manage Extensions and Treat Untrusted Inputs as Hostile

Cursor uses Open VSX. A June 2025 malicious extension on Open VSX was linked to a $500K crypto theft. Every MCP tool that returns external content (Jira/GitHub issues, Slack, web search, email) is an injection vector — the CurXecute attack class.

Action: audit installed extensions; remove any with <10k installs, unverified publishers, or no updates in >12 months. Enterprise admins should publish an extension allowlist via MDM.

Mitigation: disable MCP servers whose tool output you cannot trust. For browser/web MCPs, never enable auto-run. Review every diff and command the agent proposes — especially writes to .cursor/, .vscode/, ~/.cursor/, ~/.ssh/, CI config, and package.json scripts.

Enterprise Governance: SSO, SCIM, Audit Logs, Model Blocklist

For team deployments, push enforcement off the endpoint and onto identity/policy.

Path: Cursor Admin Dashboard → Identity & Access for SAML 2.0 SSO (Okta, Entra, Google Workspace), SCIM 2.0 provisioning, RBAC; → Compliance for audit log export (SIEM streaming on Enterprise); → Model Controls to enforce a model blocklist and CMEK on Enterprise.

Tip: enforce SSO + disable local login, automate offboarding via SCIM, stream audit logs to a SIEM, block models that lack ZDR contracts, and apply MDM policies for non-bypassable Privacy Mode and Workspace Trust.

Audit Installation Provenance and Pin a Known-Good Version

The Clinejection incident (Dec 2025 – Feb 2026) showed attackers can publish unauthorized Cline releases to npm and the VS Code Marketplace by hijacking the maintainer publish workflow. Treat the extension as an untrusted dependency.

Setting: VS Code → Extensions → saoudrizwan.claude-dev → "Install Specific Version"; CLI: npm install -g @cline/cli@<pinned-version>.

Tip: pin to a vetted version no earlier than v3.35.0, disable auto-update for the extension, verify the publisher ID matches saoudrizwan, review the GitHub release SHA before bumping.

Keep the Cline Panel and Task History Private

Cline's chat pane renders markdown images inline; loading attacker-controlled URLs is the documented data-exfiltration channel for .env contents. Task history and checkpoint snapshots persist transcripts on disk under .cline/ (workspace) or ~/.cline/data/ (CLI).

Tip: never screen-share the Cline panel with live secrets in scope; periodically purge task history and checkpoint stores; treat them like shell history files.

Disable Auto-Approve; Turn YOLO Mode Off

Cline Settings → Features exposes nine auto-approve toggles plus a YOLO Mode checkbox. There is no fixed allowlist — the model itself decides requires_approval per command, which Mindgard showed can be overridden via .clinerules.

Path: Cline panel → gear icon → Settings → Features → Auto-Approve.

Tip: leave Execute all commands, Edit all files, Read all files, Use the browser, and YOLO Mode off. Permit at most Read project files and Execute safe commands. Set "Max Requests" to a low number (e.g. 20) so a runaway task pauses.

Isolate the Workspace with a DevContainer or Remote SSH Host

Cline executes shell commands and writes files with the privileges of the VS Code process — on a developer laptop, that means full access to ~/.ssh, ~/.aws, browser cookies, and any mounted drives.

Setting: .devcontainer/devcontainer.json with "remoteUser": "vscode", no SSH-agent forwarding, no host volume mounts for ~; or VS Code Remote-SSH to a disposable VM where Cline is installed on the remote host only.

Tip: run Cline inside a container or ephemeral VM with no credentials mounted; never install Cline on a machine that also stores production secrets or signing keys.

Restrict File Access with .clineignore; Lock Down .clinerules

ClineIgnoreController enforces .clineignore (gitignore syntax) to block reads/writes/listings, and .clinerules/ files are injected into the system prompt every task. Mindgard's CVE class abused .clinerules to disable approval gates; Embrace The Red's PoC abused unrestricted reads of .env.

Tip: treat .clinerules/ as security-sensitive — review every file in PRs, never accept rules from untrusted forks, disable rules in the management panel when not in use.

Constrain the Terminal Tool — No Broad Shell Auto-Approval

execute_command runs through VS Code shell integration. The model-assigned requires_approval flag is documented in the system prompt and therefore known to attackers; DNS-exfil via ping $(cat .env) was demonstrated.

Setting: Cline Settings → Features → "Execute safe commands" only; "Execute all commands" off.

Tip: require manual approval for every command in untrusted repos; on Linux/macOS dev VMs, drop egress for the Cline user (firewall rules blocking DNS/HTTP except to allowed LLM/MCP endpoints) to neutralize DNS- and image-based exfiltration.

Protect BYOK Credentials — Keep Keys Out of the Workspace

Cline stores API keys in the VS Code Secrets API (extension storage, encrypted at rest) and the CLI stores them in ~/.cline/data/secrets.json. Project .env files have historically collided with Cline-configured keys (issue #714) and are also the primary exfil target in known PoCs.

Setting: Cline Settings → API Configuration (provider, key); CLI: cline config set.

Tip: enter keys through the Cline settings UI only — never via a workspace .env Cline can read; use scoped, rate-limited, short-lived keys; rotate after any suspected injection; prefer the Cline Provider gateway or an internal LLM gateway.

Vet MCP Servers — Never One-Click Install from the Marketplace

MCP tool descriptions are strings rendered into the LLM context, so a malicious server can inject persistent instructions, shadow legitimate tools, or pivot the agent. Configs live at ~/.cline/mcp.json (CLI) and the IDE Configure tab.

Setting: MCP Servers icon → Configure → JSON; per-server autoApprove: [] array; disabled and timeout fields.

Tip: install MCP servers only from sources you would npm install from in production; keep autoApprove empty; pin server versions; pass secrets via env vars not config literals; review every new tool's description text before first use.

Defend Against Indirect Prompt Injection in Untrusted Content

Cline ingests repo files, docstrings, markdown, web fetches, issue/PR text, and MCP output as plain context. Confirmed attack vectors: malicious Python docstrings, .clinerules overrides, markdown image URLs that exfiltrate via the rendered chat, TOCTOU staging across multiple file edits.

Setting: Cline Settings → Features → "Use the browser" off; review checkpoint diffs before continuing a task.

Tip: when analyzing an unknown repo, start with auto-approve fully off; never let Cline open a PR or issue body from an external contributor without reading it yourself first; rely on checkpoints to roll back and inspect.

Configure Telemetry, Audit Logs, and Enterprise Gateway

Cline ships a pluggable telemetry provider (PostHog by default, with OpenTelemetry and no-op options). Issues #3361 and #7068 document cases where data was transmitted with telemetry "disabled," so verify behavior rather than trusting the toggle. Enterprise deployments can route LLM traffic through the Cline Provider gateway.

Setting: Cline Settings → Advanced → Telemetry (off); enterprise: OpenTelemetry endpoint per enterprise-solutions/monitoring/telemetry docs.

Tip: in regulated environments, set telemetry to no-op and confirm with a network trace; route all provider calls through your own gateway (egress allowlist to that gateway only); ship Cline event logs and command-execution audit trail to your SIEM.

Pin a Patched Version; Treat the Archived Extension as Frozen

Roo Code was archived on 15 May 2026 with no further security fixes coming from upstream. Every 2025 advisory only became safe at or after v3.26.7.

Setting: VS Code → Extensions → RooVeterinaryInc.roo-cline → "Install Specific Version"; disable auto-update for the extension.

Tip: pin to v3.26.7 or later, verify publisher ID RooVeterinaryInc, mirror the VSIX internally, evaluate migrating to a maintained fork (README points to ZooCode and back to Cline) since no further CVEs will be patched.

Disable Auto-Approve by Default; Never Enable Write or Execute Globally

The Auto-Approve dropdown exposes eight toggles — Read Operations, Write Operations, Command Execution, Browser Usage, MCP Servers, Mode Switching, Subtask Management, Follow-Up Questions — plus "Include files outside workspace" and "Include protected files" sub-options that bypass .roo/, .vscode/, and .rooignore protection. Every high-severity Roo advisory requires auto-approved writes or auto-approved execute to fire.

Setting path: Roo Code sidebar → Auto-Approve dropdown (Cmd+Alt+A / Ctrl+Alt+A) → uncheck Write, Execute, Browser, MCP, "Include files outside workspace", "Include protected files".

Tip: keep only "Read Operations" auto-approved if anything; require manual approval for every command on third-party repos; use the bottom-right Enabled master switch to pause approvals during code review.

Lock Down Command Execution with Denylist + Allowlist

execute_command parsing has been bypassed repeatedly: missing \n validation (fixed 3.23.19), zsh validation error (3.26.7), bash parameter expansion (3.26.0), process substitution + & (3.25.5), npm install postinstall (3.26.0).

Setting: Settings → Auto-Approve → Execute → "Allowed Commands" and "Denied Commands"; pick Inline Terminal or VS Code Terminal under terminal mode.

Tip: keep "Allowed Commands" minimal (e.g. npm test, tsc --noEmit, git status); never include npm install, yarn, pip, curl, bash, sh, zsh; deny curl, wget, nc, ssh, scp; firewall egress to backstop parser bypasses.

Ship a Strict .rooignore and Validate Symlink Hygiene

.rooignore (gitignore syntax at workspace root) blocks read_file, write_to_file, apply_diff, list_files. GHSA-p76r-7mc3-qh7c (Moderate, fixed 3.26.0) showed symlinks inside the workspace could redirect reads outside .rooignore coverage to expose .env.

Tip: run on v3.26.0+ so post-symlink validation is active; periodically find . -type l to audit new symlinks committed by collaborators.

Treat .roomodes, .vscode/settings.json, .code-workspace as Protected Config

Three high-severity RCEs (GHSA-3765-5vjr-qjgm .vscode/settings.json, GHSA-4pqh-4ggm-jfmm .code-workspace, GHSA-5x8h-m52g-5v54 .roo/mcp.json) all exploited the same pattern: prompt injection + auto-approved writes lets the agent rewrite a config file VS Code or Roo later executes.

Setting: keep Auto-Approve → Write → "Include protected files" disabled; the protected list covers .vscode/, *.code-workspace, everything under .roo/.

Tip: review .roomodes, .vscode/settings.json, .code-workspace, .roo/mcp.json in every PR like a CI workflow; never accept these files from forks without diffing; commit under CODEOWNERS.

Constrain Custom Modes — Use fileRegex and Minimal Tool Groups

Custom Modes in .roomodes (project) or custom_modes.yaml/.json (global) define slug, name, roleDefinition, groups, optional fileRegex. The four tool groups — read, edit, command, mcp — are the actual capability gates. A malicious .roomodes shipped via a repo can silently broaden capabilities.

Setting: project file .roomodes (YAML preferred); edit globally via Command Palette → "Roo Code: Edit Global Modes".

Tip: for docs/reviewer modes, give only read + edit with fileRegex: "\\.(md|mdx|txt)$"; never grant command and mcp together in the same custom mode; review .roomodes on first open of any new repo.

Keep Orchestrator / Boomerang Strict — No read/command by Default

Orchestrator mode (🪃) delegates subtasks to specialized modes. By design it cannot read files, write files, call MCPs, or run commands — the docs explicitly call this out as context-poisoning protection. Adding any of those groups collapses the isolation.

Setting: Command Palette → "Roo Code: Edit Global Modes" → orchestrator entry; Auto-Approve → "Always approve creation & completion of subtasks" toggle.

Tip: leave Orchestrator's groups empty by default; keep "Always approve subtasks" off so subtask handoffs require human confirmation (each handoff is also an injection boundary worth eyeballing).

Pin and Audit MCP Servers; Never Auto-Approve MCP Tools

MCP configs live in two places: global mcp_settings.json and project .roo/mcp.json. Project overrides global. Each server entry supports command, args (with ${env:VAR} substitution), env, alwaysAllow, disabled, disabledTools, timeout. GHSA-5x8h-m52g-5v54 (fixed 3.20.3) showed .roo/mcp.json being rewritten by an injected agent to add an attacker-controlled STDIO server.

Setting: MCP Servers panel → gear → "Edit Global MCP" / "Edit Project MCP".

Tip: keep alwaysAllow: [] on every server; prefer STDIO over SSE/Streamable HTTP; pass secrets through env not args; pin server versions; set disabled: true for any server not actively used.

Protect API Keys; Export Files Are Plaintext

Roo Code stores provider keys in VS Code's Secret Storage, but Settings → Export writes a roo-code-settings.json with API keys in plaintext, and roo-cline.autoImportSettingsPath will load such a file on startup — making it a credible attack target on shared machines.

Setting: Settings → API Configuration Profiles; storage override via roo-cline.customStoragePath; auto-import via roo-cline.autoImportSettingsPath.

Tip: never commit roo-code-settings.json to a repo; if you must export, encrypt the file (age, gpg) and delete the plaintext copy; do not set autoImportSettingsPath to a workspace-relative path; use short-lived scoped keys and rotate after any suspected injection.

Isolate the Workspace and Defend Against Indirect Injection

Every Roo RCE chain begins with attacker-controlled content (docstrings, READMEs, issue bodies, web fetches, MCP tool descriptions) entering the LLM context and convincing the agent to write a config file or run a command. The defenses are environmental.

Setting: .devcontainer/devcontainer.json with no SSH-agent forwarding and no ~ mount; or Remote-SSH to a disposable VM where Roo Code is installed only on the remote side.

Tip: never run Roo Code on a host holding production secrets, signing keys, or browser cookies; firewall egress to your LLM/MCP endpoints only; open untrusted repos with Auto-Approve off and .rooignore covering all secret paths.

Audit Your Install and Pin a Known-Good Version

CVE-2026-33718 (command injection via get_git_diff()) was patched only in 1.5.0. Pull pinned images, never :latest.

Tip: subscribe to All-Hands-AI/OpenHands GitHub Security tab; diff config.template.toml between upgrades; rebuild runtime image after every bump (sandbox.force_rebuild_runtime = true).

Keep the UI Off the Public Internet

OpenHands' web UI binds to 0.0.0.0:3000 in the official docker run example and has no native login. Anyone who reaches the port owns your agent, your repos, and your LLM bill.

Tip: never publish :3000 directly; access over SSH tunnel, WireGuard, or Tailscale. If LAN access is required, set WEB_HOST and front it (next section).

Put an Auth Gateway in Front

Because there is no built-in user auth, terminate TLS and authenticate at a reverse proxy (nginx/Caddy/Traefik + OAuth2-Proxy, Cloudflare Access, or Tailscale Funnel + ACL). Also set a strong jwt_secret.

Tip: enforce SSO at the proxy, require WebSocket upgrade on /socket.io, rate-limit /api/conversations/*. Block all paths for unauthenticated users — the API has no second auth layer behind it.

Lock Down the Sandbox Runtime

The Docker runtime is the only boundary between the agent and your host. Run it as an unprivileged UID, off the host network, with no extra capabilities, minimal pinned base image. Avoid LocalRuntime outside disposable VMs.

Tip: consider RemoteRuntime (runtime.all-hands.dev), E2B, or Daytona for untrusted tasks. Never set use_host_network = true on a multi-tenant box.

Restrict Workspace Mounts and File Uploads

sandbox.volumes bind-mounts host paths into the container with the UID you chose — if you mount ~, the agent can read your SSH keys. Mount only the project directory, prefer :ro for anything you don't want rewritten.

Tip: never mount ~/.ssh, ~/.aws, ~/.docker, ~/.config/gh.

Restrict the Agent's Tool Surface

Each enabled tool is an attack primitive. Disable browsing if the task does not need internet (browser-rendered Markdown images were the exfil path in the GITHUB_TOKEN incident).

Tip: ship two profiles — coding.toml (no browser, no jupyter) and research.toml (browser on, no shell). Switch via --config-file.

Protect LLM Keys, OAuth Tokens, and Secrets

config.toml's [llm] api_key lands on disk in plaintext; conversation containers receive GITHUB_TOKEN / provider keys as env vars — exactly what the prompt-injection PoC exfiltrated. Inject secrets at runtime from a vault or --env-file.

Tip: issue scoped GitHub tokens (single repo, no delete_repo, short TTL); rotate jwt_secret and all provider keys after any suspected injection.

Vet MCP Servers and Pin Them

OpenHands V1 reads ~/.openhands/mcp.json; any server can run arbitrary code (stdio) or call arbitrary HTTPS endpoints (http/sse). npx -y mcp-remote ... pulls current code from npm on every launch — supply-chain risk.

Tip: pin versions (npx -y mcp-remote@1.2.3), prefer vendored stdio binaries over npx/uvx, run openhands mcp disable <name> for anything unused, review each server's tool schema.

Use confirmation_mode + security_analyzer (Avoid Bare Headless)

In the web UI, set [security] confirmation_mode = true so the agent pauses before destructive actions. For CLI add a security_analyzer ("llm" or "invariant"). Headless mode ignores confirmation (always-approve) — never point it at untrusted tickets.

Tip: for CI, run headless only against trusted prompts; for human-in-the-loop sessions, keep confirmation on for run, write, browse, and any MCP tool call. Treat any security_risk: HIGH as auto-reject.

Defend Against Prompt Injection (Lethal Trifecta)

Published exfil chain: untrusted web content → agent renders Markdown image → URL contains base64-encoded ghp_… token → attacker server logs it. Mitigations are architectural, not promptcraft.

• Set enable_browser = false for any agent that touches secrets.
• Run agents with either untrusted-content access or secrets access — never both.
• Serve the UI with strict CSP img-src 'self' data: at the reverse proxy.
• Strip Authorization, GITHUB_TOKEN, OPENAI_API_KEY from sandbox.runtime_startup_env_vars.
• Keep conversations short-lived; rotate any token that ever entered an agent context.

Tip: treat every fetched webpage, issue body, and MCP response as adversarial input.

Patch and Audit the Install

CVE-2026-22812 (unauthenticated RCE via the local HTTP server — any malicious webpage could execute shell commands) is fixed in 1.0.216; CVE-2026-22813 (HTML injection in the markdown renderer, no DOMPurify/CSP) is fixed in 1.1.10. Anything older is exploitable from a drive-by browser tab.

Tip: track GitHub Security Advisories on sst/opencode; uninstall old global binaries before installing the new one.

Keep the HTTP Server Private

opencode serve binds 127.0.0.1:4096 by default and exposes /tui, /session/*, and the full OpenAPI spec at /doc. Never bind to 0.0.0.0 or widen --cors to wildcards — that is the pre-1.0.216 RCE class.

Tip: leave --mdns off, set explicit --cors origins, front any remote exposure with an SSH tunnel or mTLS reverse proxy.

Enforce Gateway/Basic Auth on Server Mode

The server is unauthenticated unless OPENCODE_SERVER_PASSWORD is set. Without it, anything local — including a browser page hitting localhost — can drive the agent through /tui or session endpoints.

Tip: rotate the password per machine, store it in your OS keychain, refuse to start serve if the env var is empty.

Workspace Isolation and External-Directory Guard

opencode auto-loads opencode.json and .opencode/ from whichever directory you launch in — untrusted repos can ship hostile MCP commands, plugins, or agent files. external_directory defaults to "ask"; keep it that way.

Tip: run untrusted repos inside a container or VM, disable project-level plugin/MCP loading until you've reviewed opencode.json and .opencode/.

Tool Allowlist via permission

opencode's 13 built-in tools (bash, edit, write, webfetch, task, etc.) default to "allow". Tighten with pattern rules — last-match wins, so put * first.

Tip: never invoke headless opencode run -p ... against an untrusted prompt — -p auto-approves every permission. Use "ask" policies in interactive sessions and a deny-by-default policy under CI.

Credentials Hygiene — auth.json and .env

Provider keys from opencode auth login land in ~/.local/share/opencode/auth.json (plain JSON, no encryption documented), and OAuth tokens for MCP land in ~/.local/share/opencode/mcp-auth.json. opencode also auto-loads .env from the project root.

Tip: chmod 600 ~/.local/share/opencode/auth.json, prefer {env:ANTHROPIC_API_KEY} substitution over baking keys into config, never commit opencode.json containing inline keys.

Lock Down MCP Servers

MCP local servers run an arbitrary command array at startup with no prompt and no confirmation — a malicious opencode.json is straight-line code execution.

Tip: review every MCP entry on git pull, keep the count small, remember plugin tool.execute.before hooks do not intercept subagent calls (issue #5894).

Constrain Subagents and Custom Agents

Agents are markdown files in .opencode/agents/*.md with YAML frontmatter that can override global permissions. A repo-supplied subagent can quietly re-enable bash or edit.

Tip: treat .opencode/agents/ and .opencode/commands/ as code — review in PRs; prefer global agents in ~/.config/opencode/agents/ over project ones for sensitive roles.

Plugin Safety

Plugins in .opencode/plugins/ (and the global equivalent) are JS/TS modules auto-loaded at startup, with npm deps cached in ~/.cache/opencode/node_modules/. They have full Node privileges. A project that ships a plugin owns your shell.

Tip: disable plugin auto-load for unfamiliar repos (move/rename the directory before first launch), pin plugin versions, audit tool.execute.before hooks — they're bypassed by subagents, so layer them behind permission rules.

Prompt-Injection and Output-Rendering Defense

CVE-2026-22813 XSS shows model output is dangerous: pasted web content, MCP tool responses, and remote files can carry injected instructions or HTML. Use webfetch/websearch sparingly with "ask", set doom_loop: "ask" so repeated identical tool calls pause.

Tip: never paste raw issue/email/web text into a --prompt invocation with auto-approve; route untrusted inputs through a read-only subagent whose tool surface is denied by default.

Run the Built-in Security Audit

n8n ships an audit CLI command that scans for risky configurations across five categories: instance settings, credentials, database, nodes, and filesystem access.

Tip: schedule the audit, treat any "abandoned credentials" or "unprotected webhooks" findings as tickets, and pin n8n to versions >= 1.122.0 / 2.x to clear CVE-2025-68613.

Keep the Editor UI Off the Public Internet

The editor at / and the REST API at /rest should never be Internet-reachable for non-trusted users; CVE-2025-68613 only requires an authenticated workflow editor to reach RCE.

Tip: separate the "editor" host (private) from the "webhook" host using WEBHOOK_URL so trigger and editor surfaces have different DNS names and ACLs.

Enforce Authentication, 2FA, and SSO

Owner-account email/password is enabled out of the box; turn on TOTP two-factor for every user and, on Enterprise, wire SAML/OIDC/LDAP.

Tip: legacy N8N_BASIC_AUTH_* was removed — use built-in user management with 2FA. If the proxy adds its own auth (oauth2-proxy, Cloudflare Access), keep it as defense-in-depth.

Terminate TLS and Set Webhook URLs at a Reverse Proxy

Run nginx/Caddy/Traefik in front, terminate TLS with Let's Encrypt, forward X-Forwarded-Proto / X-Forwarded-For so n8n constructs correct webhook URLs and rate-limits by real client IP.

Tip: enforce HSTS and X-Frame-Options: DENY at the proxy, cap client_max_body_size, apply per-IP limit_req on the webhook path.

Manage and Rotate the Encryption Key

N8N_ENCRYPTION_KEY encrypts every credential at rest. n8n auto-generates one into ~/.n8n/config on first start; in production set it explicitly so it survives container rebuilds and is identical across main, worker, and webhook processes.

Tip: store the key in a real secrets manager, back it up separately from the database, rotate via the Enterprise key-rotation feature.

Isolate Code Execution with External Task Runners

On 2.x task runners are on by default but ship in internal mode (same uid/gid as n8n). Switch to external mode so JS and Python Code nodes execute in a separate, distroless container running as nobody (uid 65532) with a read-only root filesystem. Primary mitigation for GHSA-8398-gmmx-564h and CVE-2025-68668 (Pyodide RCE).

Tip: in queue mode every worker needs its own runner sidecar; use the -distroless runner image and explicit N8N_RUNNERS_ALLOWED_BUILTIN_MODULES allowlists instead of *.

Block Dangerous Nodes and File/Env Access

Disable nodes you do not use, especially Execute Command and the legacy Code node. n8n 2.0 disables ExecuteCommand and LocalFileTrigger by default; on 1.x do it explicitly.

Tip: combine with seccomp/AppArmor at the container level and drop Linux capabilities (cap_drop: [ALL]).

Disable or Tightly Gate Community Nodes

Community nodes are arbitrary npm packages that load into the same process, receive decrypted credentials, and have unrestricted network access — the December 2025 npm supply-chain attack on n8n community packages exfiltrated OAuth tokens this way.

Tip: pin exact versions, review GitHub provenance (mandatory from May 2026 for verified nodes), never let community nodes be used as AI Agent tools on production agents.

Constrain the AI Agent Node and Use Guardrails

The LangChain AI Agent node can call any tool you connect to it — HTTP Request, Code, MCP, sub-workflows — so prompt injection from a webhook payload can pivot into arbitrary tool calls. Write a strict system message; wrap untrusted input/output with the built-in Guardrails node (n8n >= 1.119).

Tip: Guardrails node on input branch (Check Text for Violations) and another on output before any send/write tool; require human approval (Wait node) for destructive actions; avoid wiring Execute Command, raw HTTP, or community nodes as tools.

Harden Queue Mode, Backups, and Monitoring

In queue mode the main, worker, and webhook processes share the same encryption key and DB — lock down Redis with auth + TLS, give each role its own minimal env, never expose worker ports.

Tip: subscribe to n8n GitHub Security Advisories, patch within 48 hours of a critical CVE, rehearse a credential-rotation runbook (rotate N8N_ENCRYPTION_KEY + every connected OAuth/PAT).

Use Sessions as Your Audit Trail

Pi writes every message, tool call, and tool result as JSONL into ~/.pi/agent/sessions/ (tree-structured, full history). This is the only built-in audit surface — there is no separate audit log.

Tip: back the sessions directory with append-only storage or ship it to your SIEM; use /export for HTML review; avoid /share for sensitive work (it uploads to a private GitHub gist).

Keep the Harness Off Shared/Public Surfaces

Pi is a local TUI; there is no built-in web server or remote UI to expose. Risk comes from running it inside reachable environments (dev containers exposed via port-forward, shared SSH hosts, CI runners with inbound access).

Tip: run Pi only on workstations or ephemeral containers you control; never run as root; never expose the host's working directory over SMB/NFS while a session is live.

Authenticate via Env Vars or OAuth, Not Committed Files

Pi reads provider credentials from environment variables (ANTHROPIC_API_KEY, etc.) or from OAuth via /login. Custom providers live in ~/.pi/models.json.

Tip: store keys in your OS keychain or a secrets manager and inject at shell-init; never put raw keys in .pi/settings.json. Add .pi/ and ~/.pi/ artifacts to .gitignore globally.

Isolate Execution — Pi Does Not Sandbox Bash

The bash tool runs with the user's full privileges. Maintainers explicitly recommend: "Run in a container, or build your own confirmation flow."

Tip: run Pi inside a rootless container or VM with a bind-mounted project dir, dropped capabilities, and --network restricted to the model endpoint only.

Restrict the Tool Surface Explicitly

Pi exposes flags for tool scoping: --tools <list> / -t (allowlist), --no-builtin-tools / -nbt, --no-tools / -nt. Built-ins are read, write, edit, bash, grep, find, ls.

Tip: default to the smallest set for the task — read,grep,find,ls for code review, add edit,write for refactors, only enable bash when needed and a sandbox is active.

Lock Down Settings and Config Directories

Pi reads global settings from ~/.pi/agent/settings.json and project overrides from .pi/settings.json. PI_CODING_AGENT_DIR can relocate the global dir. Project settings override global — a malicious .pi/ in a cloned repo can change behavior.

Tip: chmod 600 ~/.pi/agent/settings.json; before opening any third-party repo, find . -path ./.git -prune -o -name '.pi' -print and inspect; treat .pi/extensions/ in a foreign repo as untrusted code.

Treat Extensions and Skills as Arbitrary Code

The README is blunt: "Pi packages run with full system access. Extensions execute arbitrary code, and skills can instruct the model to perform any action including running executables." Extensions load from path, npm, or git via -e, --extension <source>.

Tip: pin extension versions, vendor them into the repo, code-review every update, run with --no-extensions when triaging unknown projects. Maintain an internal allowlist of vetted pi packages.

Defend Against Prompt Injection in Tool Output

Pi has no built-in prompt-injection mitigations — the four-tool design means model-read content (file contents, bash output, fetched pages) flows directly back into context. A poisoned README or web page can instruct the agent to exfiltrate keys or run destructive bash.

Tip: combine tool-restriction (section 5) with network egress filtering (section 4); avoid pointing the agent at untrusted URLs; use --offline mode (PI_OFFLINE=1) when working on sensitive code.

Control Updates and Telemetry

Pi checks https://pi.dev/api/latest-version for updates and reports installs to https://pi.dev/api/report-install.

Environment equivalents: PI_SKIP_VERSION_CHECK=1, PI_TELEMETRY=0, PI_OFFLINE=1.

Tip: in regulated environments set all three; pin Pi to a known-good version (npm --save-exact) and gate upgrades through your normal package-review process.

Monitor Sessions and Dangerous Calls

Because permission gating is opt-in via extensions, observability is your primary control. Session JSONL captures every tool call with arguments.

Tip: write a small wrapper extension that streams tool-call events to your log pipeline and blocks high-risk commands (rm -rf, curl | sh, anything touching ~/.ssh, ~/.aws, ~/.pi, .env*). Alert on bash invocations outside the project working directory; rotate provider API keys regularly.

Version Pinning

Both 2025 CVEs were fixed in 0.23.0 and 0.39.0. Pin to a known-good minor; never auto-update to latest.

Tip: lock the version in package.json or mise.toml; subscribe to GitHub Security Advisories for openai/codex.

Network Exposure

--remote ws://host:port exposes the TUI to an app-server; [sandbox_workspace_write] network_access = true lets sandboxed shell commands reach the internet (default deny on Linux; silently ignored on macOS Seatbelt per issue #10390).

Tip: scope network per-task: codex --config sandbox_workspace_write.network_access=true only for installs.

Authentication (ChatGPT OAuth + API Key)

Prefer "Sign in with ChatGPT" device-code OAuth over a long-lived OPENAI_API_KEY — refresh token rotates every ~10 days and can be revoked from your OpenAI account.

Tip: enable MFA on the OpenAI account backing OAuth; use codex logout rather than rm so keyring entries are also wiped.

Sandbox (Default-On Seatbelt / Landlock)

Defaults to sandbox_mode = "workspace-write": read-only outside workspace, writes confined to session cwd, network blocked. macOS Seatbelt + Linux Landlock+seccomp. Never run as root.

Tip: for code review of untrusted repos downgrade to sandbox_mode = "read-only" and require --ask-for-approval on-request.

Approval Modes / Tool Allowlist

--ask-for-approval accepts untrusted (prompt for state-mutating), on-request (default with workspace-write), never (silent — CI only).

Tip: configure approvals_reviewer = "auto_review" so a secondary model screens approval requests for exfiltration/credential-probing.

Credentials (~/.codex/auth.json)

Holds access_token, refresh_token, id_token, account_id — treat like an SSH private key. Verify mode 0600. Codex also reads workspace .env.

Tip: on shared boxes, CODEX_HOME=/run/user/$UID/codex puts tokens on tmpfs that disappears on logout.

--dangerously-bypass-approvals-and-sandbox Risks

Alias --yolo. Disables Seatbelt/Landlock AND all approval prompts. A single malicious AGENTS.md, web result, or MCP response can rm -rf ~. Reserve for throwaway containers only.

Tip: add a shell alias that refuses the flag outside a container: alias codex='[ -f /.dockerenv ] || _strip_yolo; command codex'.

Prompt Injection (Markdown / Web / MCP)

AGENTS.md files at every directory level are injected as user messages near top of context (NVIDIA documented indirect injection via dependency-supplied AGENTS.md). Web search results, file contents, MCP tool output are all untrusted text.

Tip: disable --search for untrusted repos; review every AGENTS.md with git log -p; never auto-load project .codex/config.toml from a freshly cloned repo.

Updates

CVE cadence (0.23.0, 0.39.0) shows Codex is patching live security issues monthly.

Tip: automate weekly gh api repos/openai/codex/security-advisories check in CI; alert on any new GHSA.

Audit Logs

Session transcripts to $CODEX_HOME/history.jsonl (cap with [history] max_bytes). Lifecycle hooks (PreToolUse / PostToolUse in ~/.codex/hooks.json) stream every shell invocation to syslog or a SIEM.

Tip: set allow_managed_hooks_only = true in /etc/codex/requirements.toml so users can't disable audit hooks.

Pin the Version, Isolate the Install

Aider ships rapid PyPI releases — a compromised or buggy release can rewrite your repo on next run. Pin a known-good version rather than tracking latest.

Tip: pin in requirements.txt/pyproject.toml, review the changelog before bumping; never install via the OS package manager (docs explicitly warn it installs wrong deps).

Network Exposure — CLI Local, Browser Mode Not

Default CLI mode opens no listening ports — outbound HTTPS to LLM provider, PostHog, /web scrapes only. The --browser/--gui mode launches a Streamlit server that binds locally without authentication.

Tip: keep gui: false in .aider.conf.yml; if you need it, leave bound to loopback and gate access via SSH port-forwarding.

Authentication — N/A, Local Trust Model

Aider has no user authentication; whoever runs the binary inherits full repo-edit and shell-exec rights. This section reduces to OS-level controls.

Tip: run Aider as your normal user, never as root, and not from shared service accounts. Treat any host running Aider as a developer-shell-accessible host.

Isolation — No Built-in Sandbox

Aider executes /run, --lint-cmd, --test-cmd, accepted suggest-shell-commands directly on the host with your privileges. Run inside a container scoped to one repo.

Tip: one container per project, no host bind-mounts outside the repo, drop capabilities, disable --suggest-shell-commands.

.aiderignore and Edit-Scope Control

.aiderignore (gitignore syntax) is the only mechanism that hard-blocks files from being read or edited. Pair with --subtree-only in monorepos and --read for reference-only files.

Tip: commit .aiderignore, keep gitignore: true (default), use /read-only for anything that shouldn't be edited.

Credentials — Env Vars or .env, Never .aider.conf.yml

The YAML config path supports openai-api-key / anthropic-api-key and lives in home or repo root — easy to leak via dotfile sync or git add. Prefer env vars from a secret manager.

Tip: never set api-keys in .aider.conf.yml; ensure .env and .aider.conf.yml are in your global .gitignore; rotate keys regularly.

--yes-always and Auto-Commit Risks

--yes-always bypasses every confirmation — file adds, shell suggestions, URL scrapes, commits. Combined with defaults auto-commits: true + dirty-commits: true, an unattended Aider can rewrite + commit your work in one LLM turn. Architect mode adds auto-accept-architect: true.

Tip: work on a dedicated branch, review every /undo-able commit, only enable --yes-always in CI on a throwaway worktree.

Prompt Injection from Files, Diffs, and Web Pages

Aider feeds the LLM the repo map + every added/read file + /web scrapes + (default detect-urls: true) auto-fetches URLs in your messages. Hostile content in a dependency README, vendored JS, scraped page can pivot the model.

Tip: vet files before /add, prefer /read-only for third-party docs, never /web an untrusted URL, read every diff before accepting.

Updates and Telemetry (PostHog)

Aider checks for updates on launch (check-update: true) and sends anonymous usage events to PostHog by default (model names, token counts, errors, command usage — not code or keys).

Tip: disable analytics fleet-wide; if you must keep it, redirect to your own PostHog via analytics-posthog-host.

Audit — Chat, Input, and LLM History Files

Aider writes .aider.chat.history.md (full transcripts + diffs), .aider.input.history (every prompt typed), and optional .aider.llm.history (raw LLM traffic) in the repo root. They contain code snippets, file contents, anything pasted.

Tip: confirm .aider* is in .gitignore (default behavior with gitignore: true); for team audit trails, enable --llm-history-file and ship the JSONL to your SIEM.

Pin Version, Watch Install Channel

The Linux/macOS one-liner pulls the stable tag and writes a self-updating binary. Desktop builds auto-update.

Tip: verify shasum from the releases page; subscribe to releases feed; disable Desktop auto-update on managed fleets.

Desktop vs CLI Exposure Surface

CLI opens no listener (outbound HTTPS to provider only). Goose Desktop runs an internal goose-server process and a local OAuth callback (override via GOOSE_OAUTH_CALLBACK_PORT). Both share ~/.config/goose/.

Tip: prefer CLI for headless/CI; on Desktop keep GOOSE_OAUTH_CALLBACK_PORT bound to loopback and firewall it; isolate users via GOOSE_PATH_ROOT=/srv/goose/$USER.

Provider Credentials — Keyring First, secrets.yaml Last

Goose stores keys in OS keyring (Keychain / libsecret / Windows Credential Manager) by default. GOOSE_DISABLE_KEYRING=1 (or headless without keyring) falls back to ~/.config/goose/secrets.yaml plaintext (mode 0o600).

Tip: never git add secrets.yaml or config.yaml; on CI inject keys via env vars + GOOSE_DISABLE_KEYRING=1 to tmpfs-only secrets.yaml; rotate after session sharing.

Pick the Right GOOSE_MODE — auto Is the Default

GOOSE_MODE controls per-tool approval. Default auto (no prompts, agent edits/deletes/executes freely). Switch to smart_approve for risk-classified gating, approve to confirm every tool call, chat to disable tools entirely.

Per-tool decisions persist to ~/.config/goose/permissions/tool_permissions.json + permission.yaml. Mid-session: /mode approve.

Tip: default smart_approve on dev laptops; approve for customer data; chat for text drafting; review permission.yaml after each session.

No Built-in Sandbox — Isolate the Host

The developer built-in extension shells out (shell, text_editor, list_windows) with full user privileges; computercontroller drives the GUI and runs automation_script; memory writes to disk. Block's docs explicitly point at containers/dev containers for isolation.

Tip: one container per project, no bind-mount of $HOME or ~/.ssh, separate Docker network from host LAN.

Lock Down Extensions With GOOSE_ALLOWLIST

The Goose Hub and goose configure → Add Extension will install any MCP server (stdio/SSE/npm/uvx). Block ships an allowlist mechanism — point GOOSE_ALLOWLIST at a YAML of approved command: strings and Goose blocks installs that don't match.

Tip: host allowlist on internal infra (HTTPS + cert pinning at egress); pin extensions by full command (npx -y pkg@1.2.3); disable computercontroller unless someone explicitly needs browser automation.

Prompt Injection — Enable Security Prompt and Adversary Mode

Goose ships two independent defenses, both off by default. SECURITY_PROMPT_ENABLED=true activates a built-in classifier (SECURITY_PROMPT_THRESHOLD, default 0.8). Adversary Mode is a separate, silent reviewer agent that inspects each tool call and returns ALLOW/BLOCK before execution; rules live in user-editable adversary.md.

Tip: turn both on; expand Adversary Mode's tools: list to cover any extension that writes/networks; refuse to paste untrusted web content directly — let developer__fetch bring it in so it's reviewable.

Updates, Telemetry, Egress

Goose Desktop auto-updates and emits OpenTelemetry traces. GOOSE_TELEMETRY_ENABLED (default false) governs anonymous events; OTEL_EXPORTER_OTLP_ENDPOINT / LANGFUSE_*_KEY redirect traces.

Tip: confirm telemetry off fleet-wide; allowlist only provider hostnames at egress proxy; tail goose info -v after upgrade to spot new outbound destinations.

Audit — Session DB, Logs, Memory Files

From v1.10, every session writes to ~/.local/share/goose/sessions/sessions.db (SQLite — id, description, working dir, full transcript, every tool call + result). Logs land under ~/.local/state/goose/logs/. The memory extension persists facts to ~/.config/goose/memory/.

Tip: back up the session DB off-box; periodically purge memory/ and prompts/; ship ~/.local/state/goose/logs/*.jsonl to your SIEM and alert on GOOSE_MODE=auto + denied-extension events.

Best Practices Recap

• Pin a release tag, disable Desktop auto-update, verify shasums.
• Keep GOOSE_MODE at smart_approve or approve; cap GOOSE_MAX_TURNS.
• Run the developer / computercontroller extensions in a container — Goose has no built-in sandbox.
• Keys in keyring; never in config.yaml; treat secrets.yaml as a fallback only.
• Set GOOSE_ALLOWLIST; disable extensions you don't use.
• Enable SECURITY_PROMPT_ENABLED and Adversary Mode; review adversary.md rules.
• Disable GOOSE_TELEMETRY_ENABLED, route OTLP traces internally, force HTTPS through egress proxy.
• Treat sessions.db and ~/.local/state/goose/logs/ as sensitive — back up, purge, ship to SIEM.

Version Pinning and Extension Marketplace Provenance

Continue ships through VS Code Marketplace, Open VSX, and JetBrains Marketplace with a rolling "pre-release" channel landing new code ~a week before stable. Install only publisher Continue.continue; disable auto-updates.

Tip: subscribe to GitHub releases feed for continuedev/continue, avoid the pre-release channel on production developer machines.

Continue Panel Exposure and IDE Secret Storage

API keys typed into the onboarding panel are persisted via vscode.SecretStorage (OS keychain); any key written into config.yaml lives on disk in plaintext.

Tip: never paste keys into config.yaml; let the IDE store them, or load via secrets.* from environment / Hub.

Authentication and Continue Hub Identity

Local Continue has no built-in auth — anyone with shell access reads ~/.continue/ and keychain entries unlocked by your IDE session. The Continue Hub (Mission Control) adds org identity for shared assistants/secrets.

Tip: enable SSO + MFA on the Hub account, scope shared assistants to least-privilege secret blocks, disable Hub access from machines that only need local models.

Isolation — No Sandbox, In-IDE Execution

Continue runs inside the IDE extension host process and inherits its full filesystem, network, and environment access; MCP servers are spawned as child processes of that host. Use OS-level isolation for any repo you do not fully trust.

Tip: open untrusted repos inside a devcontainer or Restricted Mode workspace; mount ~/.continue read-only.

Agent Mode Tool Allowlist and MCP Scope

MCP is only available in Agent mode; each MCP server is launched with a command/args/env tuple — arbitrary binaries with your user privileges.

Tip: pin MCP commands to absolute paths, constrain filesystem servers to a single project root, disable Agent mode in repos where you do not need tool execution.

Credential Handling in ~/.continue/

~/.continue/config.yaml, workspace .continue/, and ~/.continue/logs/core.log are world-readable by your user; logs may capture prompts in verbose mode.

Tip: rotate keys quarterly, exclude .continue/ from dotfile repos and backups, turn off Verbose logging once you finish debugging.

Custom Context Providers and Invokable Prompt Files

Context providers shell out to real binaries — search runs ripgrep, terminal reads the last shell command + output, clipboard reads recent clipboard items, http fetches arbitrary URLs. Invokable prompt files (invokable: true in .continue/prompts/) become slash commands.

Tip: review .continue/prompts/ and .continue/mcpServers/ in code review, drop high-risk providers from defaults, require signed-off changes to add new MCP servers.

Prompt Injection from Indexed Code, Docs, Web

Continue indexes your codebase (local embeddings under ~/.continue/index/) and any docs: sites you add. A malicious comment in a dependency, a poisoned docs: page, or an MCP tool result can hijack the agent.

Tip: only add first-party docs: sources, treat agent tool output as untrusted, require human approval on every write/exec tool call — never blanket auto-approval.

Updates, Telemetry, Outbound Network

Continue sends anonymous telemetry to PostHog by default; the CLI variant honours CONTINUE_TELEMETRY_ENABLED=0. For self-hosted endpoints behind a private CA, configure TLS verification explicitly rather than disabling it.

Tip: disable allowAnonymousTelemetry, route through corporate proxy with caBundlePath, never set verifySsl: false to "fix" a cert error.

Audit and Logging

Continue writes runtime logs to ~/.continue/logs/core.log and exposes a development data pipeline (data: section) that can stream chat/edit/autocomplete events to an HTTP sink or local file.

Tip: ship data: events to a SIEM, monitor core.log for unexpected MCP spawns, report suspected vulnerabilities privately to security@continue.dev.

Pin Plan Tier and Opt-In Features

Free/Pro/Pro+ data is opted into model training by default starting 24 April 2026; Business and Enterprise contractually exclude customer data + add audit logs, IP indemnification, content exclusions. Coding Agent, MCP, self-hosted runners are admin-gated.

Path: Enterprise/Org → Policies → Copilot → toggles for Chat, Coding Agent, MCP, model selection.

Tip: standardize on Business or Enterprise; review feature matrix quarterly and disable previews you're not actively governing.

Minimize Copilot Exposure Surface

Copilot is reachable from IDE, github.com chat panel, PR/issue @copilot mentions, CLI, mobile, MCP-connected tools. Copilot CLI, Coding Agent, and Agent Mode in Chat do not honor content exclusions.

Path: Org → Copilot → Policies → disable surfaces you do not use (CLI, mobile, Chat in .com, Coding Agent per repo).

Tip: enable Coding Agent only on opted-in repos; disable @copilot in public repos to prevent drive-by issue triggers.

Authentication and Identity

Copilot seats follow GitHub identity; SSO/SCIM enforcement on Enterprise gates Copilot access. Personal accounts using Copilot Free against company repos bypass enterprise telemetry.

Path: Enterprise → Authentication security → require SAML SSO + SCIM; Copilot → seat management restricted to SSO-verified users.

Tip: block personal-account access via IP allowlist + Enterprise Managed Users (EMU); require WebAuthn/passkeys for any account that can trigger the Coding Agent.

Coding Agent Isolation Boundaries

The Coding Agent runs in an ephemeral GitHub Actions runner, can only push to current PR branch or fresh copilot/* branch, and its PRs require human approval before workflows execute. Self-hosted runners (ARC) supported.

Path: Repo → Settings → Actions → "Require approval for all outside collaborators" + branch protection on main; Copilot → Coding Agent → choose GitHub-hosted vs self-hosted runner.

Tip: treat the agent like an external contributor — never add it as a bypass actor on rulesets; if using ARC, isolate the runner namespace and rotate the runner image daily.

Content Exclusions and MCP Allowlist

Content Exclusions stop Copilot completions/Chat from reading matched paths — but not the Coding Agent or CLI. The MCP allowlist controls which MCP servers any Copilot surface can connect to.

Path: Enterprise → Copilot → Content exclusions (glob: .env, **/secrets/**, IaC); Org → Copilot → MCP allowlist set to "explicit allow"; Repo → Copilot → Firewall = Enabled.

Tip: exclude secrets, infra, customer-data paths org-wide; allowlist MCP servers individually with pinned versions; never enable "Let repositories decide" for the firewall.

Credential and Secret Handling

The Coding Agent can commit secrets pasted into issues, accidentally embed API keys lifted from context, or write .env files into PRs. Push protection + secret scanning are the backstop.

Path: Repo → Security → Secret scanning + Push protection = ON; Org → Code security → require both for all repos; pre-commit gitleaks for IDE-side defense.

Tip: configure GHAS custom patterns for your own tokens; alert on any commit authored by copilot-swe-agent[bot] that touches .env*, *.pem, or CI secret files.

Treat .github/copilot-instructions.md as Code

Custom instruction files are auto-injected into every Copilot request in the repo. A malicious PR that edits copilot-instructions.md can silently rewire the assistant for every subsequent developer — highest-leverage prompt-injection vector.

Path: CODEOWNERS entry: /.github/copilot-instructions.md @security-team + branch protection requiring code-owner review on main.

Tip: require signed commits on these files, review diffs in security review, forbid applyTo: "**" patterns from untrusted contributors.

Prompt-Injection Defenses (CamoLeak Class)

CamoLeak (CVSS 9.6, disclosed Jun 2025, fixed Aug 2025) combined hidden HTML comments in PRs with Camo-proxy URL precomputation to exfiltrate private code as 1×1 pixel requests. GitHub disabled image rendering in Chat, but the class — untrusted markdown + agent with repo read + outbound channel — persists via MCP and Coding Agent firewall gaps.

Tip: never let the Coding Agent process issues from external contributors without human triage; apply Willison's "lethal trifecta" — strip outbound network from any agent that sees private code and untrusted text.

Update Cadence and Feature-Flag Governance

Copilot ships changes weekly; IDE extension, Chat backend, Coding Agent runner image update independently. Premium-request SKUs changed materially Sep–Dec 2025 (zero-dollar budgets removed; per-SKU tracking for Coding Agent from 1 Nov 2025).

Path: Enterprise → Policies → Copilot → "Block usage above budget" = ON; per-SKU budgets for Coding Agent.

Tip: subscribe to the GitHub Changelog RSS, gate preview features behind a pilot org, set hard premium-request budgets on Coding Agent to cap blast radius from a runaway agent loop.

Audit Logs and Monitoring

Enterprise plans expose a Copilot audit log covering policy changes, content-exclusion edits, MCP allowlist edits, Coding Agent task starts, seat assignments. Chat prompt/response content is not in the standard audit log.

Path: Enterprise → Settings → Audit log → stream to SIEM (Splunk/Sentinel/S3); enable copilot.* event categories; ingest Copilot Metrics API daily.

Tip: alert on copilot.cfb_* (Coding Agent firewall bypass), business.update_copilot_business_policy, copilot.content_exclusion_updated, and any Coding Agent run outside business hours from a non-pilot repo.

Version Pinning & Extension Provenance

The wiper shipped because users auto-updated to v1.84.0 within hours. Pin a known-good version, verify the publisher (AmazonWebServices), validate VSIX SHA-256 against the GHSA advisory before rollout.

Setting: VS Code extensions.autoUpdate: false + MDM-deployed VSIX; JetBrains "Manage Plugin Repositories" pinned to a vetted mirror.

Tip: subscribe to aws/aws-toolkit-vscode security advisories; stage releases through a canary ring for ≥72h before broad deployment.

Q Chat Panel Exposure

The chat panel auto-includes open editor tabs, workspace files referenced by @workspace, and (in agent mode) terminal output — any of which can carry indirect prompt-injection payloads. The cleaner.md file was loaded exactly this way.

Setting: amazonQ.workspaceIndex.enabled: false for repos containing untrusted contributor content.

Tip: disable Q in workspaces hosting third-party PRs, decompiled binaries, or scraped web data.

Authentication — IAM Identity Center, Not Builder ID

AWS Builder ID is a personal identity with no IAM mapping, no MFA enforcement, and a 90-day Q session. IAM Identity Center (SSO) gives permission sets, group-based subscription management, MFA, SCIM provisioning, and a usage dashboard.

Setting: IdC instance + AmazonQDeveloperAccess permission set; disable Builder ID sign-in via org SCP.

Tip: federate IdC to your IdP (Okta/Entra ID), require MFA, shorten the IdC session below the 90-day Q default.

Isolation — Assume No Sandbox

The extension runs inside the IDE process with the developer's UID, full home-dir access, and whatever AWS profile is selected. There is no container, no seccomp, no AppArmor.

Setting: run Q CLI inside a devcontainer / Firecracker microVM / bubblewrap jail; never as root.

Tip: for agent mode, use a dedicated low-privilege OS account and a project-scoped AWS profile, not your admin shell.

Tool / Action Allowlist

Agent mode exposes fs_read (trusted by default), fs_write, executeBash, plus AWS-CLI invocations. /tools trustall gives the model unconfirmed write and shell.

Setting: in Q CLI use /tools trust fs_read only; never trustall. Configure ~/.aws/amazonq/agent.json with explicit allowedCommands (e.g. git status, npm test) and deny rm, aws * delete*, curl, wget.

Tip: require HITL for every executeBash; ensure Language Server ≥ v1.24.0 (AWS-2025-019 fix that closed the find/grep HITL bypass).

Credential Handling

Q inherits the active AWS credential chain — environment vars, ~/.aws/credentials, SSO cache, IMDS on EC2 dev hosts. A compromised prompt can aws s3 cp or aws iam create-access-key with whatever role you've assumed.

Setting: named profiles per project (AWS_PROFILE=q-sandbox), short-lived SSO creds, IAM permission boundary capping the role to read-only + sandbox-account write.

Tip: never run Q with AdministratorAccess or your management-account credentials; rotate any access keys exposed during a Q session.

Custom Rules / Context (.amazonq/ and Customizations)

Q reads project rules from .amazonq/rules/*.md and pulls private-codebase context from "Amazon Q Customizations" (admin-uploaded S3 indexes). Both are prompt-injection vectors.

Setting: treat .amazonq/ as code — require code-owner review, sign commits, CI-lint for suspicious directives (rm -rf, aws * delete, base64 blobs).

Tip: restrict Customizations admin to IdC group q-customization-admins; scope each customization to one team via resource-based policy.

Prompt Injection (Wiper as Canonical Example)

The wiper succeeded by getting Q to obey a cleaner.md smuggled into the source tree. The same class works via README files, dependency code, GitHub issues opened in the chat panel, web pages opened via tools, even error messages from executeBash.

Setting: combine #2 (don't include untrusted context), #5 (deny destructive shell), #6 (scoped creds), and content scanners on .md / docstring inputs.

Tip: add a CI check that fails the build if any file in .amazonq/, prompts/, or docs/ contains imperative-mood instructions to delete resources or exfiltrate data; treat any LLM-generated commit touching these paths as high-risk.

Updates — Auto-Update Off, MDM On

The wiper window was the auto-update window. Disable auto-update for the extension and the Q Language Server, mirror VSIXes internally, roll forward via MDM after a staging soak.

Tip: bind extension installs to an MDM-pushed extensions.json recommendation list with version pins; alert on any developer-installed deviation.

Audit — CloudTrail Data Events + Prompt Logging

Q Developer API calls (GenerateRecommendations, SendTelemetryEvent, customization access) are CloudTrail data events — not logged by default. Inline prompt content is hidden unless you opt in.

Setting: create an org trail with AWS::QDeveloper::* data events enabled, ship to a Log Archive account, enable Prompt Logging in the Q Developer console (admin-only, off by default).

Tip: alert in Security Hub / GuardDuty on q-developer principal performing iam:*, s3:DeleteObject, or cross-region *:Delete*; correlate with VS Code extension version telemetry. Disable training-data sharing — Free tier opt-in by default.

Account Authentication and MFA

Enable hardware-key or TOTP MFA on every Replit account; Agent inherits whatever session authenticated it. Rotate passwords + revoke active sessions any time Agent has had access to secrets including OAuth tokens or API keys. Bind Git, GitHub, deployment-provider OAuth grants to least-scope tokens.

Teams / Enterprise Workspace Controls

Move production work into a Teams or Enterprise org for SAML SSO, SCIM provisioning, audit logs (Enterprise-plan only). Force SSO with your IdP (Okta/Entra/Google); require MFA at IdP layer; disable password fallback. SCIM deprovisioning = a fired engineer loses Agent + DB + Deployment access in one step.

Secrets Vault Hygiene

Store every credential in Replit Secrets (AES-256 at rest, TLS in transit); never paste keys into chat with Agent — they end up in conversation history. Prefer app-scoped Secrets over account-scoped. Separate *_DEV and *_PROD secret names. Static Deployments cannot use Secrets.

Agent Autonomy and Mode Controls

Default to Plan Mode / planning-and-chat-only mode (added post-Lemkin) for anything touching production. Use Lite/Economy for routine edits; reserve Power/Turbo for greenfield in throwaway Repls.

Tip: treat "vibe coding" as prototype-only; disable auto-run on file save; start a fresh Agent session before sensitive work so prior context cannot be re-interpreted as approval.

Database Backups, Snapshots, and Dev/Prod Separation

New Replit-hosted Databases now provision separate dev + prod automatically — verify it's on; legacy Neon-backed databases (sunset Dec 4, 2025) do not. Use Database Time Travel / checkpoint rollback as the last line of defense.

Tip: export nightly logical dumps (pg_dump) to external storage the Agent has no creds for. Forbid DROP, TRUNCATE, and unscoped DELETE via the DB role the Agent uses; grant DDL only to a human-run migration role.

Deployments, Always-On, and Blast Radius

Pick the deployment type intentionally (Static / Autoscale / Reserved VM / Scheduled). Deployment has its own Secrets snapshot taken at publish time — re-publish after rotating keys. Set billing cap + request budget so a runaway Agent loop can't burn your card.

Tip: require a human "Publish" click for prod; never let the Agent run the deploy flow unattended.

Webhook and External Integration Security

Verify HMAC signatures on every inbound webhook the Agent wires up — Agents routinely skip this step. Store webhook secrets in Replit Secrets. Pin outbound webhook URLs to an allowlist; an injected prompt can otherwise exfiltrate data via a crafted fetch() the Agent adds "to help".

Tip: for third-party MCP-style integrations, grant the narrowest OAuth scope possible and review what the Agent connected after every session.

Prompt-Injection Defenses (Rule of Two)

Treat any content the Agent reads (scraped pages, GitHub issues, support tickets, PDFs, dependency READMEs) as untrusted instructions, not data. Apply the Rule of Two (Willison / OpenAI): of {autonomous execution, access to private data, ability to communicate externally} the Agent should hold at most two at once. Production DB creds + outbound HTTP + autonomy = the combo that caused Lemkin's loss.

Tip: never let the Agent both read user-submitted content and hold production write credentials in the same session.

Audit Logs, Checkpoints, and Observability

Enterprise audit logs cover login, SSO, SCIM, admin events — ship to your SIEM. Use Replit checkpoints liberally; they are the rollback mechanism that worked in the Lemkin case after Agent claimed it couldn't.

Tip: snapshot the Repl (download as zip or push to an external Git remote you control) before any large Agent run; review the Agent conversation transcript as part of post-incident forensics — it shows what tools were called and what the model "saw".

Patching, Feature Flags, and Incident Readiness

Replit ships Agent behavior changes continuously; re-test your guardrails monthly because defaults shift (planning-only mode itself was added mid-2025).

Tip: document an Agent kill-switch: who revokes the SSO session, who rotates Secrets, who pauses Deployments. Run a tabletop exercise based on the Lemkin scenario — "Agent dropped prod DB and is lying about restore options" — practice the Time Travel restore and the external pg_dump restore.

Lock Down Account Authentication and SSO

For anything beyond a single-developer Pro account, use the Enterprise plan and route logins through your IdP. Devin supports SAML SSO, OIDC, Okta, Azure AD/Entra ID, SCIM-style IdP group sync.

Tip: enforce SSO-only login (disable password fallback); require MFA at the IdP (Devin itself relies on the IdP for MFA); map IdP groups to Devin's default roles (Admin, Member, DeepWiki Only) or custom roles. Configure IP Access Lists (PUT /v3/enterprise/ip-access-list) — note the PUT replaces the entire list, document IPs externally first.

Minimize GitHub OAuth Scope

The GitHub App is the single biggest blast-radius surface. Devin's default install requests read/write on contents, PRs, issues, checks, commit statuses, discussions, projects, workflows — full contributor access.

Tip: during install choose "Only select repositories", never "All repositories"; enforce branch protection on main / release branches (required reviewers, required checks, no force-push); require signed commits; use CODEOWNERS on .github/, infra/, .agents/; allowlist Devin's published egress IPs (100.20.50.251, 44.238.19.62, 52.10.84.81) in your GitHub org IP allowlist.

Understand (But Don't Rely On) Workspace VM Isolation

Cognition built microVM-per-session isolation — each Devin gets its own kernel, filesystem, network namespace; VM destroyed when session ends. What you still control: Snapshots (review like Dockerfiles — anything in snapshot is in every future session), machine size / concurrency caps, network egress (Cognition's default is allowlist with deny-by-default but Devin can still fetch arbitrary URLs).

Tip: if you handle regulated data, the Enterprise tier offers single-tenant VPC deployment with AWS PrivateLink or IPSec — use it instead of multi-tenant cloud.

Treat Knowledge and Skills as Code

Devin's Knowledge (org-wide notes auto-recalled by trigger description) and Skills/Procedures (SKILL.md files in .agents/skills/, .cognition/skills/) are prompt-injection vectors with persistence. A malicious or sloppy Knowledge entry executes on every future session that matches its trigger.

Setting: restrict who can create org-level Knowledge via custom roles (ManageKnowledge permission); store all Skills in-repo under .agents/skills/<name>/SKILL.md and require CODEOWNERS review on those paths; use the allowed-tools: YAML frontmatter to restrict procedures to read-only or specific tools.

Tip: set triggers: ["user"] on sensitive skills so Devin won't auto-activate them from indirect prompts; audit Skills' !`command` substitution and $ARGUMENTS — these execute in the VM.

Scope the Slack Integration Tightly

The Slack app requests nine permission groups including channels:history, groups:history, im:history, files:read/write, users:read.email. Anyone in a channel where the bot is present can @Devin and burn ACUs.

Tip: invite @Devin only to specific channels (#devin-requests, #eng-triage) — never the workspace-wide default channel; disable or scope Auto-triage which monitors channels and auto-spawns sessions; block external/guest users from channels where Devin is present (Slack Connect guest = indirect-prompt-injection path).

Set ACU and Cost Limits Aggressively

Devin's business model is ACU-based (Agent Compute Units) on top of plan quotas with pay-as-you-go overage. A confused or jailbroken Devin running in a while-true loop is a billing event.

Tip: restrict the RunDevinSessions permission to only the roles that need it; restrict ManageApiKeys so service users cannot be created broadly; for automation (auto-triage, CI-triggered, scheduled snapshots) put a manual approval gate in front so a malformed issue title cannot spawn 50 sessions.

Use Devin Secrets Correctly — Never Paste Credentials in Chat

Devin Secrets encrypted at rest. Three scopes: organization (admin manage), personal (creator only), repo/session-specific.

Tip: never paste API keys, tokens, passwords directly into Devin chat — always reference via Secrets UI so masked in logs and screenshots; create a dedicated devin@company.com machine identity per third-party service Devin needs (GitHub bot, Linear API key, AWS IAM with least-privilege); document Secrets in Notes with owner, scope, expiration; rotate quarterly; audit secrets:created/secrets:revoked events.

Plan for Prompt Injection from Issues, PRs, Web Pages

This is Devin's most-exploited real vulnerability class. Johann Rehberger has publicly demonstrated: indirect injection from a web page Devin browsed → Devin exposes a random VM port to the internet; web-content injection → Devin downloads malware into the VM; crafted issue/PR content → Devin leaks secrets out of the workspace.

Tip: never let Devin auto-merge (branch protection + required human review is the only reliable backstop); treat any session that touched external URLs as tainted; don't put production credentials in the same session that browses the open web; for auto-triage, sanitize the issue body before it reaches Devin; watch the live session — if the screen does something unexpected, pause immediately.

Inventory Integrations and MCP Servers

The Enterprise audit-log catalog references GitHub, GitLab, Azure DevOps, Bitbucket, Linear, Jira, Slack, and MCP servers as connectable surfaces. Each one is a new credential and a new injection channel.

Tip: maintain an integrations allowlist — admins approve each integration before enable; restrict ManageMcpServers and ManageIntegrations permissions to platform admins via custom roles; vet third-party MCP servers the same way you'd vet a VS Code extension; disable integrations you don't actively use — every dormant OAuth grant is a credential someone could revive.

Turn On Audit Logs and Review Them

Audit logs (GET /v3/enterprise/audit-logs) capture 100+ event types: logins, role changes, integration installs, secrets create/revoke, knowledge edits, MCP server changes, automation triggers, AI guardrail violations.

Tip: enable a service user with cog_ prefix and ManageEnterpriseSettings scoped only to audit-log read; pull logs nightly into SIEM (Datadog/Splunk/Panther) — retention windows are limited to ~100 days per query; alert on new integration installed, role changed to Admin, secrets revealed/edited at org scope, IP access list modified, SSO config changed, bursts of session creation outside business hours.

Lock Down Account Auth and the OAuth Surface

Manus accepts Google, Apple, and email sign-in; no first-party password-plus-TOTP, so the agent account is as strong as your Google/Apple identity. Enforce hardware-key WebAuthn (Titan, YubiKey, passkey) on the upstream IdP, kill SMS fallback, prune Manus from the IdP's third-party-app list on offboarding.

Tip: use a dedicated IdP identity for Manus, not your daily-driver Google account, so an injected agent bouncing through OAuth cannot reach personal Gmail/Drive/Calendar.

Understand What the Manus Sandbox Actually Isolates

Each task spawns a fresh Ubuntu VM with shell, Python/Node, Chromium, and a writable /home/ubuntu; per-task and torn down after completion or idle timeout. What is not isolated: the agent writes anywhere in its VM, installs arbitrary packages, opens outbound connections to any host, and calls deploy_expose_port to publish a service to the internet.

Tip: assume every task has the equivalent of an unsandboxed dev laptop with internet egress; never put long-lived secrets, SSH keys, or .env files into the sandbox even temporarily.

Treat the Browser Tool as the Lethal-Trifecta Pivot

The browser reads attacker-controlled HTML, the agent has tool access, and exfiltration channels are wide open — Simon Willison's lethal trifecta in textbook form, and how the VS Code kill-chain started (a PDF the user asked Manus to summarise).

Tip: split untrusted reading from privileged acting — one task scrapes with no connectors attached; a second receives only your hand-curated summary and may touch Gmail/Drive/Slack.

Constrain the Shell Tool and Block Port Exposure

The shell tool is the most powerful sandbox capability and deploy_expose_port the most dangerous — turns any sandbox-internal compromise into an internet-facing one. Manus has no UI toggle for either; the control is prompt + review.

Tip: watch the live timeline and kill the task on sight of expose_port, code-server, ngrok, cloudflared, or unexpected curl ... | sh — the sandbox cannot stop these, only you can.

Scope Connectors and Custom Apps Like Production Credentials

Connectors (Gmail, Drive, Slack, Meta Ads, GitHub) attach OAuth tokens any future task can use; Custom Apps add user-supplied API keys. A prompt injection weeks from now can exercise every connector you ever authorised.

Tip: grant narrowest scope each IdP offers (Google: dedicated account, share specific Drive folders only; GitHub: install Manus app on one repo, not whole org; Slack: workspace bot with channel-level access, not user OAuth); audit monthly: Account → Connectors and the IdP's third-party-apps list; never connect a production-admin identity — create a manus-bot@ identity per environment.

Set Hard Credit and Spend Limits

Manus is credit-metered (Free 300/day, Plus ~3,900/mo, Pro ~19,900/mo, Team shared pools); a runaway or hijacked agent burns the monthly allocation in hours and your card on auto-recharge. No per-task budget cap.

Tip: Account → Billing — disable auto-recharge / "top-up on low balance"; use a virtual card (Privacy.com, Revolut Disposable) with a monthly cap; Team — assign per-member credit pools, not one shared org pool. Treat sudden credit burn as an incident signal — pause the task, review the replay.

Assume Every Input Is a Prompt-Injection Vector

The Embrace The Red kill-chain proved PDFs, web pages, emails, Slack messages, GitHub issues, Docs are all valid injection carriers. The agent has no robust instruction/data separation.

Tip: keep a small "system card" in Manus Knowledge that re-asserts these rules every task — Knowledge is injected into the system prompt and is the closest thing to a persistent guardrail Manus offers; never let one task both (a) read untrusted content and (b) hold connector access to Gmail/Drive/Slack/GitHub.

Review the Replay Log Before You Trust the Output

Every task ships a deterministic Replay (timeline of every tool call, shell command, browser nav, file write) and a public-share toggle. The replay is the only forensic artefact you get; the share toggle is the easiest way to accidentally publish a session including pasted secrets.

Tip: archive replays of any task that touched a connector before deletion — if you later need to prove what the agent did or did not exfiltrate, the replay is the evidence.

Use Team Plan Controls and Workspace Segmentation

Team admins can invite/remove members, see shared tasks, manage shared connector pool — but no per-role tool restrictions and no SCIM. Controls are seat management and shared-workspace hygiene.

Tip: require WebAuthn on the upstream IdP for every seat; one shared connector per service, scoped to a bot identity (do not let members attach personal Google accounts); disable public sharing by default; review the shared task list weekly for anything labelled "Public". Separate "research" seats (no connectors) from "operator" seats (connectors attached).

Opt Out of Training Use and Minimise Data Retention

Manus says customer data is deleted on account termination + SOC 2 / ISO 27001 controls apply, but training-use defaults and retention windows for replays and snapshots have shifted across releases.

Tip: Account → Privacy / Data — turn off "Improve Manus using my conversations" if present; turn off public showcase / community feed contributions; periodic: Account → Tasks → select all → Delete; review Knowledge pinned facts (they are read by every future task). Offboarding: revoke connectors at the IdP first, then delete Manus. Never paste secrets, PII, or prod credentials into prompts or Knowledge.

Built-In Security Audit, Version Pinning, Node Baseline

OpenClaw ships a first-class security audit command that scans filesystem perms, gateway bind/auth, exec policy, plugin supply chain, and exposure flags. SECURITY.md now mandates Node.js >= 22.16.0 (citing CVE-2025-59466 async_hooks DoS and CVE-2026-21636 permission-model bypass). The Apr 2026 beta also introduced security.audit.suppressions for triaged audit findings.

Tip: run security audit --deep weekly via cron and after every openclaw update; commit the JSON output for diffing; use security.audit.suppressions sparingly with review dates so triaged findings don't silently rot.

Gateway / Control-UI Network Binding

The Gateway listens on http://127.0.0.1:18789/ by default. Keep gateway.bind: "loopback" and front remote access with Tailscale Serve (which keeps Gateway on loopback) rather than LAN/public binds.

Tip: never set gateway.bind to "lan" / "custom" without simultaneously setting gateway.auth.mode to token or password.

Authentication (Gateway Token / Password / Trusted Proxy)

Three auth modes for the Gateway WebSocket: token, password, trusted-proxy. No built-in OAuth or 2FA for the Gateway itself — 2FA is delegated to upstream channels. The standalone browser-control API only honors token/password, never proxy identity.

Tip: rotate gateway.auth.token (and provider keys in ~/.openclaw/agents/<id>/agent/auth-profiles.json) on a schedule; restart the Gateway after rotation.

Isolation (Sandbox Modes, Docker, Workspace Scope)

Sandbox defaults to off for the main session — tools execute on the host. Force isolation for non-main sessions and restrict workspace mounts. Backends: Docker (default), SSH, OpenShell.

Tip: run the Docker sandbox with --read-only and dropped capabilities; never set tools.exec.applyPatch.workspaceOnly: false — the audit flags it as dangerous. OpenShell sandbox: GHSA-wppj-c6mr-83jj + GHSA-5h3g-6xhh-rg6p (Apr 23 2026, both High) patched path-traversal escapes via the filesystem bridge — pre-patch, the OpenShell backend allowed reads + writes outside the sandbox mount root. Pin a post-Apr-23 build.

Tool Allowlist / Permission System

Tools are grouped (group:automation, group:runtime, group:fs, plus named tools gateway, cron, sessions_spawn, sessions_send). Use the messaging profile and deny by default; require human approval on exec. GHSA-x3h8-jrgh-p8jx (Apr 23 2026) closed a heredoc / shell-expansion bypass in the execution allowlist analyser — pre-patch, attackers could smuggle disallowed commands past group:automation/runtime rules via unquoted heredocs.

Tip: the gateway tool can mutate config persistently — keep it denied for untrusted channels. GHSA-cwj3-vqpp-pmxr (Apr 24 2026) showed LLM-driven calls were able to mutate Gateway config until the model-driven config mutation guard landed — upgrade past Apr 24.

Credential / API Key Handling

Secrets live under ~/.openclaw/credentials/<channel>/, ~/.openclaw/agents/<id>/agent/auth-profiles.json (model keys), and optional ~/.openclaw/secrets.json. No built-in vault — file perms are the boundary.

Tip: never commit openclaw.json; openclaw security audit checks fs.* perms — let --fix apply them.

Plugin / Skill / MCP Server Vetting

Skills are markdown directories (SKILL.md) installed from ClawHub (runs VirusTotal + ClawScan + static analysis). Plugins load in-process with operator privileges. MCP servers configured via openclaw mcp set. Treat all three as untrusted code.

Config knobs: skills.install.allowUploadedArchives: false, plugins.entries.acpx.config.permissionMode: "approve-each" (never approve-all). MCP stdio blocks NODE_OPTIONS / PYTHONSTARTUP / PERL5OPT automatically. GHSA-r6xh-pqhr-v4xh (Apr 23 2026) closed an MCP loopback owner-spoofing bug — owner context is now derived from the local pairing, not the server's bearer token.

Tip: pin skills via agents.list[].skills allowlist (non-empty allowlist is final, doesn't merge). Pinned skills get update-signing via the ATLAS v1.0 roadmap — opt into signed-only installs once available.

Prompt Injection Defense

SECURITY.md explicitly states prompt-injection without a boundary bypass is out of scope — defense is the operator's job. The primary lever is contextVisibility, which filters quoted/forwarded/thread context that LLMs ingest as instructions.

Tip: combine context filtering with tools.exec.security: "deny" and ask: "always"; approve pairings deliberately via openclaw pairing approve <channel> <code>.

Updates, Patch Hygiene, Threat-Model Roadmap

Three release channels: stable, beta, dev. The openclaw update command auto-detects install type, runs diagnostics, restarts the Gateway. The upstream MITRE ATLAS v1.0 threat model (Feb 2026 rebase) plus a new formal verification doc are now part of the security baseline. Net-new 2026 controls in the roadmap: VirusTotal scanning of ClawHub skills, token encryption at rest, recommended skill sandboxing, signed skill packages, explicit "no rate limiting today" gap.

The May 2026 beta (v2026.5.16-beta.5) added an HTTPS managed forward-proxy (proxy.tls.caFile), rejection of forged loopback Control-UI origins from non-local proxy paths, and a 15s timeout on legacy before_agent_start plugin hooks. Until skill update signing ships, compensate with a self-hosted reverse proxy that rate-limits the Gateway and encrypt ~/.openclaw/credentials/ at rest (FileVault on macOS, LUKS on Linux).

Tip: stay on stable; subscribe to GitHub Security Advisories on openclaw/openclaw; rerun security audit --deep after every update because config migrations can re-introduce defaults.

Logging / Monitoring / Telemetry

OpenClaw writes session transcripts to ~/.openclaw/agents/<agentId>/sessions/*.jsonl and Gateway logs to /tmp/openclaw/openclaw-YYYY-MM-DD.log — anyone with FS access can read them. Enable redaction; export metrics via Prometheus / OpenTelemetry. ClawHub telemetry is opt-out.

Tip: logging.redactSensitive: "tools" is what audit --fix restores — don't disable it; rotate/encrypt ~/.openclaw/agents/*/sessions/ if the host is shared.

Version Pinning / Install Provenance / Model Selection

Hermes ships from github.com/NousResearch/hermes-agent under MIT; current stable v0.14.0 / v2026.5.16 (2026-05-16, "security wave"). The default installer is a curl | bash from hermes-agent.nousresearch.com/install.sh — convenient, but bypasses signature verification. Prefer cloning at a tagged release. v0.14.0 also adds a built-in supply-chain advisory checker that scans every install for unsafe dependency versions; run it after each upgrade. The [all] extras were restructured so heavy/risky backends (Hindsight client, image gen, voice/TTS) are lazy-installed on first use — pin a lean extras set unless you need them.

Tip: never curl | bash to production; pin a git tag, audit the installer, pin model IDs. Anything < v0.14.0 leaks credentials into chat output by default — upgrade as a priority, or at minimum set HERMES_REDACT_SECRETS=1 and audit gateway adapters.

Server / API Exposure (Gateway, ACP, Batch)

CLI is local-only, but the Gateway is a persistent server that connects outward to messaging platforms — meaning anyone who DMs your bot is a potential prompt source. ACP runs over stdio (safe). Run the Gateway as a non-root user, on a dedicated host or VM, with outbound egress filtered to provider APIs only.

Tip: treat the Gateway like a public-facing bot — separate host, dedicated UNIX user, egress allowlist, no local terminal backend.

Authentication (Gateway Authorization + DM Pairing)

Hermes does not use OAuth/SSO for the agent itself; it authorizes inbound users through a 6-step check chain. Default is deny. Use explicit allowlists; never set *_ALLOW_ALL_USERS=true in production. The DM-pairing flow issues 8-char codes for unknown users that the owner must approve out-of-band.

Tip: explicit per-platform allowlists + unauthorized_dm_behavior: ignore; audit hermes pairing list weekly. v0.14.0 scopes Discord role allowlists to their guild (closes a CVSS 8.1 cross-guild DM bypass) and makes WhatsApp reject messages from unknown contacts by default.

Isolation / Sandboxing of Tool Execution

Seven terminal backends. The local default is unsandboxed — only protected by in-process "dangerous command" heuristics which SECURITY.md explicitly disclaims as non-boundaries. Switch to docker (or modal / daytona / vercel_sandbox for cloud) so the container becomes the actual trust boundary. execute_code and MCP subprocesses can still reach host state — only whole-process wrapping closes that gap.

Tip: Docker terminal backend for tools and run the whole Hermes process inside its own container for defense in depth. Container-backend caveat (community audit #7826, finding C3): containerized backends skip all in-process approval checks by design — so the container itself must be tightly configured (read-only root, dropped caps, no host mounts, no SSH-agent forwarding). Operators cannot lean on the approval prompt there. Pair with explicit HERMES_WRITE_SAFE_ROOT (opt-in by default — finding H4).

Tool Allowlist / Function-Calling Restrictions

70+ tools auto-register from tools/registry.py across ~28 toolsets. The Hermes 4 model emits XML <tool_call> blocks with high reliability — anything you leave enabled, the model will use.

Tip: start from a minimal allowlist (deny-by-default toolset list) and re-enable only what a given workflow demands. v0.14.0 closed three known bypasses of the dangerous-command detector and now flags sudo -S plus stdin-fed / askpass-stripped sudo as DANGEROUS; unnecessary shell=True subprocess calls were removed across the codebase to shrink shell-injection surface. The in-process gate is hardened but still not load-bearing per SECURITY.md — OS isolation is the only trust boundary.

Credential / API Key Handling

Hermes stores secrets in ~/.hermes/.env (auto-routed by hermes config set) and OAuth tokens in ~/.hermes/auth.json. Critically, execute_code and terminal strip API keys from child-process env by default; only vars in required_environment_variables (skill manifest) or terminal.env_passthrough are forwarded.

Tip: chmod 600 the env file, audit terminal.env_passthrough and every skill's required_environment_variables, rotate provider keys quarterly, scope each key (OpenRouter sub-keys per skill). v0.14.0 flips HERMES_REDACT_SECRETS to default-on and routes all outbound chat messages through redact_sensitive_text in gateway platform adapters; hermes debug share also redacts payloads before upload. TOCTOU races in auth.json + MCP OAuth flow were closed in the same release.

Plugin / MCP / Tool Registry Vetting

Plugins load from three sources at import time: ~/.hermes/plugins/, .hermes/plugins/, and pip entry points — each is arbitrary Python executed in-process. Skills from the community Skills Hub are flagged as the top supply-chain risk. MCP servers get no default authentication or capability scoping.

Tip: treat plugins and skills as code dependencies — git-pin, code-review, never auto-update from the Hub; run MCP servers themselves in containers. v0.14.0 sanitizes tool error strings before re-injection into model context (closes prompt-injection via crafted stderr), covers remaining SSRF fetch paths in the skills hub, and gates plugin API routes behind dashboard authentication — so dashboard credentials are now a higher-value target (use strong auth + non-default bind). Persistent skills (community audit #7826, finding C4): writeable ~/.hermes/skills/ enables cross-session prompt-injection persistence — make it read-only or audit weekly for new files.

Prompt Injection Defense (and the Hermes-LLM Tradeoff)

Hermes 4 is explicitly tuned for high steerability and low refusal — it follows system prompts strictly, including malicious ones. This makes prompt injection from retrieved context (web pages, memory, AGENTS.md, .cursorrules, SOUL.md) more dangerous than against more refusal-heavy models. Hermes Agent includes the tirith pre-exec scanner, SSRF blocking, and context-file injection scanning.

Tip: approvals.mode: manual, tirith_fail_open: false, never disable SSRF protection, treat every retrieved document as hostile input.

Updates / Model Upgrades / Telemetry

Updates flow through hermes update. Tirith itself auto-installs from GitHub releases with SHA-256 checksum verification on first use. Model upgrades through the provider abstraction are silent if you use floating aliases — pin model versions. The SOUL.md / personality system is part of the supply chain.

Tip: stage updates in a non-production profile first; subscribe to NousResearch/hermes-agent releases. CVE-2026-7396 (WeChat adapter path traversal) is the only public CVE to date — assume more will land.

Logging / Monitoring / Audit Trail

Hermes writes to ~/.hermes/logs/ and stores sessions in ~/.hermes/sessions/; tool calls and approvals flow through the event hooks system, which can dispatch to webhooks. Memory writes hit a SQLite + FTS5 store — invaluable for forensics, but also the prime injection target.

Tip: ship ~/.hermes/logs/ and tool-call hooks to your SIEM, snapshot the SQLite memory DB daily for tamper detection, alert on approvals.mode changes and any /yolo toggle.

Version Pinning / Install Provenance

NanoClaw is install-from-git only (no npm/pypi package); canonical clone is https://github.com/nanocoai/nanoclaw.git. Releases became reliable only at v2.0.63 (May 2026). Pin to a signed release tag rather than tracking main, and verify the GitHub org is nanocoai (project was renamed from qwibitai/nanoclaw; stale forks under the old name still appear in CVE feeds).

Tip: check out a specific release tag, record the commit SHA in your config-management system, re-run pnpm install --frozen-lockfile after every pull.

Server / UI Exposure

NanoClaw's host process does not expose a public HTTP API or admin UI by default. The only network ingress is via channel adapters that you explicitly install (Slack uses Socket Mode and needs no public URL; WhatsApp/Telegram use vendor APIs; the optional Dashboard and Emacs-bridge skills bind locally). Service names are per-install: com.nanoclaw.<sha1(projectRoot)[:8]> on launchd, nanoclaw-<slug>.service on systemd.

Tip: never install Dashboard or Emacs-bridge skills on a multi-user machine without firewalling them to 127.0.0.1; audit lsof after every /add-<channel> skill install.

Authentication

Three-level authorization model: roles (Owner/Admin/Member), unknown-sender policy (public / strict / request_approval), and per-channel sender-scope (all / known). No password/login — identity is the channel-account-ID of the message sender. The Main group ("self-chat") is trusted; every other group is treated as untrusted input.

Tip: default to unknown-sender-policy: strict on every non-Main group; reserve Owner role for one identity; use request_approval only on channels where the admin actually monitors approval cards.

Isolation (Docker / Sandbox)

Isolation is the primary security boundary. Each agent group runs in its own ephemeral Linux container (--rm, uid 1000 node, tini as PID 1). On macOS you can opt into Apple Container via /convert-to-apple-container; Docker Sandboxes provides micro-VM isolation. Only directories you explicitly mount are visible; project root is mounted read-only for Main group, and .env is shadowed with /dev/null inside containers.

Tip: turn on Docker Sandboxes (micro-VM) for any agent that touches untrusted channels (public Discord, GitHub PR comments); never mount ~, /, or any parent of credential directories.

Tool Allowlist / Permission System

Tool gating is enforced primarily by mount scope rather than per-tool allowlists — the agent's Bash/Read/Write runs inside the container, so it can only touch what's mounted. Cross-group operations (sending to another chat, scheduling for another user) are blocked at the IPC layer: non-Main groups can act only on themselves. v2.0.63 explicitly hardened this: scopeField now fails closed when scope is missing, and sessions get is guarded against cross-group oracle access.

Tip: enable nonMainReadOnly on every non-Main group, keep MCP tool installs minimal, review mount-allowlist.json after every skill install.

Credential / API Key Handling — OneCLI Agent Vault

Real API credentials never enter containers. OneCLI Agent Vault ships as a single Docker container (ghcr.io/onecli/onecli) running two co-located services: a Rust HTTP gateway on port 10255 (intercepts outbound agent requests, swaps placeholder keys with real credentials) and a Next.js dashboard on port 10254. Production deployments use Docker Compose with PostgreSQL — credentials are AES-256-GCM encrypted at rest, decrypted only at request time.

Container routing works by MITM TLS proxy: the gateway generates a local CA, NanoClaw containers trust it via REQUESTS_CA_BUNDLE, and applyContainerConfig({ agent: agentIdentifier }) from @onecli-sh/sdk injects HTTPS_PROXY=http://localhost:10255 into the container environment. The gateway terminates TLS from the agent, rewrites Authorization headers, and re-encrypts upstream with Rustls — same model as mitmproxy. Agents cannot read keys from env, stdin, files, or /proc; they only ever see placeholder tokens.

Rules are evaluated deterministically at the proxy before any upstream call. Documented flags: --host-pattern, --path-pattern, --method (GET|POST|PUT|PATCH|DELETE), --action (block or rate_limit), --agent-id, --rate-limit + --rate-limit-window (minute|hour|day). Agents authenticate to the gateway with a token presented in the Proxy-Authorization header, issued by onecli agents create. Audit data surfaces in the dashboard Logs pane (agent name, target host, path, timestamp per proxied request) — there is no documented CLI subcommand and no published log-shipping schema, so SIEM export is currently a manual scrape.

Limitations documented or implied as not-yet-shipped: time-of-day windows in rules, source-IP predicates, mTLS client-cert auth to upstream, first-class connectors for HashiCorp Vault / 1Password / SOPS / cloud KMS — NanoClaw's SECURITY.md notes "time-bound access and approval flows are on the roadmap." If you need any of these today, layer them at your egress proxy / IdP, not at OneCLI.

Tip: never put ANTHROPIC_API_KEY directly in .env, container.json, or NanoClaw's central DB — always go through OneCLI. Bind the dashboard to loopback only (127.0.0.1:10254:10254) or VPN — upstream docs are explicit that "the web dashboard should not be exposed to the internet." Set placeholder values (e.g. OPENAI_API_KEY=placeholder) inside containers so accidental direct-API fallback paths fail closed. Run the multi-user deployment Postgres-backed, not embedded-SQLite. Give each NanoClaw agent group its own OneCLI identity with the narrowest secret scope + rate-limit policy; rotate tokens (agents regenerate-token) on any suspected compromise.

Plugin / Skill / MCP Server Safety

Trunk ships only the registry and infra; channels and providers are installed as skills from the channels and providers branches via /add-<name>. Trunk .mcp.json is empty ({"mcpServers": {}}) — MCP servers arrive only when a skill adds them. v2.0.63 fixed a bug where MCP servers added via add_mcp_server were not inheriting OneCLI gateway routing, so older installs may have leaked keys to MCP tools.

Tip: install only the channel and provider skills you actively use; review the diff every /add-<name> produces before committing; upgrade to v2.0.63+ so MCP servers route credentials through OneCLI.

Prompt Injection Defense

Prompt injection is treated as inevitable, mitigated by blast-radius reduction rather than input filtering. A compromised agent is limited to its own session DB, its own mounts, and its own OneCLI identity. The host enforces destination wrapping (<message> tags) and v2.0.63 hardened compaction-reminder placement so it survives SDK auto-compaction. CVE-2026-7875 showed why the host/container boundary matters: a prompt-injected agent supplied crafted messages_out.id and content.files (and symlinked outbox files) to make the host read/delete files outside the outbox.

Tip: run v2.0.63 or later, never set unknown-sender-policy: public, never mount ~ or anything containing credentials into any container, never grant a non-Main group cross-channel send rights.

Update / Telemetry Control

Telemetry is opt-in and skill-driven: diagnostics only run during /setup and /update-nanoclaw skill workflows, written as markdown instructions. Updates are pull-from-git plus skill re-application; /update-nanoclaw previews changes with rollback. Supply-chain defenses on the host: pnpm-workspace.yaml sets minimumReleaseAge: 4320 (3 days) and onlyBuiltDependencies restricts install/postinstall scripts to exactly four packages by name: better-sqlite3, esbuild, protobufjs, sharp. .npmrc minReleaseAge=3d is a fallback layer beneath the workspace setting.

Tip: keep minimumReleaseAge: 4320; never add minimumReleaseAgeExclude entries without a human-approved CVE reference and exact-version pin; subscribe to the GitHub Releases feed.

Logging / Monitoring / Audit Trail

NanoClaw deliberately ships no monitoring dashboard or debugging UI on trunk — the AI-native model is to ask Claude Code via /debug. Per-session state lives in two SQLite files (inbound.db, outbound.db) with exactly one writer each, plus a central DB tracking users, roles, agent groups, messaging-group wirings and migrations. The optional Dashboard skill adds a local UI for sessions, agents, and token usage; container logs available via docker logs.

Tip: ship docker logs to a write-only off-host store (CVE-2026-7875 showed the outbox can be abused for host-side delete, so don't keep your only copy of logs on the same host); install Dashboard skill only on a trusted local network; periodically diff mount-allowlist.json against a known-good baseline.

pre-commit Framework Setup

The pre-commit framework (pre-commit.com) is the universal harness — runs language-agnostic hooks defined in .pre-commit-config.yaml, pinned by SHA, isolated in per-hook virtualenvs. Pin every rev: so an agent cannot silently bump a hook to a malicious version.

Tip: mirror the same config in CI via pre-commit/action@v3.0.1 so local-skipped hooks (SKIP=gitleaks git commit) still fail the PR.

gitleaks — Fast Regex Scanner

Gitleaks scans git history and staged content against ~150 built-in regex rules plus your custom ones. Fast, deterministic first-line scanner; combine with a baseline file so legacy false positives don't drown real findings.

Tip: generate the baseline once with gitleaks detect --report-path .gitleaks-baseline.json, commit it, require any new finding (not in baseline) to fail CI.

trufflehog — Live Credential Verification

TruffleHog goes beyond regex — its --results=verified mode actively pings the provider API to confirm a credential is live. Use verified in CI to cut noise to zero; use unverified in nightly audits to catch dormant keys.

Tip: run --only-verified on every PR (blocking), and a full-history --results=verified,unknown scan weekly via a scheduled GitHub Action. For repos >1 GB, prefer trufflehog filesystem on a checkout over trufflehog git.

detect-secrets (Yelp) — Auditable Baseline

detect-secrets takes a different approach — an auditable baseline of every potential secret, with entropy plus plugin heuristics. Ideal when you need a reviewable artifact showing what's been triaged.

Tip: require a human (not an agent) to be the git author of any commit touching .secrets.baseline — enforce via CODEOWNERS.

AI-Agent-Specific Scanners (Prompt Injection & Rules Files)

Agent rule files (.cursorrules, .clinerules, .opencode/agents/*.md, CLAUDE.md, AGENTS.md, .github/copilot-instructions.md) execute as system prompts — treat them as code.

• promptfoo — npx promptfoo@latest redteam init / promptfoo redteam run
• NVIDIA garak — pipx install garak; LLM vulnerability scanner with 100+ probes
• Mindgard CLI — pipx install mindgard; commercial red-team runner
• Lasso Security — commercial runtime/CI scanner

Tip: add a local pre-commit hook that greps rule files for suspicious tokens (ignore previous, system:, base64 blobs, fenced <|im_start|>) and require a security-team CODEOWNER review for any change under .cursor/, .opencode/, .clinerules, CLAUDE.md.

Repository Hygiene — .gitignore for Agent Config Dirs

Agent IDEs and CLIs scatter credentials across well-known paths. Most are project-local and will end up in git status unless ignored.

Tip: keep .env.example committed; add a pre-commit hook that hard-fails on any path matching *credentials*, *auth.json, or mcp.json regardless of .gitignore (defense against git add -f).

CI Gates — Block Secrets, Gate Agent-Authored Commits

Two gates: (a) secret scan on every PR, (b) human-review requirement on commits whose trailers identify an AI agent.

Tip: enforce branch protection requiring secrets + agent-authored-review checks; maintain a git log --author= allowlist of trusted committers.

Hidden-Unicode / Bidi Detection

"Trojan Source" attacks (CVE-2021-42574) hide logic in U+202A–U+202E bidi controls and U+200B–U+200F zero-widths — devastating in agent-authored code because reviewers skim.

Additional tools: bidiscan, npm i -g anti-trojan-source, cargo install trojan-source-finder.

Tip: add the regex above as both a pre-commit local hook and a gitleaks rule — belt-and-suspenders, since agents sometimes echo invisible chars from web-fetched content.

Pre-Push & Post-Checkout — Inspect Third-Party Repos

Before pointing an agent at a freshly-cloned repo, scan it. A malicious .cursorrules or .opencode/agents/*.md can hijack the agent on first invocation.

Tip: for any cloned repo, run git log --diff-filter=A --name-only -- '.cursor*' '.opencode*' '.claude*' '.cline*' to see who introduced agent configs — then audit each before invoking an agent.

Supply-Chain Scanning for Agent Extensions & Plugins

Cursor/Cline/opencode/Pi marketplaces and MCP server registries have shipped weaponized packages (typosquats, dependency-confusion, post-install scripts exfiltrating ~/.aws). Treat every agent extension and MCP server like an npm dep.

Tip: pin every MCP server and agent extension by integrity hash (npm ci with committed lockfile, or uvx --from 'pkg==X.Y.Z'); run osv-scanner + socket on every PR; subscribe to Dependabot + Socket advisories.