⌕

What is Axtary

Axtary is a content-authorization layer for AI-agent actions. Before an agent's tool call reaches GitHub, Slack, Linear, Google Drive, a database, or an internal API, Axtary normalizes what the action will actually do, checks it against deterministic policy, optionally requires a human to approve the exact payload, signs a short-lived ActionPass for that payload, records a tamper-evident ledger entry, and only then executes it through a scoped connector.

The agent never holds your provider credentials, and an approval cannot be replayed against different content — the approval binds to the SHA-256 hash of the exact payload.

AP2 binds a purchase cart. Axtary binds the diff, the Slack body, the SQL predicate, and the MCP tool call. Identity tells you which agent is acting; Axtary proves what exact action it was allowed to take. The public ActionPass spec and verifier make that evidence portable.

The problem

Agents are getting identities and API keys, but tokens authorize a channel ("this agent may post to Slack"), not the content ("this agent may post this exact message to this channel"). A prompt-injected or confused agent holding a valid token can still open a PR that touches infra/prod/, read a .env, or message the wrong channel. OAuth scopes are too coarse for probabilistic actors.

Axtary's job is not to sanitize the model's thoughts. It bounds what a wrong or compromised agent can do and makes every attempted action attributable.

What Axtary actually does

  • Decides before execution. Policy runs on the hot path and fails closed — nothing executes unless it's explicitly allowed.
  • Binds approvals to content. High-blast-radius actions require a human to approve the exact payload/diff; the signed pass is bound to that payload's hash, so the agent can't swap it afterward.
  • Keeps credentials out of the agent. Provider secrets live in a local proxy/broker, never in the model's context.
  • Records everything. Every decision and outcome is written to a hash-chained ledger you can verify offline and export.

In practice: an agent fixing a bug opens a PR — Axtary lets the ordinary edits through but pauses when the diff touches auth/, so a human approves that exact change before it lands. The same agent looks up a customer in a database through the Postgres connector — Axtary checks the exact SELECT, runs it with a dedicated read-only role, and relies on row-level security to keep the result inside the configured tenant scope. Every one of those decisions is in a ledger you can hand to security. Each capability below is one connector enforcing that pattern.

How it's shaped

Axtary runs as two planes:

  • Local enforcement plane (the axtary CLI / proxy / SDK / Claude Code hook / MCP wrapper) — runs on your machine, holds the provider credentials, makes the decision, and executes. This is the hot path.
  • Hosted control plane (the dashboard at axtary.com) — where humans review hosted approvals, inspect synced ledger evidence, and manage the team. Provider credentials stay in the local runtime; the hosted plane is optional for local-only enforcement and required only for hosted approval/sync workflows you enable.

New here? Start with the Quickstart, then read Core concepts.

Versioning

Axtary follows semver. The version in the header names the current published npm release (@axtary/*@0.3.0). Axtary is currently 0.x (pre-1.0): the runtime is real and demoable, but APIs may still change before the first stable 1.0.0 release.