The Enforcement Boundary Is a Deployment Choice

Every serious evaluation of an AI governance layer asks two questions. The first is what it catches. The second is where it runs. For most teams the second question is an operations detail. For regulated, sovereign, and federal environments it is the deal: a control that cannot run inside the required boundary is not a control, whatever its detection numbers say.

Governance is a decision plus a place

A governance verdict has to execute somewhere physical. That somewhere determines three things: who could tamper with the verdict, what data has to cross a boundary to produce it, and whose jurisdiction the whole exchange lives in. There are three broad placements, each a stronger claim than the last about who cannot alter the outcome.

At the egress. A proxy or gateway inspects traffic at the network edge. It governs whatever routes through it, which is real coverage, with a boundary that is honest to name: traffic that does not route through it is not governed.

In the server plane. The policy engine runs as a service the agent's runtime must call before an action executes. The verdict is produced outside the model's context entirely, so the model cannot talk its way around a boundary it never touches. This is where Shrike's scan pipeline lives on every channel.

In hardware. Policy executes inside a trusted execution environment (AMD SEV-SNP in our case), isolated at the silicon level even from the host operator. This is the placement for engagements where "outside the model's reach" has to include the infrastructure itself.

The contract must not move when the boundary does

Here is the property we consider non-negotiable, and the reason this post exists: the policy contract has to be identical at every placement. Same scan interface, same verdict shape, same declared agent scopes, same evidence record. You integrate once; where the enforcement boundary sits is then a deployment decision, made by the operator, changed without touching a line of integration code.

The test is simple. If moving from managed SaaS to a VPC deployment requires re-integrating, re-writing policy, or accepting a different evidence schema, you do not have one product with deployment options. You have two products, and your governance posture forks the day your residency requirements change.

Guardrails that live with the provider leave with the provider

There is a quieter version of the same portability question, and it sits inside the model API rather than the infrastructure. Providers ship increasingly good guardrails: content filters, safety settings, moderation endpoints. Teams sometimes count these as their governance layer. They are real controls and worth turning on. But they are a property of the provider, not of your posture: the policy vocabulary is the provider's, the thresholds are the provider's, and the record of what was blocked lives in the provider's console.

The consequences follow directly. Run two providers and you have two different floors that cannot express one policy. Switch providers, for price, for capability, or because the model you depend on is deprecated, and every tuned threshold and every month of accumulated evidence stays behind. Your governance posture resets on the day of the migration, which is exactly the day it should not.

Governance that is independent of the model provider does not have this failure mode. The policies, the declared scopes, and the evidence record live in a layer that treats every provider the same, so switching or adding one is a configuration change, not a governance migration. Provider guardrails then do what they are genuinely good at: a defense-in-depth floor underneath a policy you own and carry with you.

Where Shrike runs today, honestly tagged

Cloud SaaS, live today. Managed on Google Cloud, us-central1 by default with EU region on request. No content retention by default: safe interactions are stored as a hash plus metadata, never the content. Procurement can run through your existing Google Cloud commitment via the GCP Marketplace listing.

Your VPC, under Enterprise engagement. The enforcement plane deploys inside your network boundary. Prompts, tool calls, and verdicts stay behind your perimeter.

Air-gapped, under Enterprise engagement. Zero outbound. Policy updates arrive as signed bundles. Built for government and defense environments, with US-personnel-only support available.

Sovereign and TEE, under Enterprise engagement. In-region processing for data-residency mandates, and hardware-enclave isolation for engagements that require it.

The honest prints, because a portability claim without them is marketing: Google Cloud is live today, AWS is planned, and on-prem runs under Enterprise engagement. The full deployment and data-residency detail, including our subprocessor list, is on the trust center.

What a certificate covers, and what a boundary covers

Security questionnaires reasonably ask for SOC 2. Ours is in progress: Shrike is built to SOC 2-aligned controls with certification targeted for 2026, and we say exactly that rather than rounding up. But it is worth being precise about what a certificate does. SOC 2 attests that a vendor handles the data you send it responsibly. A deployment boundary you control answers a prior question: how much data has to be sent at all. When the enforcement plane runs inside your VPC or your air gap, the sensitive content never becomes anyone else's operational responsibility. Certificates and boundaries compose, and we are pursuing both. Only one of them is under your control, and that is the one deployment portability protects.

The operator decides

This is the same principle that runs through everything we ship: the operator declares the policy, and the operator places the boundary. Governance that dictates its own deployment model is governance with an opinion about your architecture. Ours is that the boundary is yours to place, and that nothing about your policies, your integration, or your evidence should change when you place it somewhere new.