Verifiable by design
Castle is a governance control plane for enterprise AI. Its trust model is built on a simple idea: you should not have to take our word for anything that matters. Binding decisions are deterministic, every material action lands on a hash-chained audit log, and the evidence packet Castle exports can be verified on your own machine with a small standalone tool and no access to Castle at all.
Castle is also independent of the AI platforms it governs. Examiners and counterparties expect attestation independent of the attested; a platform vendor governing its own stack is self-attestation. Castle governs agents built on any stack, including Microsoft's Agent Governance Toolkit, and produces evidence a third party can verify without trusting Castle or the platform.
Security architecture
- Deterministic decision core. Risk tiers, control status, policy decisions, and runtime authorization come from fixed rules over declared facts. No model output ever sets a binding decision, which is also why prompt injection cannot move one.
- Decide at the policy decision point, enforce at the action boundary. Agents ask Castle to authorize before acting: in process via the SDK guard, through the MCP enforcement gateway, via adapters for ARI-compatible runtimes, the OpenAI Agents SDK, and LangChain/LangGraph, or over the REST policy-decision endpoint for anything else. A deny blocks the action before it runs, and the gateway fails closed if the decision service is unreachable.
- Secure by default. The API refuses to start without authentication unless a developer explicitly opts into an insecure local mode. Login and token endpoints are rate limited per IP.
- Supply chain. Dependencies are locked with hashes, audited in CI with a blocking vulnerability gate, scanned for secrets, and shipped with a software bill of materials.
Key management and rotation
Castle ships versioned key management with a provider abstraction. Each cryptographic job has its own key purpose: credential encryption, field-level data encryption, attestation signing, and session signing.
- Managed KMS / HSM. For production, data keys are wrapped by a key encryption key held in Azure Key Vault or Azure Managed HSM, using standard envelope encryption. Key material is generated locally and never leaves the machine in plaintext. AWS KMS, GCP Cloud KMS, and HashiCorp Vault follow the same provider interface and are documented as planned providers.
- Automated rotation policy. A configurable rotation interval flags due keys; rotation is one command. Previous versions are retained, so existing ciphertexts still decrypt and existing signatures still verify after every rotation.
- Auditable rotation. Every rotation appends to a hash-chained rotation log that can be re-verified at any time.
Access controls
- Authenticated, role-based access with separated roles for owner, admin, operator, auditor, and viewer duties.
- Enterprise SSO over OIDC, built for Entra ID and Okta, with SCIM provisioning for joiner and leaver flows.
- Tenant isolation controls and a data-residency allowlist for region-restricted deployments.
- Short-lived session tokens; with key management enabled, session signing keys rotate without logging everyone out.
Audit logging
Every material action, from obligation confirmation to a runtime deny, emits an event onto an append-only, hash-chained log. Each event links to the one before it, so inserting, deleting, or editing any record breaks the chain at that exact point. Verification is a built-in command and is surfaced in the dashboard's trust page, which derives its status live from the install.
Continuous control monitoring
Posture is re-verified on a schedule, not asserted once. castle monitor re-checks event-chain integrity, signing and encryption key rotation age, agent tool use against declared allowlists, and overdue remediation. Results are persisted as run history and stamped onto the audit chain, so the checking is itself evidence. Checks are deterministic reads; no LLM is involved.
Evidence handling
Artifacts are stamped with content hashes when captured, assembled into a Merkle manifest, and exported as a signed attestation packet. A buyer or auditor verifies the packet with the standalone castle-verify tool: signature, root, and every per-artifact hash, with zero access to Castle systems. You can also verify a packet in your browser, where this site runs the same verifier, unmodified, on a WebAssembly Python runtime with nothing installed. An honest limit: a valid signature proves integrity, not that the underlying evidence is complete.
Two optional layers extend the packet. Public evidence anchoring (opt-in, off by default) records the packet's Merkle root in the public Sigstore Rekor transparency log: only hash values are published, never evidence content, and inclusion verifies fully offline. Countersignature receipts let an independent Castle instance re-verify a packet and countersign it, with receipts aggregating into one offline-verifiable Transparent Statement, aligned to the IETF SCITT architecture (draft-ietf-scitt-architecture, in IESG evaluation): the pattern and semantics, not the COSE wire format. Across a delegation chain (carrier, MGA, TPA), obligations delegate down and countersigned evidence rolls up; a counterparty can run a free verification node to countersign incoming evidence, and an oversight report summarizes coverage across the chain.
The integrity format itself is published as an open schema (v0.1, draft) with a conformance test kit and a written RFC change process. Every hash and signature check is specified precisely enough to reimplement and verify independently, so the format is testable rather than proprietary, and verification never requires trusting Castle.
Time-boxed examiner access
For a regulator, carrier auditor, or bank partner, Castle issues a read-only portal grant scoped to one engagement. The link is displayed once and stored only as a hash, the grant expires on its TTL, and expiry or revocation kills live sessions on the next request. Grant creation, revocation, and every access are recorded on the audit chain. The examiner sees live posture, the runtime decision log, exam-readiness views, continuous-check results, and the attestation packet with instructions to verify it independently.
Every vertical pack also ships a self-contained verifier bundle an examiner runs in one command, with zero Castle trust; for insurance, castle insurance examiner-packet assembles that bundle, the exhibits, and a signed attestation into one portable deliverable led by a 00-START-HERE.md verify-first cover sheet. The portal accepts an uploaded packet and verifies it as a convenience, and the authoritative check remains the examiner's own offline run.
AI governance controls
- An AI use case registry with deterministic risk assessment and lifecycle states.
- An agent registry where every governed agent declares the tools, data, and actions it may touch.
- Runtime enforcement: allow and deny decisions before actions execute, with a policy decision log. Hooks run in process, in front of MCP tool servers, around ARI-compatible runtimes, inside OpenAI Agents SDK and LangChain/LangGraph agents, and over the REST policy-decision endpoint for any other stack. The decision is computed on the agent's registered identity and the tool name, and a denied action never runs.
- Human sign-off gates on approvals and obligation confirmation; the model proposes, a person decides.
- Exceptions and remediation: accepted risks are explicit and owned, and every remediation carries an owner and a due date.
First-party model validation
Beyond governing how a model is used, Castle tests whether the model itself behaves. A configurable validation battery runs four deterministic checks against your own models (bias and fairness by disparate impact, grounding quality, robustness under perturbation, and drift by PSI) and emits a typed pass/fail result with metrics for each. Results map to named obligations (NAIC bias testing, SR 11-7 validation, EU AI Act Article 14 human oversight, SOC 2), and each run is stamped write-once and folded into the same signed evidence packet, so it anchors and verifies offline with castle-verify like any other artifact.
The validation engine is a cleanly bounded module behind its own interface, so the same battery can run as a self-contained library without the rest of Castle.
First-party only: Castle helps you validate and document your own models. It is not an independent audit, and a passing battery is evidence of validation work, not a certification.
Govern the guardrails you already run
Model validation proves the model behaves before it ships; content guardrails catch a bad input or output in the moment. When you run a guardrail engine (NeMo Guardrails, Llama Guard, Presidio), Castle ingests each rail decision (jailbreak, toxicity, groundedness, PII, topical) as obligation-mapped, hash-chained evidence, and reconciles the rails you declared you run against the ones that actually fired. A rail you say you run but that never fires shows as a gap; a rail that fires but was never declared shows as drift.
Castle governs and evidences the guardrails. It is the system of record for their decisions, not the guardrail engine, and this is not a third-party audit.
Govern the agent-behavior signals you already collect
The same pattern extends past content rails to the runtime-security tools that watch how an agent behaves. When an agent-identity, intent-drift, or anomaly tool raises a signal, Castle ingests it as obligation-mapped, hash-chained evidence and reconciles the agents you declared against the signals that actually fired: a signal for an undeclared agent is drift, a declared agent no tool reports on is a coverage gap. Castle runs no detector of its own here and makes no allow-or-deny call on a signal's content; it is the system of record for what those tools decided, mapped to the obligation each one answers.
Castle governs and evidences these signals. It does not replace the security tool that produced them, and this is not a third-party audit.
Vendor and model governance
Castle inventories AI vendors and the models behind each use case, tracks vendor posture such as SOC 2 report status and signed data processing agreements, and maps vendor and contract obligations into the same obligation graph the rest of the program runs on. Integration status reflects real connection state; Castle never fakes a live connection.
Data handling
- Sensitive fields, including contract text and personal data, are encrypted at rest with AES-256-GCM; credentials live in an encrypted vault with a memory-hard key derivation.
- Credentials are stripped before anything reaches a model.
- Deployment options: our cloud, your private cloud, or a fully air-gapped install that fails closed rather than reach out.
- Retention windows, report watermarks, and data residency are configurable per workspace.
Compliance alignment
Castle is designed to support evidence-driven compliance programs. It ships regime libraries for insurance AI obligations, including NAIC model bulletin adoptions, NYDFS guidance, Colorado's AI rules for insurers, the EU AI Act, and Texas, Canadian OSFI, and UK PRA guidance, each mapped by analysts and confirmed by a human reviewer in the product.
Castle also ships a jurisdiction-by-jurisdiction record of NAIC AI Model Bulletin adoption status, with source-dated records covering the 24 adopting jurisdictions (23 states plus DC) listed on the NAIC's implementation tracker, status April 1, 2026. A built-in content-currency check ages those records so stale regulatory content surfaces as a warning instead of drifting silently. Kept current to public sources as of the recorded dates; reference material, not legal advice.
Compliance references describe readiness and evidence support, not certification. Castle holds no certifications today, and we will not imply otherwise.
Security review
Running a vendor security review? We will walk your team through the architecture, threat model, and verification flow, and provide deeper materials on request under NDA, including the prompt injection threat model and detailed architecture notes.