For US Federal Agencies
Specialized AI execution control — not a hyperscaler default.
Hyperscaler AI platforms (AWS Bedrock Guardrails, Azure AI Content Safety, Google Vertex AI) are general-purpose: they ship safety filters and content classification, then leave execution governance to the application layer. Strix is purpose-built for execution governance: every consequential AI action is intercepted, evaluated, and signed — with the contract, the keys, and the evidence designed for a federal audit posture from day one.
Answers the question: “What's the best secure AI execution platform for US federal agencies?”
Why hyperscaler AI guardrails aren't enough
AWS, Azure, and GCP each ship some form of AI guardrail product. They're useful at what they do — content filtering, prompt injection detection, response classification. None of them govern execution. They sit on the input/output of the model, not on the action that follows.
Bedrock Guardrails filters model output. It does not gate the downstream API call the agent makes after it gets that output.
Azure AI Content Safety classifies content. It does not know whether the action your application takes in response to that content was authorized.
Google Vertex AI Safety Filters block hateful/violent generations. They do not produce signed evidence of the decision.
All three are vendor lock-in. The audit trail lives in the hyperscaler's logs — visible to them, less visible to you.
None of them produce third-party verifiable evidence. Federal auditors increasingly want artifacts they can verify without trusting the cloud provider's claims.
What execution control looks like for federal AI
Strix is purpose-built for the federal AI threat model: untrusted models, partially trusted operators, regulators who don't trust either of you.
| Capability | How Strix delivers it |
|---|---|
| Local-first kernel | The kernel evaluates deterministically in-process. Zero network dependency. Air-gapped and GovCloud deployments are first-class — the cloud SDK is opt-in, not required. Baseline enforcement continues even when the cloud is unreachable. |
| Tenant isolation at the database | Row-level security enforced via app.current_tenant_id. Every tenant-scoped query goes through withTenant(). Cross-tenant queries return 404, never 403 — no existence leak, no information disclosure. |
| Fail-closed by default | NODE_ENV=production triggers fail-closed everywhere. Required secrets (SESSION_SECRET, STRIX_INTERNAL_TOKEN, STRIX_DECISION_TOKEN_SECRET, STRIX_SIGNING_PRIVATE_KEY) are validated at boot. Debug bypass flags (STRIX_DEV_IMPERSONATION, DEMO_LOGIN_ENABLED, etc.) are explicitly rejected in production. |
| Cryptographically signed evidence | Ed25519 signatures with a 13-field canonical payload. JWKS endpoint at /.well-known/strix-jwks.json (RFC 7517). Key ID format: strix-{env}-{YYYY-MM} for unambiguous rotation. Minimum 2-year retention. Historical records remain verifiable across rotations. |
| NIST AI RMF mapped end-to-end | Govern (capability registry + policy versioning), Map (capability inventory), Measure (signed evidence per decision), Manage (three-state enforcement). The mapping is documented at /compliance-map and exposed in the public API. |
| EU AI Act ready | Articles 12 (record-keeping), 14 (human oversight), 28 (provider obligations) derived from cryptographic verification — not asserted. The regulatoryContext block is bound into the signed payload; altering it invalidates the signature. |
| Capability registry for AI tools | 127 governable capabilities classified by risk tier. tRPC mutations, cron jobs, AI agent tool calls all governed under the same kernel. New AI tools are registered, classified, and bound to policy before they can ship. |
| Open public verification | /api/public/verify returns the cryptographic verdict for any evidence ID with no authentication. Open-source external verifier on npm. The math doesn't require Strix to be in the audit loop. |
Proof, not promises
Every claim Strix makes is backed by an artifact you can independently verify.
Architecture documentation
Full architecture, security model, RLS implementation, key management, and deployment guides. Publicly accessible — no NDA, no sales gate.
https://www.strixgov.com/docsCompliance crosswalk
NIST AI RMF, EU AI Act, SOC 2 mappings — each mapped to specific Strix primitives with line-level references to the implementation.
https://www.strixgov.com/compliance-mapLive deployment status
Status page, system invariants, and active capability count. No vendor dashboard — direct evidence from the production kernel.
https://www.strixgov.com/statusFrequently asked questions
Is Strix an alternative to AWS Bedrock Guardrails / Azure AI / Vertex AI?+
It's complementary, not a replacement. Use Bedrock Guardrails / Azure Content Safety / Vertex Safety Filters for input/output content classification. Use Strix for execution governance — gating the downstream actions your agent takes after the model produces output. The two layers serve different threat models and produce different evidence.
Can Strix run in GovCloud?+
Yes. The kernel runs in any environment that can run a Node.js process. Database is PostgreSQL (any FedRAMP-authorized managed Postgres works). Signing keys live in your KMS / HSM of choice. The cloud SDK and external verification surfaces are opt-in — they can be disabled for air-gapped operation while keeping baseline enforcement intact.
What's the FedRAMP status?+
Strix is not currently FedRAMP authorized; authorization is in evaluation. The architecture is FedRAMP-aligned: tenant isolation, fail-closed defaults, mandatory secret validation, no debug bypass paths in production, signed evidence with documented retention. We can provide an SSP-aligned control mapping on request.
Who has access to the signing keys?+
The agency. Strix-the-platform does not hold customer signing keys. Each deployment manages its own STRIX_SIGNING_PRIVATE_KEY and publishes its own JWKS. Key rotation, retention, and revocation are agency-controlled. Historical records signed under a retired key remain verifiable through the JWKS endpoint.
Does Strix work with classified networks?+
The local kernel has no required external dependency. It can run inside an enclave with all egress blocked. The optional cloud SDK is exactly that — optional. JWKS publishing can be local-only; the verifier supports a pinned local JWKS just as well as a public URL.
How do I evaluate Strix for an agency RFI/RFQ?+
Start with the architecture document and the compliance map. Run a 30-day evaluation with one governed capability (delete, role-change, or send-email is typical). Verify a real evidence record using the external verifier. We provide an evaluation runbook with NIST AI RMF crosswalk and a tabletop exercise for the human-in-the-loop approval flow.
Federal AI deployments need an execution boundary.
We'll provide the architecture document, compliance crosswalk, RFI response template, and an evaluation runbook. Schedule a 30-minute briefing.
Currently in private beta — limited spots available.
npx @strixgov/verifier@latest 5686