Core concepts
Four ideas explain how Axtary works.
Normalized action
Every tool call — a Claude Code file read, a GitHub PR create, a Slack message, an MCP tool call — is converted into one provider-neutral normalized action: who (actor/tenant/agent), intent, tool, resource, exact payload, and context. Policy, signing, and the ledger all speak this single language, so one rule set covers every connector.
Deterministic policy
Policy is evaluated before execution, locally, and fails closed — if nothing explicitly allows an action, it's denied. Decisions are one of allow, deny, or step_up (needs human approval). The engine is deterministic and fast (it sits on the hot path), and it exports to Cedar and OPA/Rego forms so you can prove the same decision three ways.
Beyond the built-in preset, you can write rules in axtary.yml (a policies block): match by tool/resource/actor, with allow/deny/step_up effects and obligations — required-approver roles, blocked paths, time-of-day and rate windows, and tighter pass TTLs. Rules are default-deny and combine deny-over-step_up-over-allow. axtary policy simulate shows exactly which rule fired and why before you ship a change.
ActionPass
When an action is allowed, Axtary issues an ActionPass: a short-lived, signed, verifiable token scoped to that one action. Crucially it is bound to the SHA-256 hash of the exact payload. Tokens are ephemeral; passes are evidence. Because the pass is offline-verifiable and chained into the ledger, a reviewer (or another tool) can confirm exactly what was authorized.
Proof of possession (ActionPass v1)
Content binding says what a pass authorizes; key binding says who may present it. ActionPass v1 additionally binds a pass to the holder's key (DPoP, RFC 9449, with an RFC 7800 cnf confirmation). To use a pass the agent must present a fresh proof signed by that key for the exact request (method, URI, and the pass itself), with replay protection. A pass captured from logs, memory, or a proxy hop can't be replayed by anyone else — even for the same action. v0 passes (content binding only) still verify; v1 adds the sender constraint.
Delegation
An agent can hand a sub-agent a narrower pass — same human owner and task, but a subset of the scope and one fewer delegation hop. A child can never broaden the tool, resource, payload, or constraints beyond its parent, and the whole root→leaf chain is signature- and attenuation-verified before execution. This bounds blast radius across multi-agent systems instead of sharing one over-broad credential.
Budgets
A policy can attach a budget — a per-tenant, per-actor, or per-task spend limit the runtime owns, never the agent. The proxy reserves against the limit before issuing a pass and commits or rolls back on the outcome, counting in-flight reservations so concurrency can't oversubscribe. A runaway or looping agent is capped. This is metering for blast-radius control — not pricing or billing.
The ledger
Every decision and its post-execution outcome are written to a hash-chained ledger — each record links to the previous one's hash, so any tampering breaks the chain and is detectable. It records the decision, reasons, policy version, payload/action hashes, trace IDs, and the provider result. You can verify it offline and export it (including SIEM-friendly formats).
You can also attest an export: axtary attest-ledger signs it, and anyone — with only a JOSE library and the published public key — can run axtary verify-export (or reimplement the algorithm from the spec) to confirm the signature, the chain, and every record offline, detecting a single-byte change. Tamper-evidence becomes portable evidence an auditor can check without trusting Axtary.
Content authorization, not channel authorization
This is the differentiator. A normal token authorizes a channel: "this agent may post to Slack." Axtary authorizes content: "this agent may post this exact message to this channel." A prompt-injected agent holding a valid scoped token still cannot swap the PR diff or the Slack message after a human approved it — the approval is bound to the exact payload hash, and a mismatch is blocked before execution. That's the claim Axtary makes demoable, not just asserted.
The two planes
- Local enforcement plane holds credentials, decides, and executes (the hot path). It works with no hosted account at all.
- Hosted control plane (axtary.com) is for human review, compliance evidence, and team management. It never holds a provider credential and is never in the critical path of an action.
See the Quickstart to run all of this locally.