For US Government Contractors
AI policy enforcement that holds up to a federal audit — on the record, signed, verifiable.
Federal contractors deploying AI face a record-keeping problem that audit logs cannot solve. Strix produces Ed25519-signed evidence on every governed action, mapped directly to NIST AI RMF, EU AI Act Articles 12, 14, and 28, and SOC 2 audit trails — verifiable by any third party, including your auditor, your customer's auditor, and the regulator.
Answers the question: “How do federal contractors enforce AI policy and prove compliance?”
What federal AI procurement actually requires
GSA, DoD, and civilian agencies are converging on a shared expectation: AI systems must produce tamper-resistant, third-party verifiable records of every consequential decision. Internal logs, screenshots, and 'we'll show you our dashboard' do not satisfy this requirement.
Vendor-provided dashboards are not evidence — they're a UI on top of a mutable database. An auditor cannot independently verify them.
Logging frameworks (Datadog, Splunk, CloudWatch) record what happened. They don't prove the action was authorized, evaluated, or approved.
Approval workflows in ticketing systems (Jira, ServiceNow) live outside the execution path. Any caller with the right API can bypass them.
Most 'AI governance' platforms are policy authoring tools — they help write rules. They don't enforce the rules at the moment of execution.
EU AI Act Article 12 requires automatic logging of high-risk AI systems with retention sufficient for traceability. Article 28 puts the burden on the provider, not the deployer.
How Strix maps to federal AI requirements
Each requirement maps to a specific Strix primitive. The mapping is documented, tested, and exposed at /compliance-map.
| Capability | How Strix delivers it |
|---|---|
| NIST AI RMF — Govern (GV) | Capability registry assigns risk tier (Critical/High/Medium/Low) to every AI-callable action. Policy versions are content-addressable (sha256 hash) — you can prove which policy ruleset was in effect at any point in time. |
| NIST AI RMF — Map (MP) | Every AI-callable capability is registered, classified, and bound to its risk profile. The 127-capability registry is enumerable via /api/v1/capabilities — auditors get a complete inventory in one call. |
| NIST AI RMF — Measure (MS) | Every governed action produces a signed evidence record. /api/public/stats exposes aggregate counts (total decisions, denial rate, approval rate, capability distribution) without exposing tenant data. |
| NIST AI RMF — Manage (MG) | Three-state decisions (ALLOW/DENY/INTERCEPT). High-risk and critical actions require human approval before execution. Single-use tokens with revocation. No bypass paths. |
| EU AI Act Article 12 (record-keeping) | Tamper-resistant logging is derived from cryptographic verification: hashValid AND chainValid AND signatureValid. The flag is computed from the math, not asserted by the application. |
| EU AI Act Article 14 (human oversight) | Actor identity is bound into the signed payload. Critical and High-risk actions require explicit human approval issued via a single-use execution token. Self-approval is blocked at the policy level. |
| EU AI Act Article 28 (provider obligations) | Strix as the provider signs every evidence record with a key whose public half is published at /.well-known/strix-jwks.json. Auditors verify against the JWKS — they don't take Strix's word for it. |
| SOC 2 — Trust Services Criteria | CC7.2 (system monitoring), CC7.3 (incident response evidence), CC8.1 (change management evidence), and CC9.1 (risk mitigation evidence) all map to the same signed evidence record. One artifact, multiple criteria. |
Proof, not promises
Every claim Strix makes is backed by an artifact you can independently verify.
JWKS endpoint
Public keys served at the canonical RFC 7517 path. Includes contractVersion 2, retentionPolicy metadata, and X-Strix-Contract-Version header for client-side version pinning.
https://www.strixgov.com/.well-known/strix-jwks.jsonCompliance mapping (live)
Every NIST AI RMF function and EU AI Act article mapped to the specific Strix primitive that satisfies it. Cross-references the architecture documentation. Public, no auth required.
https://www.strixgov.com/compliance-mapExternal verifier
Identical to what a federal auditor would run. Zero Strix dependencies — open-source, npm-installable, uses standard Ed25519 + JWKS primitives.
npx @strixgov/verifier@1.9.0 quorum <decisionId>Frequently asked questions
Is Strix FedRAMP authorized?+
Strix is not currently FedRAMP authorized. Authorization is in evaluation. The architecture is designed to be FedRAMP-compliant: tenant isolation via row-level security, fail-closed defaults in production, mandatory secret validation, no debug bypass paths in production. We can provide the SSP-aligned control mapping on request.
How does Strix handle classified or CUI-marked data?+
Strix governs the action — capability, actor, intent, context — and produces a signed evidence record. The data being acted on stays in your tenant's database and never leaves your environment. Tenant scoping is enforced at the database (RLS) using app.current_tenant_id; cross-tenant queries return 404, never 403.
What's the retention policy on signed evidence?+
Minimum 2 years for the signing key (EU AI Act compliance baseline). Evidence records are append-only and cannot be modified or deleted. Historical records remain verifiable through key rotation — the JWKS endpoint resolves any kid (key ID) to its public half. Records signed under retired keys verify exactly as they did under the active key.
Can the regulator audit Strix without our cooperation?+
Yes — that's the design intent. The public verification API (/api/public/verify) accepts any evidence ID and returns the cryptographic verdict without authentication. The external verifier is on npm and uses standard cryptographic primitives. The math doesn't require us to be in the loop.
How does this compare to Microsoft Purview / Azure AI Content Safety?+
Microsoft Purview is a data governance and content safety platform — it inspects content for policy violations and provides classification, labeling, and DLP. Strix is the execution control layer — it enforces what an AI agent can do at the moment it tries to do it, and produces signed evidence. The two are complementary; Purview answers 'is this content allowed,' Strix answers 'should this action execute.'
Does Strix support air-gapped or GovCloud deployments?+
The kernel evaluates deterministically in-process with zero network dependency. The optional cloud SDK adds dynamic rules but is opt-in. JWKS publishing and evidence verification work entirely from a local key store. GovCloud and air-gapped deployment paths are documented; contact us for the deployment guide.
Ready to take Strix to your contracting officer?
We'll provide the architecture document, NIST AI RMF crosswalk, EU AI Act compliance mapping, and a live evidence-verification demo. 30 minutes.
Currently in private beta — limited spots available.
npx @strixgov/verifier@latest 5686