Security & Compliance
This is the procurement answer set a platform lead forwards when security or compliance joins the buying motion. It assumes the architectural discussion is already underway and focuses on reviewer questions, evidence, and artifact handling.
If you need the mechanism first, start with How It Works. If you need the reviewer-facing evidence story rather than the procurement checklist, go to AI Audit Trail.
The Procurement Questions This Page Answers
| Question | Current answer |
|---|---|
| Encryption | TLS 1.3 in transit, AES-256-GCM at rest, BYOK with AWS KMS / GCP KMS / Azure Key Vault, and Ed25519 permit signing. |
| Residency | US regions in us-east with us-west DR, EU in eu-west, plus self-hosted deployment in customer VPC or on-prem when required. |
| Retention | Customer-controlled retention; minimum 18 months on SaaS and unlimited retention on self-hosted deployments. |
| SSO / SCIM | SAML 2.0 or OIDC SSO, SCIM 2.0 provisioning, and RBAC scoped by tenant, workload, or policy namespace. |
| SOC 2 status | In audit window for the Q2 2026 report; the report is available under NDA on request once issued. |
Evidence Model
A reviewer receives a scoped export or query result keyed by `permit_id`, not screenshots from four systems. The same record can be queried by tenant, workload, policy version, exception path, or time window.
- Artifact shape — signed permit records plus NDJSON export for downstream review or archive.
- Queryable fields — `permit_id`, tenant, workload, provider, model, `policy_id`, `rule_matched`, and exception path.
- Signed fields — permit identifier, issuance time, subject, request metadata, and the decision block that records what rule allowed or denied execution.
Control Mapping
These mappings help a reviewer place Keel in the control stack. They do not claim that Keel alone satisfies a framework outcome.
| Review trigger | Relevant Keel control |
|---|---|
| SOC 2 or ISO review asks who approved a run under which rule | Permit records carry policy version, matched rule, and exception path before execution starts. |
| Identity review asks how access is provisioned and removed | SSO, SCIM, scoped RBAC, and revocable API tokens govern operator access; administrative actions are themselves queryable. |
| HIPAA or PHI scoping review asks where payload data flows | SDK mode keeps prompt and response bodies in customer infrastructure by default; self-hosted deployment and BAA path exist for PHI workloads. |
| Residency or retention review asks where records live and how long they persist | Region selection, policy-controlled retention, and signed export govern where evidence is stored and how it leaves the system. |
Fail-Closed Posture
For audit-evidence workloads, the meaningful default is fail-closed. If policy evaluation cannot complete, the request does not silently pass through and create an evidence gap that someone has to explain later.
That matters in review because a fail-open path turns evaluator failure into an unverifiable exception. Keel keeps policy evaluation errors fail-closed, and lets teams make any narrower operational tradeoff explicitly at the workload level rather than by accident.
NDA Artifact Request Path
Email security@keelapi.com with the customer name, requested artifact set, and deadline. The standard package is the SOC 2 report when available, penetration-test summary, SIG Lite or CAIQ responses, DPA, insurance certificates, architecture diagram, and BAA template when relevant.
Most requests return within one business day. If the reviewer needs the operating model alongside the answer set, forward How It Works with the artifact request instead of rewriting the system explanation in email.