Security & Trust
Security architecture your counsel will actually sign off on.
Primary data on-premises. Backups encrypted client-side before they leave the building. Row-level security enforced at the database — not the application layer. Zero third-party plaintext access. SOC 2 Type I: targeting Oct 15, 2026; not yet certified — auditable from the first request.
The security properties described here are structural — enforced at the database and infrastructure layer, not the application layer. A misconfigured service, a compromised credential, or a runtime error cannot bypass them.
Availability — grāmatr Cloud is available now. Private cloud and on-premises are committed for September 1, 2026; the fully air-gapped variant for January 1, 2027. SOC 2 Type I is targeting October 15, 2026 — grāmatr does not claim certification it does not yet hold.
On-premises primary storage. No AWS. No GCP. No Azure.
Customer data lives on gramatr-owned, on-premises hardware. We are not a tenant in a hyperscaler's infrastructure. On multi-tenant grāmatr Cloud, tenants are isolated at the database row level — never commingled in shared cloud storage.
No third-party plaintext access.
Database backups leave the building encrypted client-side (AES-256 via pgBackRest) before they reach offsite storage (Cloudflare R2). Cloudflare stores ciphertext only — they cannot read your data. Encryption keys are managed in a self-hosted secrets manager using a zero-knowledge architecture: the secrets management layer cannot read the plaintext keys. Access tokens are themselves encrypted at rest.
Encrypted in transit.
All API traffic routes through Cloudflare Tunnel — metadata routing only, no stored data. TLS enforced everywhere.
Row-level security.
Database access is enforced at the row level, not the application layer. A misconfigured service cannot leak another tenant's data.
Tiered governance.
Intelligence is scoped by tier — system, enterprise, team, user, project — with row-level security enforced at the database level.
Actor identity on every request.
grāmatr records not just what was requested but who requested it — the authenticated actor is identified and logged before any model responds. Every audit record carries actor identity, not just activity. This is the first question a regulator or auditor asks; it is the first thing grāmatr answers.
Least-privilege access.
Operator access to production is limited, logged, and audited. No shared credentials.
Patent-pending pre-classification routing.
Sensitive requests are classified and routed before any expensive model sees them, reducing exposure surface by design.
The request path, and where isolation is enforced
Every request follows the same path. The two boundaries that matter to your security and counsel teams — the deployment perimeter you control, and tenant isolation at the database row — are structural, drawn here explicitly.
grāmatr Cloud · your private cloud · on-premises · air-gapped. The entire layer below moves to the infrastructure you choose.
Enforced at the database, not the application layer. A misconfigured service or compromised credential cannot read another tenant's rows.
Fail-open: if the grāmatr layer is ever unreachable, requests pass through to the model unmodified — degraded classification, not an outage.
Your data is yours. Exportable on demand. Deleted on cancellation.
Your data is yours
You own the content you submit to grāmatr. We do not sell it, rent it, or share it with advertisers.
Export on demand
Enterprise customers can export their organization's directives, skill definitions, and governance records at any time.
Deletion on cancellation
Upon cancellation, a full export is provided. After export confirmation, all customer data is permanently deleted from grāmatr systems within 30 days. A certificate of deletion is available on request.
Clean deletion
When you delete, your data is permanently removed — intelligence configurations, observations, and embeddings.
Where regulated workloads run.
grāmatr Cloud does not process PHI and is not available for EU data residency. PHI-covered and EU-region workloads run on private cloud or on-premises only — infrastructure you own and control. Can PHI leave your network? On private cloud and on-premises, no: you define the boundary, and grāmatr is never a party to the BAA.
| Deployment | PHI / BAA | EU data residency |
|---|---|---|
| grāmatr Cloud — available now | Not supported. grāmatr does not process PHI on its cloud infrastructure. | Not supported. |
| Private Cloud — committed Sept 1, 2026 | Customer-controlled. The BAA is executed by the party operating the deployment — a BAA path is available. | Customer-controlled. Deploy in your home region. |
| On-Premises — committed Sept 1, 2026 (connected); Jan 1, 2027 (air-gapped) | Customer-controlled. The BAA is executed by the party operating the deployment — a BAA path is available. | Customer-controlled. Deploy in your own data center. |
On-premises primary. Encrypted offsite. GitOps-managed.
On-premises primary storage
Primary database runs on gramatr-owned hardware. No hyperscaler primary storage.
Client-side encrypted offsite backups
pgBackRest encrypts backup streams (AES-256) before transmission to Cloudflare R2. R2 stores ciphertext only — no third party can read backup data.
Zero-knowledge key management
Encryption keys stored in a self-hosted secrets manager (zero-knowledge architecture). The secrets management layer cannot access plaintext keys. Access tokens encrypted at rest.
API traffic via Cloudflare Tunnel
Metadata routing only. No stored data at the edge.
Kubernetes-deployed with GitOps automation
Every production change flows through a reviewed, versioned, auditable pipeline.
Immutable builds, tagged releases
Every deployment corresponds to a signed, tagged release in source control.
Two distinct surfaces. One for SOC 2. One for the EU AI Act.
Infrastructure audit log — SOC 2 evidence stream
Every action in grāmatr infrastructure — by human operators or automated agents — is written to a tamper-resistant, append-only ClickHouse log.
- INSERT-only credentials — no UPDATE or DELETE permissions on the audit writer role
- Each record captures actor identity, resource, action, outcome, and a structured JSON metadata block linking the event to its change ticket and execution ID
- Retained 2 years in hot storage, 7 years in cold archive
- Queryable via ClickHouse SQL (JSON, CSV, or Parquet) or the compliance events REST API
Platform intelligence telemetry — AI Act transparency layer
Every AI interaction generates a per-request telemetry record capturing:
- Actor identity
- Intent classification
- Model selected
- Directives applied
- Quality gate criteria set
- Quality gate verdict with evidence
- Token consumption
- Cost
This is the audit surface that supports EU AI Act Article 13 transparency requirements. Full LLM observability via an integrated, self-hosted observability layer gives enterprise administrators per-request financial and governance attribution across every model in their deployment.
| Record type | Retention | Notes |
|---|---|---|
| Pure telemetry metrics | 2-year hot / 7-year cold | Same retention as the infrastructure log |
| Governance audit trail — per-request classification, directives, gate verdict, and cost | 2-year hot / 7-year cold | Exceeds the EU AI Act's six-month minimum log floor by design; customer-accessible export API |
| Session content — context delivered and interaction payload | 60 days by default, configurable to your application's needs | Held separately and minimized; preserves GDPR data minimization |
On-premises and private cloud deployments extend audit-trail retention for MiFID II, DORA, and EU AI Act requirements.
Fail-open first. Then a four-tier response.
grāmatr is built to fail open. If the classification layer is ever unreachable, requests pass through to the underlying model unmodified — so the business impact at hour one is degraded classification, not a system outage. Your AI workflow keeps running while we respond. Our process is a four-tier commitment, measured from confirmed detection.
Detection — within the first hour
An automated alert reaches our monitored security inbox and severity is confirmed. We verify that fail-open is active — requests are passing through unmodified — and identify affected tenants through the row-level-security audit trail.
Notification — targets within 4 hours
The status page is updated, and affected enterprise customers, along with any relevant partners, are notified. grāmatr targets notification within four hours of confirmed detection.
Resolution — targets within 24 hours
Resolution is confirmed and root cause identified. grāmatr targets resolution within 24 hours of confirmed detection.
Written report — within 3 business days
A formal incident report — timeline, root cause, remediation, and prevention measures — is delivered within three business days.
Report a security concern at any time to [email protected]. The inbox is monitored around the clock.
Where we stand today. Where we are headed.
SOC 2 Type I
Targeting Oct 15, 2026Compliance program runs as code from a versioned repository — every control mapping, every evidence link, every policy change tracked through pull requests. Architecture was designed to meet SOC 2 criteria from day one.
SOC 2 Type II
Targeting Apr 15, 2027Data collection begins following Type I completion. Full evidence pack available for enterprise due diligence under NDA.
NIST AI RMF
Full mappingAll four functions — Govern, Map, Measure, Manage — documented and mapped to grāmatr architecture. Available for enterprise review on request.
HIPAA
Private cloud / on-premBAA-covered workloads run on private cloud or on-premises only — infrastructure you control. The BAA is executed by the party operating the deployment; grāmatr does not process PHI on its cloud infrastructure and is never a party to the BAA. Row-level security, encryption at rest, and actor-logged audit trails are in place across all deployments.
GDPR / CCPA
See Privacy PolicyLawful bases for processing, data-subject rights, retention periods, and standard contractual clauses for international transfers are documented in the Privacy Policy.
Data residency
Missouri, USA · EU/UK on-prem availablePrimary data for hosted deployments is stored on gramatr-owned, on-premises infrastructure in Missouri, USA. EU, UK, and country-scoped deployments are supported via on-premises or private cloud deployment in the customer's jurisdiction.
We do not claim certifications we do not hold. Current status and target dates are available under NDA — contact [email protected].
Contact [email protected] to request under NDA.
If you find something, tell us.
If you are a security researcher and believe you have discovered a vulnerability in grāmatr or this website, email [email protected] with:
- A clear description of the issue
- Steps to reproduce
- Any proof-of-concept code or screenshots
- Your name or handle for credit (optional)
Our commitment:
- Acknowledge reports within three business days
- Investigate in good faith and keep you informed as we remediate
- No legal action against researchers who act in good faith, avoid privacy violations and service disruption, and give us a reasonable opportunity to fix issues before disclosure
The security architecture is built. The evidence is verifiable.
If your procurement, legal, or security team needs to verify what grāmatr's security actually covers — we will walk you through it.
Review AI governance architecture, the underlying science, or enterprise deployment.