Safety
openaudit treats every target as hostile:
- Files: reads are confined to the project root and never follow symlinks out of it.
- HTTP: user-supplied headers go only to the exact target origin, and credentials are stripped on cross-origin redirects.
- Agents: openaudit's own agents have no shell, and the browser is held to the target origin at the network layer. deepsec's reviewer does get a sandboxed shell, which is why it is opt-in.
- Wrapped tools: tools never build or install the target. They run from temporary directories so project config can't redirect them (pnpm hook files, pa11y config, oxlint JS plugins, Spectral custom functions). Linters whose config is code (ESLint, clippy, mypy, golangci-lint) are opt-in.
- Git: every git call overrides
core.fsmonitorand hooks, diffs compare commits rather than the working tree, and history scans run on a fresh mirror clone. - Active scanning: the ZAP active scan runs only against hosts allow-listed in a trusted
--config. - Hosted URL-audit API: connections are pinned to DNS-validated public IPs.
- Evidence: secrets in evidence are redacted.
URL auditors send only low-volume GET/HEAD requests; the opt-in ZAP scans are the exception. Only audit systems you own or are authorised to test. Report vulnerabilities privately as described in SECURITY.md.
What is sent to the model
- Agentic auditors. Claude reads whatever files inside the project root, and whatever pages on the target origin, it chooses to open with the tools above. That content goes to Anthropic as part of the session. It cannot read files outside the root (such as
~/.sshor~/.aws), and it has no direct way to send data to another host: there is no shell and no WebFetch, andhttp_getand explicit browser navigation are same-origin only. Local-file runs have no network tool at all; for the browser caveat, see Responsible use. Finding evidence is capped at 2,000 characters and common token formats are masked. Only run them on code and sites you are allowed to share with Anthropic under your agreement.options.headersvalues are never put in the prompt;http_getattaches them outside the model's view. - AI insights. Only finding metadata is sent: rule id, title, severity, category, location (file:line, or a URL without its query string), a truncated message, confidence and fingerprint, plus the report's scores and target kinds and technologies. Evidence, remediation text, file contents and local absolute paths are never sent, and common token formats are masked. Large reports are compacted: at most 8 findings per rule and 250 in total are described individually, and the rest are summarised per rule.
Responsible use
Only audit systems you own or are explicitly authorised to test. The web playbooks tell the agent to:
- use only the test accounts you provide
- avoid destructive or data-modifying actions on real data
- avoid denial of service and brute force; login throttling is probed with at most 5 attempts
- stay on the target origin
The headless auditors enforce what they can, as hard tool permissions rather than prompt instructions:
- no shell and no writes
- file access confined to the real project root
http_getand browser navigation pinned to the target origin, with a request cap onhttp_get- blocked browser script evaluation and file upload
Two limits remain:
- The browser is confined to the target origin at the network layer. An init-page guard (
src/browser-guard.ts) aborts every request to another origin and walks redirect chains hop by hop, so links, redirects and page scripts cannot load other sites. Navigation URLs that embed another URL are refused too. Only an allowlist of observation and interaction tools is available (no script evaluation, file upload or file output). The browser runs--isolated, without your API keys in its environment. - Residual risk: the guard runs inside the Playwright MCP process, which is not a sandbox. For hostile targets, run browser playbooks in a container or VM whose egress is limited to the target.
- These controls are not an OS sandbox.
Run agentic audits against staging environments and test accounts.
Reporting a vulnerability
openaudit reads untrusted repositories, artifacts and websites, so we treat bugs that let a scanned target affect the machine running openaudit as security issues. That includes path traversal, command execution, credential leakage and SSRF in the hosted API.
Report vulnerabilities privately through GitHub Security Advisories ("Report a vulnerability" on the repository's Security tab). Do not open a public issue. We aim to acknowledge reports within 3 working days.
Only audit systems you own or are authorised to test.