Approve what AI does for you.
Stop what you didn't agree to.
Take the proof with you.
Strix places a decision boundary in front of consequential AI actions. On a covered route, policy decides before the side effect. Signed evidence can be verified independently when the evidence path is configured and the record and keys are preserved.
No signup. Browser simulation; no real payment. Production evidence is a separate path.
Start here · no signup
Understand the control. Try changing an approved action.
Strix binds authority to a specific action at the execution boundary. Signed evidence records what the control allowed or refused. Use this short path to see the difference.
1 · Try the control model
Approve a sample refund, change its amount, then attempt a replay. Watch which requests reach the simulated adapter.
Browser simulation · about three minutes · no real payment.
Try the refund simulation2 · Inspect production evidence
CFX-009 shows how live refundable state distinguished a refusal from an execution on the governed Academy refund path.
Founder-operated production · separate from the simulation · explicit limits.
Inspect CFX-009 and its records3 · Choose your next step
Engineers can inspect the integration prerequisites. Teams can define one action, the conditions it needs, and who must independently check the result.
Aim to understand the action, challenge the simulation and choose a next step within five minutes. Installing an integration and establishing production coverage are separate work.
From permission to authority for one action.
Logins prove who you are.
Permissions say what you may do.
Logs say what already happened.
The exact action still needs authority. Strix enforces that judgment at the governed boundary.
Model-level guardrails filter what an AI says. Observability tools record what it did. Strix enforces the applicable authority before the governed action reaches its effect-producing call.
A governed action has three possible decisions.
The action runs — and a signed record of the decision is written before the side effect.
The governed route blocks the action. The decision record shows what was refused and why; alternate routes still need coverage review.
A human decides first. The approval is single-use and bound to the exact action that was approved.
For engineers: what the integration looks like
adminProcedure
.input(z.object({...}))
.mutation(handler)
// Executes immediately
// No evidence
// No controlgovernedProcedure("admin.programs.delete")
.input(z.object({...}))
.mutation(handler)
// Intercepted → Evaluated → Decided
// Evidence recorded every timeAny async function or HTTP call can be wrapped the same way with governedAction() from the MIT-licensed @strixgov/governed-action package. Underneath, five rules hold: nothing executes without evaluation; authority does not carry over between actions; admissibility is decided when an action is evaluated and bound to that exact action; enforcement happens before the side effect, not in a log after it; and execution grants are single-use, expiring, and revocable. Full architecture in the docs.
The refund bot, governed.
A demonstration you can walk yourself — ephemeral demo records illustrate the decisions; inspect a separately published production record below.
1 · Denied. An AI agent,
refund_bot_v3, asks to delete every customer record. The capability was never granted to it — the request is refused and nothing runs. The refusal itself becomes a signed record.2 · Held for a human. It then asks to issue a $4,200 refund. That exceeds its autonomy, so the action waits for a human approver — and the approver cannot be the one who asked.
3 · Executed, once. After approval, the refund runs exactly once — and the simulated exchange illustrates a signed evidence chain, including four distinct verification states (verified, invalid, legacy-unsigned, unverifiable).
npx @strixgov/verifier@latest 5686This re-derives the record's hash, chain, and Ed25519 signature against the public key at /.well-known/strix-jwks.json — no Strix account or SDK. This command fetches the record and public key online. For later offline verification, preserve the record, verifier, and the relevant key material.
Three rules that do the work.
Agents cannot issue their own permission slips.
Execution tokens are minted only by the decision kernel, are single-use, and expire. An agent cannot grant itself the authority it was refused.
The one asking cannot be the one approving.
For high-risk actions, the actor requesting an action cannot be the actor who approves it — enforced in policy evaluation, not in the UI.
The record outlives the thing it recorded.
Deleting a governed object does not delete the signed evidence of what happened to it. The trail stays verifiable after the data is gone.
One execution boundary. Multiple ways to protect what AI does.
Control permissions, enforce approvals, prevent unauthorized actions, and verify the evidence. Start with a governed action, then explore the controls behind it.
Boundary
Fail closed where actions enter
A local-first tool gateway, MCP adapter, and standalone proxy evaluate tool calls before they reach the destination. Malformed or unclassified requests do not become permission by default.
Read the integration docs →Authority
Permission does not replay
Execution grants are single-use, expiring, and revocable. Key rotation and cross-signed snapshots preserve continuity without turning an old grant into a new permission.
Inspect the proof flow →Evidence
Decision and outcome stay separate
A signed authorization receipt records what was allowed. A signed execution outcome records what the destination reported afterward. The verifier keeps those claims distinct.
Verify a record →Coverage
Start with the tools you already use
Capability packs cover GitHub, Slack, Linear, Notion, email, PostgreSQL, and filesystem tools, with the same execution-boundary model underneath.
Review MCP coverage →Identity
Do not trust caller-declared identity
MCP integrations can bind a trusted workload identity at the boundary, so actor context is resolved as an input to the decision rather than accepted from the tool call itself.
See the identity model →Healthcare
RCM failure modes are testable
Reference scenarios cover replay, scope creep, wrong-patient submission, injected codes, and approval interception—with proof bundles and independent verification paths.
Explore healthcare governance →Start with the action that is holding up production.
Choose the boundary you need to resolve. Each path begins with one consequential action and states what Strix can—and cannot—prove about it.
Production security review
Map one blocked action, its effect-producing routes, approval boundary, bypass risks, and evidence requirement.
Evaluate the blocked action →Human approval before action
Define which cases must wait, who may decide, what the approval covers, and where authority is consumed.
Map the approval boundary →Consequential MCP tools
Put a decision boundary in front of the MCP calls routed through Strix and identify alternate paths.
Review one MCP action →Healthcare & revenue cycle
Prior auth, appeals, and ADR response: bound what a clinical or RCM agent may write, and hand the payer or health-system buyer evidence they check themselves.
Start with the RCM action →EU AI Act flags (Articles 12, 14, 28) are derived from cryptographic verification of each record — never asserted. The NIST AI RMF and SOC 2 crosswalk is published at /compliance-map.
For federal and self-hosted buyers: each deployment holds its own signing keys — Strix does not hold customer signing keys. Strix is not currently FedRAMP authorized; authorization is in evaluation.
See it on your own workflow.
Thirty minutes: wrap one action, watch it get allowed, denied, or held — and verify the record yourself before we hang up.
Not ready to book? Write to admin@strixgov.com or call (505) 305-7900. More ways in — including a written-question form — at /contact.
Strix is a product of Velaris Group.