⌕

What is Axtary

Axtary is a content-authorization layer for AI-agent actions. Before a tool call reaches GitHub, Slack, Linear, Google Drive, a database, or an internal API, Axtary checks the normalized action and exact payload against deterministic policy. It can allow the action, deny it, or require a person to approve that exact payload.

Provider credentials stay in the local Axtary runtime instead of the agent. An approval cannot be reused for different content. A short-lived signed ActionPass binds authorization to the action and payload hash, and the decision and execution result are written to evidence you can export and verify independently.

Identity tells you which agent is acting. Axtary checks which action it may take. The public ActionPass spec and verifier make that evidence portable.

The problem

Tokens usually grant broad access such as "may post to Slack" or "may write to this repository." They do not decide whether this message belongs in this channel or whether this pull request may touch infra/prod/.

Axtary does not inspect or repair the model's reasoning. It limits what the configured execution boundary will allow and records every attempted action.

What Axtary actually does

  • Decides before execution. Policy runs on the hot path and fails closed. Nothing executes unless it is explicitly allowed.
  • Binds approvals to content. A person reviews the exact payload or diff. If it changes afterward, verification fails.
  • Keeps credentials out of the agent. Provider secrets live in a local proxy/broker, never in the model's context.
  • Records the result. Every decision and outcome is written to a tamper-evident ledger that can be verified offline and exported.

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, see pricing, and use the Integration architecture guide to choose the CLI, MCP, local HTTP, or Node SDK boundary for your infrastructure, then use the CLI reference and Dashboard guide for day-to-day operation, then read Core concepts.

Versioning

Axtary follows semver. The version in the header names the current published npm release (@axtary/*@0.6.1). 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. The public changelog records every available coordinated package release and links each chapter to its npm evidence.