Agent Zero Trust
Open-source repository intake for AI coding agents, with experimental access-check and repair tools.
A repo is no longer just code. It is an instruction environment. Before you open an unfamiliar repository in a coding agent, inspect the instructions, hooks, configuration and setup commands that could influence it.
AZT is a deterministic, offline scanner. It flags known suspicious patterns, reports inspection gaps, and keeps the target from silently choosing its own exceptions. No model, account, telemetry or runtime dependency is required.
Install and scan
Python 3.9+ on Linux or macOS. Installation downloads the package; scanning runs offline and does not execute the target's code. Native Windows is unsupported.
python3 -m venv .venv-azt
.venv-azt/bin/python -m pip --isolated install --index-url https://pypi.org/simple --no-deps agent-zero-trust
.venv-azt/bin/azt --version
.venv-azt/bin/azt scan /path/to/authorized-repository
Use a repository you are authorized to inspect. Add --json for scope, findings,
manifest and policy provenance. Exit codes: 0 passes the selected threshold;
1 has findings that meet it; 2 means incomplete inspection or an error.
A clean scan is not proof of safety. You do not need to install a hook.
See a real scan
This is captured output from the published 0.1.9 wheel, scanning inert synthetic text. It never fetched or ran the command. Selected lines:
FINDINGS: 1 HIGH, 1 MEDIUM
[HIGH ] net.pipe_shell README.md:1
EXCEPTIONS: 1 target requests (not applied); 0 trusted suppressed findings
DECISION: deny
Run the tiny demo, read the transcript, or view the static frame.
What changed in 0.1.9
The scanner's own trust boundary needed scrutiny, too. Target .azt-ignore
content no longer suppresses findings. Operator exceptions must come from an
explicit external policy and name an exact rule, path, content hash and reason.
Suppressed findings stay visible. Incomplete inspection cannot quietly pass.
An optional workflow gate now authenticates a receipt for a specific reviewed snapshot. Edits can invalidate that receipt and require operator re-admission. The hook and a key accessible to the same user do not contain hostile code.
Upgrade and migration · Release notes · Why I’m strengthening Agent Zero Trust
Optional: test one access change and its repair
The experimental AZT-FS-001 pack compares an explicit, supported subset of Compose JSON bind mounts. It identifies selected added read access and proposes a minimal, digest-bound configuration diff for review. Static comparison needs no Docker and does not execute the supplied configuration.
On supported native Linux Docker hosts, a bundled trusted probe tests the change using fresh synthetic resources, applies the proposed repair to its disposable test plan, and retests while a small coding task runs. It does not test your real credentials or launch a live coding agent. Docker supplies the isolation; AZT adds configuration interpretation, repair, orchestration and reviewable evidence.
The accepted record covers two configuration inputs for one case, three phases each. Both retained original fixtures and completed cleanup. A passing misconfigured phase means the test demonstrated intentional exposure, not that the unsafe configuration is approved for deployment. Denial is credited only with the positive control and legitimate-task checks.
Exact evidence and limitations · Offline comparison and optional Linux reproduction
Know the boundary
The scanner detects known shapes, not every prompt injection or cross-file
intention. Inventoried formats are not necessarily fully parsed. The public
known-miss ledger predates this update and remains part of the project.
FS-001 is a selected trusted-probe check, not universal containment, a model
evaluation or an independent security audit. Other execution-boundary scenarios
remain untested. The legacy doctor command concerns a deferred general runtime
proposal, not FS-001's Docker prerequisite check.
Coverage and known misses · Supported files · Threat model · Security reporting
Help make it useful
Try an authorized scan. Report a missed detection, false positive or confusing result with a minimal synthetic fixture and the command you ran. Reproduce the documented case before generalizing its result.
Contribute · Open an issue · Use the Action · Public principles
Created by Rafael (Ralph) Peña, with credit to contributors and upstream work. The original engine came from rulebench vet. MIT. Citation metadata.
Delegate work. Retain control.
Release files for agent-zero-trust 0.1.10
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| agent_zero_trust-0.1.10.tar.gz | 748.3 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| agent_zero_trust-0.1.10-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 790.5 kB
Release files / agent_zero_trust-0.1.10.tar.gz
| Download URL | agent_zero_trust-0.1.10.tar.gz |
|---|---|
| Size | 748.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
45445f247f9b80c7674507216bbbfc81b04fac34a696c265b1d2c60d024ff633
|
|
BLAKE2b-256 checksum How to use checksums |
410d8148bc0c9592be5868eee7478c513a66ea6a68ebaba96e974229243bf3c1
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.12.9
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 15, 2026.
Transparency logRelease files / agent_zero_trust-0.1.10-py3-none-any.whl
| Download URL | agent_zero_trust-0.1.10-py3-none-any.whl |
|---|---|
| Size | 42.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
4590931bee7c5dfae400a2120d924a9aae5940f6d31cfa5c35af54feb6ab3535
|
|
BLAKE2b-256 checksum How to use checksums |
43ff43f1aa3d9022fac1fcc34f43764c94f2f6b134b301cd84f742feb679aa07
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.12.9
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 15, 2026.
Transparency log