The approval should match the action.
Policy can allow an action. A person can approve it. Axtary checks that the thing reaching execution is still the same thing.
I built Axtary around a stubborn question: when an agent is about to change something, what exactly was authorized?
We have increasingly good answers for who an agent is and which systems it can reach. The answer gets much fuzzier at the last moment, when it is about to send this message, open this pull request, or run this query. That last mile is where Axtary lives.
A valid credential can still carry the wrong action
Suppose a reviewer approves a particular Slack message for a particular channel. If the message changes on the way to the API, the OAuth token may still be valid. The agent may still be the same agent. But the approval is no longer an approval of the thing being sent.
The same problem shows up in a changed diff, a broader SQL predicate, a different file path, or an MCP tool whose definition drifted between review and use. Identity and scopes still matter. Axtary starts where they stop: at the proposed action itself.
The test I keep coming back to
The demo I care about most is almost boring. Approve payload A. Change one byte before execution. Try again. The credential is still valid, but the approval is not. Axtary stops before the provider call and records both hashes so the denial can be checked later.
The mismatch, decision, and both hashes remain in the ledger export for independent verification.
What actually works today
Axtary is early, and I would rather be precise than make it sound bigger than it is. The core path works locally, with an optional hosted surface for human review and evidence:
- An installable CLI, local proxy, TypeScript SDK, runtime hooks, and governed MCP wrapper
- The same policy fixtures evaluated through the native, Cedar, and Rego engines
- Local or hosted review of the exact payload when a person needs to decide
- Short-lived ActionPass authority plus a hash-chained ledger and standalone verifier
- Scoped paths for GitHub, Slack, Linear, Jira, Postgres read, Google Drive read, local docs, and clearly labeled cloud-readiness checks
- A credential-free playground and nine registry-backed npm packages at 0.4.0
Not every provider path has the same proof behind it. The public docs separate a credential-free demo, an implemented but disabled connector, and a fresh live run. I do not want an integration logo to stand in for evidence that the path was actually exercised.
Why the verifier is public
A green badge inside Axtary is not enough. If Axtary produces the ledger and is also the only thing allowed to call that ledger valid, the proof is circular. The ActionPass draft and verification workflow are public so someone can inspect an export without trusting the dashboard that produced it.
That is the standard I am aiming for: the policy decision, human approval, provider outcome, and exported evidence should agree on the same action. If they do not, the verifier should say so plainly.
The boundary, plainly
Axtary does not prevent prompt injection, replace an identity provider, or mediate tool calls that never reach its configured boundary. It cannot make an uncovered path safe. What it can do is limit what a wrong, confused, or compromised agent executes on the paths it covers, and leave an attributable record of the attempt.
It also does not turn implemented code into live provider proof. When a path has only deterministic or historical evidence, the docs say that. I would rather keep that boundary visible than borrow confidence from a broad claim.
Try it. Then tell me what breaks.
npm install -g @axtary/cli
axtary init
axtary demo --approve-step-upI am looking for teams already letting coding agents or MCP clients touch code, tickets, messages, or data. Bring me one recurring workflow where a broad credential or a generic approval feels too loose. I am not looking for polite feedback. I want to know where the model is awkward, incomplete, or simply wrong.