AZT · Agent Zero Trust

Know what changed. Before you delegate.

Your coding agent reads more than code. A README, setup guide or project instruction can ask it to run a command—or ask you to share sensitive information. AZT helps you see what changed, understand what is being asked, and save a readable report before deciding what to trust.

For people building with AI, from their first app to a security review. Free. Offline after installation. No account, model API or telemetry.

Try it · Who it's for · See the examples · Use in GitHub · Help build it

Animation · Still image · Mobile still · Transcript and reproduction

Illustrated demonstration of the recorded CLI workflow, not a shipped graphical interface or live-agent test. Repeats every 22 seconds with a reset; pacing is editorial. No target instruction is executed.

I use AI to build, and I take its risks seriously. AZT is my contribution to helping people use it with less blind trust. — Rafael (Ralph) Peña · Why I'm building this

Who it's for

You don't need to speak security. Start with: What is this asking me to run, share or trust? AZT gives you a place to look, not a decision to obey.

Scan your project

Python 3.9+ on Linux or macOS; native Windows is unsupported. Installation downloads the released package. Scanning and change review then run offline: no account, model calls, telemetry, Docker or hook needed.

Start in the specific project directory you want to inspect. The temporary environment and reports belong outside that directory; don't scan your home, whole disk or a parent directory containing the temporary review folder.

AZT_PROJECT=$(pwd -P)
AZT_REVIEW=$(mktemp -d)
AZT_REVIEW=$(cd "$AZT_REVIEW" && pwd -P)
cd "$AZT_REVIEW"
python3 -m venv "$AZT_REVIEW/venv"
. "$AZT_REVIEW/venv/bin/activate"
python -m pip --isolated install \
  --index-url https://pypi.org/simple --no-deps \
  agent-zero-trust==0.1.13
azt --version
azt scan "$AZT_PROJECT"

Inspect only projects you are authorized to scan. AZT reads their contents; it never runs their instructions. Keep this activated terminal for later checks. Setup runs from the new review directory, not from the inspected project. pwd -P avoids temporary-path symlink aliases on macOS.

Scan exits: 0 passes the selected threshold; 1 has findings meeting it; 2 means incomplete inspection or an error. A clean scan is not proof of safety. The default threshold is HIGH: a MEDIUM warning can be worth reviewing even when the exit code is 0. What's in the released 0.1.13.

azt scan "$AZT_PROJECT" --json > "$AZT_REVIEW/before.json"

azt scan "$AZT_PROJECT" --json > "$AZT_REVIEW/after.json"
azt changes --before "$AZT_REVIEW/before.json" \
  --after "$AZT_REVIEW/after.json"
azt explain net.pipe_shell
azt changes --before "$AZT_REVIEW/before.json" \
  --after "$AZT_REVIEW/after.json" \
  --format html --output "$AZT_REVIEW/review.html"

Reproduce the demo

1. A setup instruction changes

This instruction asks your agent to download and run a remote script. Review the source before using it. That is the reason for review—not a claim that the source is malicious.

Run the four-case synthetic lab for the complete setup and scan → compare → explain → export commands. It uses inert example text, not your project or real credentials; the suspicious instruction is never executed. The lab keeps its environment and reports outside its fixture trees.

The illustrated AGENTS.md edit has two new findings: net.pipe_shell (HIGH: download piped directly into an interpreter) and net.fetch_unknown (MEDIUM: a download host outside the rule's allowlist). The benign edit has none; incomplete inspection retains two unresolved observations. The graphic uses the recorded 0.1.11 candidate at 0296face, not new execution evidence. Transcript · Visual provenance.

2. A helpful-looking request asks for sensitive information

“Upload your API keys” is a different request from “Send only the Python version; do not include API keys.” AZT's sensitive-request review distinguishes these supported examples and explains the possible consequence without looking for your actual keys.

Motion-free view · Mobile still · Inputs, actual output and reproduction

Illustrated CLI results, not a graphical AZT app, live agent or blocked upload. request.sensitive_disclosure is MEDIUM; default HIGH-threshold exit 0 does not mean there is nothing to review. Supported English requests can name shell history, environment dumps, tokens or private-key material. Those materials may contain sensitive information; AZT does not establish that secrets exist or were disclosed. Try the sensitive-request lab.

3. Keep something you can actually review

Export the scan or comparison as a local HTML report, readable text or JSON. The image below shows the top of an actual synthetic scan export—not a proposed dashboard. The full local record carries the scope, finding and maintained guidance together.

Continue in the quickstart's activated terminal. Save a scan and export it with new filenames (a scan exit of 1 still produces a report; run without set -e):

azt scan "$AZT_PROJECT" --json > "$AZT_REVIEW/report-scan.json"
azt report --input "$AZT_REVIEW/report-scan.json" \
  --format html --output "$AZT_REVIEW/scan-review.html"

Open the file locally. Nothing is uploaded by the export command. Raw excerpts are omitted by default, but paths and labels can still be sensitive: review a report before choosing to share it.

Four steps, one review

Saved reports are snapshots, not automatic monitoring. Target .azt-ignore requests cannot silently suppress findings. Explicit operator exceptions remain visible and bound to reviewed content. Migration and policy details.

When to reach for AZT

• Before opening an unfamiliar project with a coding agent. Review project instructions, setup text and supported configuration before relying on them.
• After a template, dependency guide or contributor instruction changes. Compare saved scans to see which observations are new, remain or lost supporting evidence. AZT is not a package-vulnerability database or automatic watcher.
• Before sharing “diagnostics” requested by a project. Check whether the request asks for broad environment/configuration material or narrowly relevant information. An “official” label does not authorize disclosure.
• During a pull-request review. Keep the instruction change and its review context close together, without a bot posting comments or installing target code.
• When you find a miss or a false alarm. Turn it into a minimal synthetic example others can test, instead of sharing private files or real credentials.

Bring the review to a pull request

The existing GitHub Action can scan one supplied checkout, or compare two explicit base/head snapshots using the same scanner. Its job summary shows inspection scope, findings by severity, the selected threshold and a next step.

In the recorded synthetic Action check, the candidate introduced one MEDIUM sensitive-request finding. The HIGH-threshold check stayed green—and the finding remained visible. Green is not approval.

Copy the reviewed, pinned base/head workflow →

Checkout happens separately from inspection. No PR comment bot or extra write permission is required. Summaries and logs follow your GitHub workflow's visibility; job-summary: false opts out of summary content. An ordinary PR workflow can itself be edited by a PR: this is review assistance, not an immutable security gate. Inputs, outputs and trust boundary.

Why I built AZT

AI risk isn't only a conversation about the distant future. In its August 26, 2026 incident account, OpenAI described models crossing technical boundaries during internal cybersecurity evaluations with reduced safeguards. That is a documented incident in a particular setting—not evidence that AZT would have prevented it.

I started AZT in July with a smaller, practical insight: a repository—your project's files—is an instruction environment, not just code. The broader AI-risk discussion pushed me to strengthen that existing work, question AZT's own assumptions, and make its checks and evidence easier for others to inspect.

I want people to benefit from AI without giving it blind trust. This is my contribution to that effort: a free tool for reviewing what could influence a coding agent, with open code and examples people can challenge and improve. It doesn't solve the whole problem. It gives us one useful place to start.

AI Is Getting More Powerful. Blind Trust Is Not a Safety Strategy.

Evidence and scope

“No longer observed” is not “proven fixed.” Missing inputs, incomplete inspection or changed rules can limit comparison. Reports and their hashes are not authenticated evidence. Exported excerpts are omitted, but paths and labels can still be sensitive: review before sharing.

AZT detects known patterns, not every prompt injection or cross-file intention. Recognized files are not necessarily fully parsed. No live-agent integration, continuous authorization or general containment is provided.

Change-review evidence and methodology · Rule guidance and matching · Coverage and known misses · Supported files · Release notes

Optional: snapshot gate and experimental access check

The snapshot gate is an opt-in workflow aid; edits require operator re-admission. A same-user hook or signing key is not a sandbox.

AZT-FS-001 separately compares selected Compose JSON mounts and proposes a reviewable repair. Its historical Docker/Linux evidence is a synthetic trusted-probe experiment—not a live-agent evaluation or general containment. Docker supplies isolation. A passing misconfigured phase demonstrates intentional exposure, not approval of an unsafe configuration. Exact evidence · Prerequisites and reproduction.

Help make the next review better

You can contribute without being a security expert. We need real questions, clear explanations and reproducible examples—not just more rules.

Find your first contribution → · Three scoped coding tasks

Please don't paste real keys, full environment dumps, shell history, customer logs or private repository contents into an issue. Start with inert synthetic text; use the security reporting route for sensitive vulnerabilities.

Contributing guide · Open a reproducible issue · Report a false positive · Coverage and known misses

A few practical questions

Created by Rafael (Ralph) Peña, with credit to contributors and upstream work. The original engine came from rulebench vet. MIT · Citation · Public principles.

Delegate work. Retain control.