Skip to content
Teardown

Teardown: The Two-Plane Execution Architecture

A control plane that holds no customer data, an execution plane inside your VPC, and a hypervisor boundary between agent-generated code and everything else. What each layer defends against, and what the shape costs.

5 min read

The deployment boundary is the architecture. A control plane decides what should happen next and holds no customer data at rest; an execution plane inside your own cloud account is the only thing that touches your systems. Everything else in this teardown follows from that one split, including the answer to every question a security review will ask.

This is a teardown rather than an argument. It describes how the system is actually built: which component holds what, where the trust boundary sits, and what each isolation layer is defending against. The reasoning for why topology is decided first is covered separately in the deployment topology article; this page is the implementation.

From the standard

“Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.”
NIST SP 800-207, Zero Trust Architecture — csrc.nist.gov

The split

Two planes, one hard boundary between them. The control plane is ours and runs as a service. The execution plane is yours and runs in your cloud account, under your identity provider, inside your network policy.

Control plane — ours no customer data at rest
  • Session lifecycle, routing, agent compilation
  • Policy evaluation and the pre-execution gate
  • Trace collection and metering
mutual TLS W3C TraceContext propagated
Execution plane — yours inside your VPC
MICROVM Own kernel, hypervisor boundary Agent-generated code runs here, and nowhere else.
  • eBPF filter and DNS sinkhole — egress denied by default
  • Your warehouses and your systems of record
The control plane has nothing to secure, because it never holds your records.

The property that matters to a reviewer is not that the control plane is well secured. It is that the control plane has nothing to secure. It never holds your records, so a compromise of our service does not become a compromise of your data.

Isolation, layer by layer

1. The hypervisor boundary

Agent-generated code is code that no human reviewed before it executed. That is a different threat model from running your own application, and container-level isolation does not meet it. Containers share a host kernel, and kernel escapes are a known vulnerability class rather than a theoretical one.

Each execution therefore runs in a MicroVM with its own kernel. The isolation boundary is the hypervisor, not a namespace. A successful escape puts the attacker inside an empty virtual machine.

2. Egress denied by default

Isolation on its own still leaves a network path out. Each sandbox therefore carries an eBPF network filter and a DNS sinkhole, restricting outbound traffic to an allowlist you define. A fully compromised agent has nowhere to send anything, because exfiltration requires a destination and there is not one.

Why both, and not either

The packet filter stops traffic to an address. The DNS sinkhole stops the lookup that would have produced the address. Together they close both the direct connection and the resolution path, which is what makes the allowlist meaningful rather than advisory.

3. Tokenization inbound, scanning outbound

Context-aware tokenization replaces sensitive spans before transmission and re-injects the real values after the response returns, so the user reads a complete answer while the model only ever saw placeholders. The policy is declarative and per-tenant: a category allowlist controlling which classes of data are tokenized at all, custom identifier patterns, and a known-safe denylist for values that look sensitive but are not, so over-tokenization does not degrade the answer.

Defence in depth means the two run in opposite directions: the tokenizer on the way in, the scanner on the way out.

What the seam carries

Mutual TLS in both directions, and W3C trace context propagated across the boundary so a single distributed trace spans both planes. That second property is what makes the audit story work: the control plane can prove which turn triggered which tool call without ever having seen the data that call returned.

Identity and the tool roster

Ingress is SAML 2.0 or OIDC against Azure AD, Okta, Google, ADFS, or a custom provider. The agent acts under the identity of the person driving it, not a service account, which is what makes the authorization question answerable at all.

session manifest · this turn
TOOLPLTTENRBA
warehouse.queryPTR
warehouse.previewPTR
catalog.searchPTR
metrics.aggregatePTR
crm.readPTR
crm.updatePT·
alm.create_testPT·
repo.indexPT·
storage.presignPT·
pipeline.runP··
billing.exportP··
admin.rotate_keysP··
COMPILED ROSTER 5

warehouse.query · warehouse.preview · catalog.search · metrics.aggregate · crm.read

0 tools this role permits are absent anyway — the tenant never enabled them. Intersection, not union.

Switch to Admin and three tools stay dark. A capability outside the intersection is absent from the manifest, not denied at the gate.

The available tool roster is computed per turn as the intersection of what the platform supports, what the tenant has enabled, and what the acting user's role permits, then compiled into a signed session manifest. An instruction injected into content cannot reach for a capability outside that intersection, because the capability was never in the manifest.

  1. available_tools = platform ∩ tenant ∩ rbac Three sets, intersected What the platform offers, what the tenant enabled, and what this person’s role permits.
  2. SIGNED SESSION MANIFEST Compiled once per turn
  3. SCHEMAS INJECTED JUST IN TIME Only when a tool is about to be used So a large connector roster never consumes the context window.
The roster is recompiled every turn, so a permission change takes effect on the next one.

Connectors as configuration

Connectors are declarative manifests rather than code. The layer discovers each tool schema at runtime and injects it just in time, which means adding a system is a configuration commit reviewed like any other change rather than a release. Nineteen connectors currently cover five cloud warehouses and fourteen file and service adapters.

One consequence worth stating: when a result set exceeds a size threshold, the connector materializes it to object storage and returns a pre-signed URL rather than the rows themselves. Large results never transit the model context, which bounds both cost and exposure.

The restricted-egress case

The topology also runs air-gapped or fully egress-restricted. Inference routes through whatever gateway your organization has already approved, deployment supports Kubernetes and Helm on premises, and the retrieval embedding model runs resident and locally rather than calling a hosted embedding service. That last detail is what makes the air-gapped case real rather than nominal — a system that must reach a hosted embedding endpoint is not air-gapped, whatever else is true of it.

What this shape costs

It is not free. You run infrastructure, you patch it, and you own an on-call rotation for it. A single-tenant hosted deployment is operationally cheaper and clears review at a large number of organizations. The two-plane split earns its cost only where a contract, a regulator, or a residency clause says the data does not leave — and in that case it is not a preference, it is the only shape that answers the question with a network diagram rather than a legal assurance.

The deployed system this teardown describes runs 60 production modules behind 1,800 automated tests, and is designed to classify each conversational turn in under 100 milliseconds before any pipeline runs.

Axionalytics

Production agentic AI for enterprise engineering, data, and revenue teams.

Keep reading

Facing this in your own environment?

Forty-five minutes with the engineers who build these systems. Bring the constraint that has been blocking you — you will leave with an architecture opinion whether or not you work with us.