For Healthcare & Revenue Cycle
Your AI agent submits prior auths. Strix decides whether each submission is allowed to leave.
AI agents are moving from drafting prior-authorization requests to actually submitting and following up on them. The moment they act, a wrong, duplicated, or out-of-scope X12 278 stops being a draft and becomes a real transaction with a payer. Strix evaluates each action at the instant it runs, blocks the ones that veer, and records an Ed25519-signed evidence record a reviewer can verify independently — no Strix tooling required.
Answers the question: “How do you keep an AI prior-authorization agent from submitting the wrong request?”
What goes wrong when an agent submits prior auths on its own
These are not contrived bugs. They are the failure modes that show up the moment a prior-auth agent stops drafting and starts acting — each one a real transaction that a payer, a patient account, or an auditor then has to unwind.
Duplicate submission — a retry or replay fires the same 278 twice. The payer sees two authorization requests, and the duplicate triggers dedup or recoupment review downstream.
Out-of-scope action — the agent was approved to submit a prior auth, but also posts an unauthorized adjustment or write-off on the member account. Nobody authorized that action; it still executed.
Injected instruction — a malformed inbound note injects the wrong CPT code. The agent authorizes the wrong procedure, and the request looks completely valid on the wire.
Logs record what happened after the fact — they do not stop the submission. By the time the wrong 278 is in the log, it is already at the payer.
An approval in a ticketing system lives outside the submission path. Any caller with the right API can submit without it ever being checked.
Does this happen on your stack?
Four questions about what your prior-auth agent does the moment it acts on its own. The gaps you flag are exactly what the demo below shows being stopped.
If your AI agent's run is retried, can it submit the same prior authorization (278) to the payer twice?
If the agent decides to also post an adjustment or write-off it was never asked to make, does anything stop it before it lands?
If an inbound note or portal message contains text the model treats as an instruction (e.g. a different CPT code), can it change what actually gets submitted?
When the agent hits a high-cost, high-risk submission, is it held for a human — or does it just fire?
See it run — same agent, governed vs. ungoverned
The same AI prior-authorization agent, run twice on an identical request. Pick a scenario: the left column is the agent with policy and guardrails only, the right is the same agent with Strix evaluating each action at the moment it executes.
Submit one prior authorization (X12 278) for CPT 70553 for Avery Sampleton to Test Health Plan.
- The agent completes the submission, then its run is retried (timeout/orchestration replay).
- Both attempts carry identical business content with fresh X12 control numbers.
Payer endpoint: Test Health Plan (SYNTHETIC, in-process) · synthetic data only
UNGOVERNED
policy + guardrails only
submitPriorAuthSubmit X12 278 prior auth — CPT 70553 (MRI brain without and with contrast) for Avery Sampleton
Prior authorization accepted: AUTH-000001
submitPriorAuthSubmit X12 278 prior auth — CPT 70553 (MRI brain without and with contrast) for Avery Sampleton
Second identical authorization request received.
GOVERNED
Strix execution gate
submitPriorAuthSubmit X12 278 prior auth — CPT 70553 (MRI brain without and with contrast) for Avery Sampleton
Action matched an approved decision and was admitted at execution time.
Prior authorization accepted: AUTH-000001
submitPriorAuthSubmit X12 278 prior auth — CPT 70553 (MRI brain without and with contrast) for Avery Sampleton
This action was already executed once. Authorization is single-use; the duplicate cannot redeem.
Same agent · same task · same payer. The only difference is whether each action is re-evaluated at the moment it executes. Evidence IDs and signatures shown are illustrative captures from the local demo (which signs with an HMAC stand-in); production records are Ed25519-signed and verify against the public JWKS with @strixgov/verifier.
What Strix does on every prior-auth action
Strix wraps the actions a prior-auth agent can take. Each one is evaluated at the moment of execution against the intent that was actually approved — not against a plan made earlier. The demo below runs the identical agent twice so the difference is visible side by side.
| Capability | How Strix delivers it |
|---|---|
| DENY — duplicate 278 | Submission carries a content hash and intent binding. A second identical 278 is blocked as a REPLAY because approval tokens are single-use — the authority to submit is spent the first time it runs. |
| DENY — out-of-scope write-off | The agent had a token to submit a prior auth, not to post a $1,250 write-off. The adjustment is blocked as UNAUTHORIZED — there is no token for that action, and prior approvals do not transfer to it. |
| DENY — injected CPT code | The action that runs is compared to the action that was approved. When an injected note changes the CPT, the submission diverges from the approved intent and is blocked as SCOPE_MISMATCH before it reaches the payer. |
| INTERCEPT — high-risk submission | High-risk and critical actions do not auto-execute. They are routed for human approval first, issued as a single-use, time-bound token. The action runs once, then the authority is spent. |
| RECORD — signed evidence | Every governed action — allowed or denied — produces an Ed25519-signed evidence record binding the actor, the action, and the decision. The record is append-only and carries the deny reason when an action is blocked. |
| VERIFY — by the reviewer, not by us | A compliance reviewer or auditor checks the signed record themselves against the public JWKS using a standard verifier. The verdict comes from the cryptography, not from a Strix dashboard. |
Proof, not promises
Every claim Strix makes is backed by an artifact you can independently verify.
Verify a real record — right now
Production evidence record 5686, re-checked live in your browser against the public verification API.
Don't take our word for it — run the same check
npx @strixgov/verifier@latest 5686Open-source verifier, standard Ed25519 + JWKS primitives, zero Strix dependencies. The signature is checked against the public keys at /.well-known/strix-jwks.json— the math doesn't require us to be in the loop.
Same agent, governed vs. ungoverned
The side-by-side demo above replays captured runs of the same prior-auth agent on real X12 278 — once with policy and guardrails only, once governed by Strix. The runs are reproducible end to end; synthetic patients and a mock payer only — it never touches a live payer, clearinghouse, or EHR.
Security-review proof pack
A one-page, printable summary for your security and compliance reviewers — the verifiable artifact, the verify command, what Strix governs, and the EU AI Act / HIPAA / NIST AI RMF mapping. Save it as a PDF from the page.
https://www.strixgov.com/solutions/healthcare-prior-authorization/proof-packJWKS endpoint
The public half of the signing key, served at the canonical RFC 7517 path. A reviewer resolves any record's key ID here and checks the signature without contacting Strix.
https://www.strixgov.com/.well-known/strix-jwks.jsonExternal verifier
The same command a compliance reviewer would run. Open-source, npm-installable, standard Ed25519 + JWKS primitives — zero Strix dependencies in the verification path.
npx @strixgov/verifier@latest <evidenceId>Frequently asked questions
Does the demo touch a real payer or any PHI?+
No. The demo runs against synthetic, Synthea-shaped patients and a mock payer that we own. There is no production target in the code, and it never connects to a live payer, clearinghouse, or EHR. The X12 278 transactions are real in structure but carry no protected health information.
Is this a different product from the rest of Strix?+
No. This is the same execution-control layer applied to a prior-auth workflow. The underlying primitives — capability registry, three-state decisions (allow/deny/intercept), single-use execution tokens, and signed evidence — are identical to every other Strix deployment. The prior-auth scenarios are a concrete framing, not a separate product.
Where does the patient and claim data live?+
In your environment. Strix governs the action — the capability, the actor, the intent, and the context — and produces a signed evidence record of the decision. The data the agent acts on stays in your systems. Tenant data is isolated at the database with row-level security; cross-tenant reads return nothing.
What does 'evaluated at execution time' actually mean here?+
Each action is re-evaluated at the moment the agent tries to run it, against the intent that was approved for that specific action. A prior approval to submit one request does not authorize a second submission, a different procedure, or an unrelated write-off. This is why a duplicate, an injected CPT, and an out-of-scope adjustment are each caught even though the agent 'meant' to proceed.
How would my compliance team verify a record?+
They run the external verifier against the evidence ID and get a cryptographic verdict — verified or not — without going through a Strix UI. The verifier fetches the public key from the JWKS endpoint and checks the Ed25519 signature over the canonical payload. The point of the design is that they check it themselves; they do not take our word for it.
Can we pilot this on one of our own agent workflows?+
Yes — that is the design-partner offer. We scope a pilot on a single prior-auth or revenue-cycle workflow you already run, set it up white-glove, and time-box it to a few weeks to answer one question: did it prevent a real mistake in your environment. Use Book a Demo to start the conversation.
See the prior-auth agent get stopped — on your workflow
We'll walk the three scenarios live, then hand you a signed record to verify on your own machine. 30 minutes, founder-led.
Currently in private beta — limited spots available.
npx @strixgov/verifier@latest 5686