Quickstart
See Axtary allow, deny, and request approval for agent actions in under ten minutes. The first run needs no account, provider credentials, or API token.
1. Install
npm install -g @axtary/cli
This installs the current published release (@axtary/*@0.6.1) from npm. The
runtime is tested, but this is a pre-1.0 release and APIs may change between
minor versions.
2. Scaffold and check
mkdir my-protected-project && cd my-protected-project
axtary init
axtary doctor connectors --config axtary.yml
init writes a starter axtary.yml. Its policy blocks .env* and secrets/
reads, asks for approval before writes to auth/, billing/, or
infra/prod/, and limits Slack posts to #axtary-dev. doctor reports which
connectors are in demo mode, disabled, or configured for a live check.
If you already know the scope you want, start from a reusable template instead:
axtary init --template repo-only-coding
axtary policy test .axtary/policy-tests/repo-only-coding.policies.test.yml --config axtary.yml
axtary demo --config axtary.yml --template repo-only-coding
Templates are repo-only-coding, staging-reads, incident-investigation, ticket-updates, doc-search, and guarded-prod. The generated policy test and demo --template are policy-only proofs with representative allow/deny cases; they do not call live providers.
3. See the loop end to end
axtary demo --config axtary.yml
Axtary now checks a fixed set of GitHub, Slack, Linear, and MCP actions. The
output starts with the decision: allow, deny, or step_up (approval
required), followed by the reason and action hash. Demo mode makes no provider
calls. Records are written to .axtary/actions.jsonl.
To approve the demo actions and verify that the approved payload is the one that executed:
axtary demo --config axtary.yml --approve-step-up
axtary prove-equivalence --config axtary.yml
If you want these decisions in an existing trace collector, keep going with the core loop first, then add OpenTelemetry export. It is opt-in and exports hashes, decisions, reasons, and audit dimensions — not payload bodies or secrets.
4. First blocked action
Start the enforcement point (leave it running):
axtary proxy --config axtary.yml
In another terminal, simulate a coding agent trying to read a secret:
echo '{"cwd":"'$PWD'","tool_name":"Read","tool_input":{"file_path":"'$PWD'/.env.production"}}' \
| axtary hook claude-code
You'll get a deny with the blocked path prefixes named, and the decision is written to the ledger.
Why does a local file read show up as
github.contents.read? Axtary normalizes every tool call to a provider-neutral action shape so one policy covers file reads, PR creates, and Slack posts alike. Thegithub.prefix is the content namespace, not a network call to GitHub.
5. Gate a real agent
- Claude Code: add the
PreToolUsehook to your project's.claude/settings.json, then ask Claude Code to read.env.production— it gets denied and self-corrects. - Any MCP agent: run
axtary mcp serveand point Claude Code / Cursor / Codex at it.
What you just proved
You saw Axtary check an action before execution, block a secret read, explain the decision, and write a verifiable record. Live connectors use the same decision and record path, with provider setup added.
Where to go next
- Choose what belongs in your infrastructure: Integration architecture explains CLI, MCP, loopback HTTP, the Node SDK, both planes, and all nine packages.
- Enable live provider calls: set its env token (or run
axtary connect linear), switch the connector from demo mode to its live mode inaxtary.yml, and re-rundoctor+smoke. - Read Core concepts to understand ActionPass, policy, and the ledger.
- Find every command and workflow in the CLI reference.
- If a remote reviewer should decide step-up actions, run
axtary loginand start the proxy or supported workflow with--hosted-approval. Hosted access is optional; see the Dashboard guide. - Send governed-action spans to a collector: OpenTelemetry export.
- Connect a provider: GitHub, Jira, a Postgres database, or a user-selected Google Drive file.