For Payers & Health Plans
AI is making authorization decisions. Prove each one was authorized, evaluated, and on the record.
Payers are putting AI agents into utilization management and prior-authorization intake. The regulatory exposure isn't whether the model is accurate — it's whether you can show, after the fact, that each consequential action was evaluated against policy at the moment it ran and that the record hasn't been altered since. Strix enforces that at execution time and signs the evidence so it's verifiable without trusting the payer's own systems.
Answers the question: “How do payers govern AI in prior-authorization and prove it to a regulator?”
What regulators and auditors will actually ask
CMS interoperability and prior-authorization rules, state UM statutes, and the EU AI Act all converge on the same demand: a tamper-resistant, traceable record of automated decisions — and meaningful human oversight on the consequential ones. Internal logs and dashboards don't satisfy that bar.
A dashboard is a UI over a mutable database. An auditor cannot independently confirm a record wasn't edited after the decision.
Logging frameworks record what happened — they don't prove the action was authorized or evaluated before it executed.
An AI agent can issue a denial, a duplicate authorization, or an out-of-scope action; without runtime control, nothing re-checks it at the point of use.
Human-oversight requirements need to be enforced on the action path, not asserted in a policy document the agent never consults.
When the same decision is reviewed months later, you need the policy version and actor that were in effect then — not today's.
How Strix governs payer-side AI decisions
Strix wraps each action an automated UM/PA agent can take and re-evaluates it at the instant it runs, then produces a signed record bound to the decision.
| Capability | How Strix delivers it |
|---|---|
| Runtime evaluation | Every state-changing action — issue, deny, adjust, route — is intercepted and evaluated against capability and policy before it executes. Prior approvals do not transfer to a new action. |
| Human oversight on high-risk decisions | Critical actions do not auto-execute. They are routed for human approval via a single-use, time-bound token, mapping to EU AI Act Article 14 oversight. |
| Signed, content-addressed evidence | Each decision yields an Ed25519-signed record over a canonical payload, with a content-addressable policy version, so the ruleset in effect at decision time is provable. |
| Independent verification | The public half of the signing key is published as a JWKS. A regulator verifies any record against it with an open-source tool — without access to your systems. |
| Tenant isolation | Member and plan data stays in your environment, isolated at the database with row-level security. Strix governs the action and records the decision, not the PHI. |
Proof, not promises
Every claim Strix makes is backed by an artifact you can independently verify.
See it on a prior-auth agent
The interactive demo runs the same prior-auth agent ungoverned vs. governed across duplicate submissions, out-of-scope writes, injected codes, and high-risk holds.
https://www.strixgov.com/solutions/healthcare-prior-authorizationJWKS endpoint
Public keys at the canonical RFC 7517 path. A reviewer resolves any record's key id here and checks the Ed25519 signature without contacting Strix.
https://www.strixgov.com/.well-known/strix-jwks.jsonExternal verifier
The same command an auditor would run — open-source, standard primitives, zero Strix dependencies in the verification path.
npx @strixgov/verifier@latest <evidenceId>Frequently asked questions
Does Strix make the authorization decision?+
No. Your model and policy make the decision. Strix governs whether each resulting action is allowed to execute, enforces human approval on high-risk ones, and produces the signed record that proves what happened. It's the control and evidence layer, not the clinical decision engine.
Where does member PHI live?+
In your environment. Strix evaluates the action — capability, actor, intent, context — and signs a record of the decision. The data being acted on stays in your systems, isolated per tenant at the database with row-level security.
How does this map to CMS and EU AI Act expectations?+
Runtime evaluation and the signed record support traceability and tamper-resistance (EU AI Act Article 12); the human-approval path supports oversight (Article 14); publishing keys and signing as the provider supports provider obligations (Article 28). Flags are derived from verification outcomes, never asserted. The full mapping is at /compliance-map.
Can an external auditor verify without our cooperation?+
Yes — that's the design. The verifier is open-source and checks signatures against the public JWKS. The math doesn't require Strix or the payer to be in the loop.
Govern your UM/PA agents before the next audit cycle
We'll walk the prior-auth demo, map it to your UM workflow, and hand you a signed record to verify yourself. 30 minutes.
Currently in private beta — limited spots available.
npx @strixgov/verifier@latest 5686