Open a private security advisory on this repository. Please do not open a public issue for a vulnerability.

Expect an acknowledgement within 3 working days and an assessment within 10. This is a small project maintained in evenings; if a fix will take longer than that, you will be told so rather than left waiting. Anyone who reports a valid issue is credited in the release notes unless they ask not to be.

There is no bug bounty.

The parts of this project that touch a trust boundary:

• agentsec/probe/blast_probe.py — runs inside the sandbox under test. It is stdlib-only and non-exfiltrating by construction: it reports the names of secret-looking environment variables and the paths of credential files, never their contents. Its network checks resolve and connect to a fixed list of hosts, send nothing, and close; a configured egress proxy is sent only a CONNECT request for those hosts and one control host. Anything that makes it read, transmit or persist a secret value is in scope, with one documented, opt-in exception: with AGENTSEC_PROBE_PROXY_AUTH=1 the proxy's own password is sent to that proxy and nowhere else. Sending it anywhere else, sending it without the opt-in, or recording it is in scope.
• agentsec/ui/server.py — the local console. Its threat model is written at the top of the module. Anything that lets a web page reach the API without the token, defeat the Host check, or cause a command outside the shipped presets to run is in scope.
• agentsec/verify.py — the repository it reads is written by the agent being checked. Anything in that repository that can change the verdict, hide a file from the check, or write outside the temporary tree is in scope. The limit stated in the module, that a change can forge the test runner's own result, is known.
• agentsec/redact.py — anything --redact fails to remove that identifies an operator or a machine.
• agentsec/runner.py — argument handling that lets a crafted image name, preset or flag reach a shell.

• A high score is not a vulnerability in this tool. It is a measurement of the sandbox you pointed it at.
• The probe writes marker files. One zero-byte marker per probed directory, created and removed immediately. That is how writability is measured, and it can trip file-integrity monitoring. It is documented, not a defect.
• The probe opens startup and settings files for writing. Existing shell startup files, authorized_keys, .gitconfig and agent settings files are opened for append and closed without writing, which a file watcher sees as a close-after-write event. Nothing is written or created; a change that writes or creates one would be in scope.
• Running the tool against infrastructure you do not have permission to test. That is on you.

agentsec measures sandboxes shipped by named vendors and publishes the numbers. The rule this project holds itself to:

1. Nothing that contradicts a vendor's own documentation is published before that vendor has been told and given time to respond. A measurement that merely confirms documented behaviour may be published, and is labelled as documented behaviour rather than as a finding.
2. A documented design boundary is recorded as such, never dressed up as a vulnerability. Several profiles shipped here say exactly that.
3. Every profile states how it was measured, in what environment, and by whom — including where the measurer and the measured are the same product. A score with no record of its environment is not comparable to anything.

If you maintain a tool measured here and think a profile is wrong, open an advisory or an issue. A correction ships faster than an argument.

Read agentsec/probe/blast_probe.py before running it somewhere you care about. It is one file and it is meant to be read. docs/CAPTURING.md explains how to run it inside an agent you do not control, and --redact scrubs a report before you share it.

This repository is public. Checked against the repository's settings on 2026-11-04:

• Private vulnerability reporting, which the advisory link at the top of this file depends on.
• Secret scanning and push protection. GitHub scans the repository and its history, and refuses a push that carries a recognised credential.
• CodeQL code scanning, from .github/workflows/codeql.yml.
• Dependabot alerts and Dependabot security updates, so a vulnerable dependency raises a pull request, and Dependabot version updates for pip and for the GitHub Actions these workflows pin.
• Secret scanning, dependency audit and a security lint in CI, kept beside GitHub's own because they also run on forks and fail the build rather than raise an alert: detect-secrets against an audited baseline, pip-audit, and bandit at high severity. The baseline holds six audited false positives, five planted test values and one axis label, and anything new fails the build.
• A leak check as its own job, which walks every tracked file and fails on an operator's home path. That has been needed twice. It checks the current tree, not history; history was searched by hand on 2026-11-04 and holds the maintainer's username in a few scrubbed paths and no credentials.

Releases publish to PyPI from .github/workflows/release.yml through trusted publishing, with no stored token; CONTRIBUTING.md lists the setup.