An architecture designed around the trust boundary.
Every design decision in Data.co starts with one question: where does sensitive data go, and who decided it could? This page describes the components, how a request moves through them, and the principles that keep the answers simple.
What runs in your environment.
Identity layer
Users from your identity provider, plus first-class identities for service accounts, agents, and models, with on-behalf-of tracking.
Classification
Labels such as PHI, PII, financial, and privileged applied at ingest to documents, chunks, rows, and embeddings.
Policy decision point
A deterministic rules engine returning allow, deny, or require approval with matching policy IDs and a reason.
AI gateway
An OpenAI-compatible endpoint that authenticates, evaluates policy, routes to approved models, and logs.
MCP gateway
Registers MCP servers, pins tool definitions, and authorizes each tool call with its arguments.
Audit log
Append-only, hash-chained records of requests and decisions, stored locally and exportable as evidence.
What happens on a single request.
- 1
Authenticate
The gateway verifies the caller and, for agents, the user they act for.
- 2
Describe
The request is expressed as subject, resource, action, and context, including data labels involved.
- 3
Decide
The policy engine evaluates applicable policies. No model participates in this step.
- 4
Enforce
Retrieval filters, model routing, or tool execution proceed only as the decision allows.
- 5
Record
The request, decision, policy IDs, and outcome are appended to the audit log.
What app.data.co sees, and what it never sees.
| Data | In your deployment | Sent to app.data.co |
|---|---|---|
| Prompts and responses | Yes | Never |
| Documents and records | Yes | Never |
| Embeddings and indexes | Yes | Never |
| Audit log | Yes | Never |
| License and account status | Cached | Yes |
| Opt-in admin metadata | Yes | Only if enabled |
A hosted plane for accounts. A local runtime for everything else.
Data.co is split deliberately. The hosted plane at app.data.co manages organizations, roles, licensing, billing, and Control configuration such as policies and identity definitions. The Control runtime runs in your network and does the enforcement: it holds the AI gateway, the MCP gateway, the policy decision point, and the audit log, and it is the only component that ever sees prompts, tool arguments, or records.
The runtime never asks the hosted plane for permission. Its license is a signed file verified offline with an Ed25519 public key, and it keeps enforcing through a grace period if a renewal is late. An optional heartbeat reports only version, license status, health, component states, and the active policy set version, through a strict schema that rejects any other field. In air-gapped mode the heartbeat is refused even if enabled, and the runtime's egress guard blocks every destination except the inference endpoints and MCP servers you configured.
How the policy engine resolves a request.
Evaluation order is fixed, so the same input and policy set always produce the same decision, policy IDs, and input hash.
| Rule | Effect |
|---|---|
| Default deny | No matching allow means deny, with the reason no_matching_allow |
| Deny overrides | Any matching deny wins, regardless of priority or author |
| Scope ceiling | An identity's declared scope caps what any allow can grant |
| Approval overrides allow | A matching require_approval holds the request until a single-use approval exists |
| Delegation | Agents acting for a user are evaluated as both; the stricter result applies |
| Fail closed | One invalid policy invalidates the set; errors and malformed requests are denied |
One line per event, chained by hash.
Each record includes the hash of the previous one, so modifying, deleting, inserting, or reordering records breaks the chain. Records are content-free: identities, resources, decisions, policy IDs, and argument keys, never prompt text or argument values. Writes are synchronous, and a failed write denies the request.
{"v":1,"seq":42,"ts":"2026-11-06T14:03:11.204Z",
"prev":"9f2c…e1","hash":"4b7a…0d",
"event":{"type":"decision","subject":"agent:rcm-billing",
"resource":"ehr.clinical_notes","action":"read",
"decision":"deny","policy_ids":["pol_phi_002"]}}Illustrative example · final API surface documented in /docs
Constraints we hold ourselves to.
- No LLM in the access decision path
- Fail closed when a dependency is unavailable
- Run with no outbound connectivity
- Policies, classification rules, and configuration as code
- Source-system permissions carried forward, never widened
- Retrieved and tool content treated as untrusted input
- Open standards where they exist: OpenAI-compatible API, MCP, OIDC
Questions buyers ask
What does Data.co run on?
Linux servers in your data center or private cloud, typically containerized. GPU servers host model inference; the control plane components run on standard compute.
Why keep LLMs out of the decision path?
Access decisions need to be repeatable, testable, and explainable. A model's output can change with phrasing and can be influenced by injected content, which makes it unsuitable as an enforcement mechanism.
Can the audit log be tampered with?
Records are append-only and hash-chained, so alteration is detectable. Protecting the underlying storage and exporting to an independent system strengthen that further.
Which models are supported?
Open-weight models served through vLLM or Ollama, plus any OpenAI-compatible endpoint you choose to register and approve.
Is any part of Data.co open source?
Data.co builds on open-source serving and storage components. Our licensing approach for Data.co's own components will be published with the documentation.
What happens if the license expires?
The runtime moves from valid to expiring thirty days ahead, then to a grace period in which it keeps enforcing and reports a degraded health status. After the grace period the gateways stop serving requests rather than serving them ungoverned.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.