Written for the person who says no.
Every enterprise AI project eventually meets a security architect whose job is to find the reason this cannot ship. That review is where most pilots die — not because the objections are unreasonable, but because nobody designed for them. This page is the set of answers, stated plainly enough to paste into a questionnaire.
The seven questions, answered in one line each
01
Where does our data go?
Nowhere. It stays in your VPC.
02
Where does generated code run?
Hardware-isolated MicroVMs.
03
What if it is compromised?
Egress denied by default.
04
Who is allowed to do what?
Your IdP, intersected per turn.
05
What about personal data?
Tokenized before transmission.
06
Can it act on its own?
Not on a write. Ever.
07
What can an auditor see?
The whole causal chain.
08
Can we run air-gapped?
Yes. Same codebase.
01 · Trust boundary
The vendor never holds your data.
Most AI vendors ask you to accept that your proprietary data will be processed on infrastructure you do not control, under a data processing agreement and a promise. For a Fortune 500 with a data residency clause, that is not a negotiation — it is a decline.
So the architecture splits at a hard line. Orchestration decides what should happen next and holds no customer data at rest. Execution lives entirely in your cloud account and is the only thing that ever touches a system of yours.
Control plane · ours
- ·Session lifecycle, routing, and agent compilation
- ·Policy evaluation and the pre-execution gate
- ·Trace collection and metering
- ✕No customer data at rest
↕ mTLS + W3C TraceContext
Execution plane · yours
- ·Runs inside your VPC, on your account, under your IAM
- ·The only component that connects to your systems
- ·Sandboxed code execution with enforced egress policy
- ✓Your data never crosses the boundary
02 · Execution isolation
Assume the agent is hostile. Design accordingly.
An agent that writes and executes code is, architecturally, a remote code execution path you built on purpose. Container-level isolation is not sufficient for that — a container shares a kernel, and kernel escapes are a known category, not a hypothetical.
Hypervisor-level sandboxing
Agent-generated code runs in a MicroVM — a hardware-level hypervisor — with its own kernel. The isolation boundary is the hypervisor, not a namespace. A successful escape from the sandbox lands the attacker in an empty virtual machine.
Egress denied by default
Each sandbox carries an eBPF network filter and a DNS sinkhole. Outbound traffic is restricted to an allowlist you define, so a fully compromised agent still has nowhere to send anything. Exfiltration requires a destination, and there is none.
Output scanned on the way out
A sidecar inspects everything the sandbox emits before it leaves, catching personal data that a query returned incidentally. Defense in depth: the tokenizer runs on the way in, the scanner runs on the way out.
eBPF allowlist and DNS sinkhole active. Two destinations approved; three refused.
Filter disabled — the same agent, the same run, with the egress policy removed.
04 · Identity & authorization
Permissions are intersected, not inherited.
The failure mode in most agent platforms is a single service account with broad access, which means every user effectively has the union of everyone's permissions. Here the tool roster available on a given turn is the three-way intersection of what the platform supports, what your tenant has entitled, and what that specific user's role permits.
available_tools = platform ∩ tenant ∩ rbac
→ compiled into a signed session manifest, per turn
- → SAML 2.0 and OIDC ingress against Azure AD, Okta, Google, ADFS, or a custom provider
- → Tokens held in key-management-backed storage, never in application configuration
- → Session history re-validates authorization on access, so a revoked role loses past sessions too
- → Cached agent specifications carry a permissions hash and expire when entitlements change
05 · Privacy
Sensitive spans never reach the model.
Context-aware tokenization replaces sensitive spans before transmission and re-injects the real values after the response returns, so the user sees a complete answer while the model only ever saw placeholders. Crucially, this is governed by a declarative policy rather than hardcoded rules — your compliance team can read and amend it.
Category allowlist
Which classes of data are tokenized at all — names, national identifiers, financial instruments, health data.
Custom enterprise patterns
Your own identifier formats — internal account numbers, part codes, case references — treated as sensitive even though no generic scanner would recognize them.
Known-safe denylist
Literal and pattern exclusions for values that look sensitive but are not, so over-tokenization does not degrade answer quality.
Skip-context rules
Tag-scoped and preceded-by exclusions, plus per-domain overrides, so policy can differ between a support transcript and a financial ledger.
06 · Human control
Reads are free. Writes stop. Every time.
"Human in the loop" is usually a slide, not a mechanism. Here it is a state machine with three properties that make it hold up under adversarial conditions.
PROPERTY 01
Blast radius is shown, not described
The gate renders a diff of exactly what would change and how many records it reaches. A reviewer approving "update the opportunity records" without seeing which twelve is not review, it is ceremony.
PROPERTY 02
Approvals cannot be replayed
Every approval is pinned to an optimistic-concurrency version token and to the schema it was granted against. If the plan or the tool definition changes after approval, the token no longer matches and the write is refused rather than executed against something nobody reviewed.
PROPERTY 03
Escalate is a first-class outcome
Approve and reject are not enough. A reviewer who is not the right person to decide can escalate, which routes the decision without either rubber-stamping it or silently dropping the work.
The same gate applies in every solution. In test engineering it is the review queue before a case is written to your ALM tool. In agentic workflows it is the write gate before a record is updated. In business intelligence it is the diff before a dashboard version is overwritten. One mechanism, three surfaces — which is why a security review of one carries over to the others.
07 · Auditability
Reconstruct the decision, not a summary of it.
Six months later someone will ask why the system changed a record, and "the AI decided" is not an answer that survives an audit. Every agent action is traced end to end with distributed trace context propagated across the control and execution boundary, so the causal chain is reconstructible rather than inferred.
- →Which turn triggered which tool call, with the arguments it was given
- →What that call returned, and which citation in the narrative points at it
- →Who approved the resulting write, when, and against which version token
- →What the gate refused, and why the policy evaluated the way it did
trace_id 4bf92f3577b34da6a3ce929d0e0e4736
├─ ingress user=j.rivera@ · role=analyst
│ ├─ tokenize 14 spans held
│ └─ injection scan clean
├─ route NEW_TASK · 84ms
├─ factory manifest signed · 9 tools
│ └─ intersection platform∩tenant∩rbac
├─ tool warehouse.aggregate
│ └─ returned 84,112 rows → pointer [1]
├─ gate crm.update HELD
│ ├─ blast_radius 12 records
│ ├─ version_token v7 · pinned
│ └─ approved m.okafor@ · 14:22:07Z
├─ tool crm.update COMMITTED
└─ egress detokenize · render
08 · Deployment
Four topologies. One codebase.
Choosing the restrictive option should not put you on a lagging feature branch. It is the same code in every topology, which is why the on-premises deployment is not a downgrade.
Kubernetes / Helm
Most common
On-premises or BYOC inside your existing cluster, under your network policy and your service mesh.
Docker
Fastest start
Compose-based deployment with a managed database, appropriate for a scoped pilot on isolated infrastructure.
Signed single binary
Air-gapped
A cryptographically signed desktop executable for environments where running a service is not permitted at all.
Managed cloud
Lowest ops
We operate the control plane; the execution plane still runs in your account. Suitable when data residency is not the binding constraint.
On inference and model access
We do not require a specific model vendor or introduce a new outbound path. Inference routes through whatever gateway your organization has already approved — an internal AI gateway, a cloud-native endpoint in your own subscription, or a self-hosted model. Retrieval embeddings run resident and locally rather than calling a hosted embedding service, which is what makes a fully egress-restricted deployment viable rather than theoretical.
Adversarial testing
Attacks we design against, by name.
A vendor who cannot name the attacks against their own class of system has not looked for them. Each of these has a specific mitigation in the codebase, and each gets exercised during the hardening phase of an engagement.
| Attack | Mitigation |
|---|---|
| Tool shadowing | A malicious server registers a tool impersonating a trusted one. Name collisions resolve fail-closed — the request is denied rather than resolved by guess. |
| Description injection | Instructions smuggled into a tool's own description text. Descriptions are treated as untrusted input and cannot redirect agent behavior. |
| Subquery evasion | A restricted operation nested inside a subquery to slip past a string-matching rule. Queries are parsed into a syntax tree and validated structurally. |
| URL egress / SSRF | A citation or pointer rendered as a link to an attacker-controlled destination. URLs are validated against an allowlist before rendering. |
| Approval replay | Reusing a granted approval against a modified plan. Approvals are pinned to a concurrency token and the approved schema; a mismatch refuses the write. |
| Citation forgery | The model emitting authoritative-looking markers it invented. Citations are generated by the backend from the tool-call record; unmatched markers are stripped. |
| Duplicate-write retry | A transient failure on a non-idempotent write becoming a duplicate transaction on retry. Retry guards are idempotency-aware per operation. |
FAQ
Straight from the questionnaire.
The control plane orchestrates and holds no customer data at rest; the execution plane runs in your VPC and is the only thing that touches your systems. They communicate over mutual TLS with distributed trace context propagated across the seam so the audit trail survives the boundary. In an on-premises deployment both planes run in your environment and the boundary becomes internal.
It has nowhere to send anything and nothing it can write unilaterally. Code executes in a MicroVM with its own kernel, so the isolation boundary is the hypervisor rather than a namespace. Egress is denied by default via eBPF filtering and a DNS sinkhole. Every write still requires a human approval pinned to a version token. The realistic worst case is unauthorized reads within the tool roster that user's role already permitted — which is why the three-way permission intersection matters.
Yes. Inference routes through whatever gateway you have already approved — including a self-hosted model — and retrieval embeddings run resident and locally rather than calling a hosted service. Deployment supports Kubernetes and Helm on your own infrastructure, or a cryptographically signed single binary where running a service is not permitted. It is the same codebase, so the restrictive topology is not a reduced feature set.
Connection credentials and API keys are encrypted at rest with authenticated symmetric encryption before they reach any database, and are never written to plaintext configuration. Identity tokens are held in key-management-backed storage under your own key material. In a BYOC or on-premises deployment the credential store is inside your perimeter, so we hold nothing at all — we do not have access to the environment those secrets live in.
Two weeks of their attention at the start, not a sign-off at the end. Weeks one and two of an engagement settle deployment topology, data residency, identity provider, egress policy, and audit requirements, and produce a threat model and deployment diagram your reviewers have already seen. Deferring that conversation to the end is the single most common reason enterprise AI projects miss their date.
Send the questionnaire before the demo.
We would rather answer forty security questions in writing and then show you something, than show you something and spend two months answering them. Send us the assessment your vendor risk team uses.
Written on this
The engineering behind it, in detail
Comparison
Bedrock Agents and Vertex AI Agent Builder: What a Managed Runtime Decides for You
Four architectural decisions you inherit with a managed agent runtime, the one written commitment that rules it out, and why the switching cost is not where people look for it.
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.
Security
Why Enterprise AI Pilots Die in Security Review
The pilot worked. Eighteen months later it still is not in production. Five architectural questions decide that outcome, and all five are settled before the first line of code.
Security
Prompt Injection Is a Containment Problem, Not a Prompting Problem
The defence and the attack share a channel, so no instruction closes the class. Four named attacks, and the architectural layers that make a successful one harmless.
Architecture
BYOC, SaaS, or On-Premises: Choosing a Deployment Topology for Enterprise AI
Deployment topology is not an infrastructure detail you settle later. It determines which data the system may touch, and it is the hardest decision to reverse.