Zero-trust applied to every AI agent. Cryptographic compartmentalization at the kernel. Audit by default — tamper-evident, queryable, evidence-on-demand. Post-quantum-ready cryptographic substrate. Compliance becomes a query, not a project.
Most AI platforms add security on top of an architecture that wasn't designed for it. Meridian was built underneath the security model, not above it. Three commitments hold the rest of this page together.
The substrate runs the system. The model is invoked when cognitive resolution is needed — never to decide what mutates state. The model's output is data, validated by the substrate before it can affect anything.
Every routing decision, every effect declaration, every approval gate is structural. Not a check that can be bypassed. Not a guideline embedded in a prompt. A property of the substrate that the model cannot reach across.
Every state transition is recorded into one tamper-evident substrate. Compliance evidence is the system's natural output, not a separately-maintained log pipeline. The recording predates the audit request.
Zero-trust is not a feature in Meridian. It is the constitution. We adopted the seven pillars of the modern zero-trust model — and applied them not just to network connections but to every operation the system performs, including AI agents acting on your data.
Every action is authenticated and authorized at the moment of execution. Identity context is required to read, write, or invoke. There is no "trusted path" inside the system.
Each capability is granted exactly the permissions its task requires. An executive that reviews invoices cannot read employee health records. An automation that scans cloud configurations cannot send customer email.
Credentials are issued at the start of an operation and revoked when the operation completes. Standing privileges are eliminated wherever the just-in-time pattern is feasible.
Every component is designed as if any other component might already be compromised. Failures are contained, not propagated.
Anything not specifically granted is refused. Permission errors fail closed; missing context fails closed; ambiguity fails closed.
Network location does not grant access. The deciding question is always who is asking, not where is the request coming from.
Authorization is re-evaluated throughout an operation, not just at the start. Long-running work is audited as it runs.
Every state transition the system performs is recorded into an append-only audit substrate. The substrate is the same one that runs the business. There is no separate audit pipeline that could fall out of sync, miss an event, or be tampered with after the fact. Evidence is not generated by an export — it is the system's natural output.
Meridian is engineered to support the controls required by major compliance frameworks. We pursue formal audits and certifications as customer engagements require them. We do not claim attestations we do not hold, and we do not commit to audit timelines outside a procurement conversation.
When you bring a framework requirement to a procurement conversation, we engage on a real timeline. Not a marketing claim.
Multi-tenancy in most platforms means we filter your data from other customers' data using a column. The column has a value, the value has to be set correctly, and the filter has to run on every query. Three things have to go right. They don't always.
Meridian's tenant boundary is enforced underneath the application layer. The kernel — not the application code — injects tenant identity into every read and every write. A tenant-missing query is rejected at the kernel, not silently returned with empty results. Application code cannot bypass this boundary because application code does not own it.
Beyond row-level isolation, executives and agents that hold long-lived state are cryptographically compartmentalized. Each agent's working memory — its beliefs, its plans, its accumulated context — is encrypted with a key bound to that agent's identity. An attempt by another agent (or another tenant) to read that memory does not return an authorization error; it returns ciphertext. The boundary is not a check that can be bypassed by escalating privilege. It is a cryptographic boundary that requires breaking the underlying key management infrastructure itself.
The dedicated tier extends this: customer-managed keys (BYOK) ensure that even No13 cannot decrypt customer data without customer-controlled key access.
The cryptographic landscape is changing. Quantum computers are not a hypothetical anymore — they are a procurement timeline. Adversaries already harvest encrypted traffic on the assumption that they will decrypt it in the 2030s. Federal mandates require post-quantum cryptography in national security systems by 2033. Enterprise procurement is starting to ask the question: what happens to my data when the quantum machine arrives?
In Meridian, the answer is that the cryptographic substrate is designed to migrate without rewriting the system on top of it.
AES-256-GCM, SHA-256, and HMAC-SHA256 — the algorithms protecting data at rest, hashing identifiers, and authenticating callbacks — remain secure against quantum attack and require no migration.
Our network channel runs TLS 1.3 with hybrid post-quantum key exchange curves enabled by default. Customers connecting to Meridian today benefit from quantum-resistant key agreement at the network layer.
Every classical asymmetric primitive in the system has been inventoried, mapped to its NIST post-quantum successor (FIPS 203 for key encapsulation, FIPS 204 for digital signatures), and made ready for migration. Gated only on cloud key-management general availability — a dependency outside any vendor's control.
The substrate is built so that algorithm replacement is a configuration change, not a rewrite. When NIST ratifies a successor or deprecates an algorithm, customers migrate by configuration. The body outlives the math.
"Meridian is post-quantum-ready, not post-quantum-complete. Anyone selling 'fully post-quantum' today is either marketing against early NIST drafts or playing word games. We are honest about the migration. Symmetric is safe. Transport is hybrid. Asymmetric is plan-ready and waiting on the cloud-provider general availability timeline. When that timeline ships, we ship the same week."
Every routing decision, every model invocation, every validation outcome, every state transition writes a tamper-evident record into the audit substrate. The same stream is published live to the user interface as the system runs: customers do not get a black box that finishes and announces a result. They watch the system think. Step counters, latency, cognitive trace, errors, the slice of context the model received, the validated output that came back — all visible in real time, all permanently anchored.
When a step fails, the system does not die silently. A specialized repair pipeline activates at maximum verbosity. The user watches the system diagnose, generate a candidate fix, retest, and either succeed or surface a clear actionable error. Where most AI systems fail invisibly and recover by retry, Meridian fails legibly and recovers by transparent self-correction.
External verification — which every regulated, safety-critical, or enterprise deployment requires — is provided by the substrate, because no process can be its own audit trail.
AI without human governance is a liability. Meridian's substrate enforces governance as code, not as policy. Three approval modes are built into the system, each appropriate to a different class of decision.
For business decisions that require human judgment ("should we ship the credit?"). Routed to the responsible role with full context, time-bounded, with structured outcome.
For any operation that touches the security envelope (new automation, new agent capability, new credential scope). Routed to security operations with risk assessment.
For any operation that changes governance itself (new approval rule, new permission, new agent role). Cannot be bypassed, auto-approved, or delegated to non-admins.
Each gate is first-class: it is part of the substrate, not a layer of UI on top of it. An operation that requires a gate cannot proceed without one. Critical operations include a structural property: the system halts mid-execution and waits for approval, at zero compute cost, for as long as the approver takes. A three-day approval cycle consumes no resources until the human responds.
Dual-control approvals are available for the highest-risk operations — wire transfers, IAM policy changes, irreversible production mutations. Two cryptographically-signed approvals from authorized identities are required before the action proceeds. Same gate, every domain.
Authentication runs on open standards: OpenID Connect with Proof Key for Code Exchange. Session continuity uses short-lived tokens with automatic refresh. WebAuthn and passkey support is required for governance-critical actions — sending email under your identity, authorizing a high-value transaction, changing a security policy. Just-in-time credential issuance for agents performing scoped work; standing privileges minimized wherever feasible.
The integration surface is the same standards-based protocol layer that the open ecosystem uses. There is no custom protocol you have to learn to integrate. The federation works with the identity providers your enterprise already deploys.
Single deployment with kernel-enforced tenant isolation and cryptographic compartmentalization. Standard SLAs. For most SMB and mid-market deployments.
Per-tenant external-API adapters and credentials. No shared third-party tokens. Enhanced SLAs. For enterprises with sensitive third-party integrations.
Per-tenant Kubernetes namespace. Optional air-gap deployment. Customer-managed keys (BYOK). Hardware security module (HSM) integration. Customer-controlled data residency. For regulated industries, government, defense, sovereign cloud requirements.
A subprocessor list and data residency details are published at /trust/subprocessors.html and updated when material changes occur.
Enterprise procurement requires clarity on where the lines are. Here are ours.
Report security issues to [email protected]. PGP key available on request.
Eight domains. One substrate. One trust posture.
Request a private deployment review.