Handing an AI agent control over GitHub or AWS is convenient, but it creates a problem: as long as an action falls inside the token’s permissions, the agent can do anything. Axtary solves this not at the point where the tool is handed over, but at the moment just before execution. It inspects the actual diff, message, query, or tool argument the agent is about to send, auto-approves routine operations that match policy, and requires human approval for high-risk ones such as production changes. Each approval is bound to a hash of the payload that was presented, so if the content is swapped out afterwards, execution is refused. Built by Axtary in the US and released in June 2026. The CLI and SDK are distributed on npm under @axtary/*, at version 0.6.1 as of August 2026.
Key Features
- Permission per action, not per tool (ActionPass): A conventional API key or OAuth token grants everything the tool can do. Axtary issues a signed authorization credential called an “ActionPass” that authorizes only a single reviewed action, with constraints
- Payload hash binding: An approval is tied to the hash of the exact diff or payload a person actually reviewed. If the content changes afterwards, verification fails and the call is stopped before it executes
- Cedar- and OPA-compatible policies: Deterministically evaluated policy languages let you declare which routine operations are auto-approved and which high-risk ones escalate. Policy is evaluated on the hot path, and when a decision cannot be made it fails closed
- Broad connectors and MCP support: Works with GitHub, Slack, Linear, Jira, Sentry, PostgreSQL, AWS, Google Cloud, and Google Drive, as well as MCP servers. Microsoft, Okta, and Auth0 are listed as coming soon. Signed MCP tool definitions (tool provenance) and a Claude Code hook integration are also provided
- Tamper-evident audit ledger: Every attempt is recorded with its verification history, including approvals, denials, and payload hash mismatches. Records can be exported for audit
- Local enforcement keeps credentials in place: The enforcement point is a local proxy running beside the agent. Credentials stay on your own machine, and the hosted control plane only coordinates approvals, policies, and audit. For local-only operation, no account is required
Pricing
| Plan | Price | What’s included |
|---|---|---|
| Local | Free (no account required) | CLI, SDK, local proxy, MCP wrapper, local policy checks, action ledger, credential-free playground |
| Founding Team | $499/month (after a 30-day pilot) | Everything in Local plus hosted approvals, a team dashboard, verified ledger sync, guided setup, and direct support during the pilot. Scoped to one non-production workflow |
| Enterprise | Custom pricing | Everything in Founding Team plus security team review, scoped identity/retention/deployment, and negotiated support terms |
There is no self-serve checkout yet; paid plans start only after the pilot terms and success criteria are agreed in writing.
Pricing is current as of August 2026. Check the official site for the latest.
Pros & Cons
✅ Pros
- Removes the need to hand out blanket tool-level permissions, so you can widen what the agent is trusted with while keeping the blast radius small
- Because approval is bound to a payload hash, the “what was approved isn’t what ran” class of incident is prevented structurally
- Uses Cedar and OPA, two proven policy languages, so there is no proprietary DSL to learn
- The local proxy model means you can start without handing credentials to a third party, and the free Local plan does not even require signing up
- Decisions and executions are written to a ledger, which makes audits and post-incident tracing straightforward
⚠️ Cons
- The version is 0.x (pre-1.0), and the docs state explicitly that APIs may change before 1.0.0
- Paid plans cannot be bought self-serve and require written pilot terms. At $499/month, Founding Team is not priced for individual use
- It does not inspect the model’s reasoning. What it constrains is the execution boundary, not the agent forming a mistaken intent in the first place
- Evaluating policy on the hot path means real operational cost: deploying the proxy, maintaining policies, and designing approval flows
- The official GitHub organization has no public repositories as of August 2026, so there are limited places to read the code described as Apache-2.0
Comparison with Similar Services
There are several approaches to controlling agent permissions; Axtary specializes in inspection immediately before execution.
| Criteria | Axtary | Native permissions (AWS IAM, GitHub PAT, etc.) | Cedar / OPA alone | Agent’s built-in approval prompt |
|---|---|---|---|---|
| Granularity | A single action, bound to its payload | Scopes per tool or resource | Depends on the policy and implementation | Per tool call, judged by eye |
| Detects post-approval tampering | Refused via hash verification | No | Must be built yourself | No |
| Audit trail | Tamper-evident ledger | Scattered across each service’s logs | Decision logs only | Only what remains in the chat log |
| Setup cost | Proxy deployment plus policy work | Low (uses existing mechanisms) | Requires building a policy platform | Nearly zero |
| Best suited for | Teams delegating multiple connectors to agents | Limited use of a single service | Organizations with their own authorization platform | Individuals and small teams |
Who Is It For
- Teams that want agents to operate GitHub or AWS but are reluctant to hand out broad tokens
- Engineering organizations where MCP-based operations have grown to the point that it is hard to trace which tool executed what
- Platform teams already comfortable running Cedar or OPA policies who want to bring them onto the agent’s execution path
- Companies with audit requirements that need a record of every agent action
- Individual developers who want to try inserting a pre-execution check in front of their own agent using the free Local plan
Summary
Axtary is not a tool for making agents smarter; it is the foundation that lets only human-approved actions through at the moment of execution. Per-action permission via ActionPass, payload hash binding, and a tamper-evident ledger are a direct implementation of what is needed before handing real operational authority to an agent. It is still 0.x and the paid plans have a high barrier to entry, but the free Local plan can be tried while keeping credentials on your own machine, so if you are wrestling with agent permission design it is worth wiring into an actual workflow to see how it behaves.