Everything below runs in your account. Nothing below runs on ours.
This page is for the architect or security reviewer who has to sign the thing off. It names every component of a deployment, says which control is enforced by what mechanism and on which tier, and marks the one boundary the architecture does not cross.
A deployment has three zones: the people who use it, the cloud account that holds it, and the managed model service the account calls out to. The account boundary is the isolation boundary. There is no shared control plane and no tenant identifier separating you from anybody else.
The drawing below is not decoration. A discovered architecture model is emitted from the synthesized templates on every deploy and reconciled against it.
Sign-in is a hosted page using the authorization code flow with PKCE, and tokens are held in httpOnly cookies. The user directory lives in your account, so the list of people who can reach the environment is yours to read and yours to revoke.
A chat request is authorized, metered with a reservation, then issued to the model service by the chat handler under a role carrying four denies. These are denies in cloud identity policy, not checks in application code, so they hold for anything running under that role, including a module that brokers inference.
A call that does not carry your content policy is refused before it reaches a model.
Inference that does not travel the governed route is denied, so there is no second door.
Inference outside the configured endpoint regions is denied at the account.
The workload cannot change the account's data-retention election to a looser one.
Tests fail the build if one of these is weakened. They prove your policy is attached to every call. What that policy says is yours to set: denied-topic and personal-information rules are supported by the policy engine and configured per client. See enforced in cloud policy.
Data at rest stays in your account. Account-level audit logging, multi-region with file validation and one-year retention, is a Standard and Strict control. Evidentiary storage with object lock, a seven-year default and break-glass access requiring a second factor is available where a deployment needs it.
What a module may reach is written into your parameter file, and every piece of module identity policy is materialized from it when the deployment is built. Nothing at runtime widens it.
Each module is served from its own origin and framed inside the dashboard, with a content security policy built per request from that module's manifest.
A signed assertion pinned to one module audience, redeemed once, carried on a host-scoped session cookie.
The broker runs fail-closed checks, intersects the request with the admitted ceiling, and issues a session of at most fifteen minutes tagged to the named person. A permission boundary denies the platform's own tables to every module role.
The full contract, the authoring kit and the promotion path are on modules. Client modules in use today run on the staging channel; the production promotion path is built and exercised on our own deployment.
Your posture is one typed object, resolved from a tier name with per-flag overrides. The infrastructure reads it, the "your plan" page inside the product reads it, and the machine-readable export reads it. A test fails the build if the page and the exceptions table disagree.
| Control | Mechanism | Where it lives | Tier |
|---|---|---|---|
| Content policy on every inference call | Deny in cloud identity policy | Chat role and every module inference role | All |
| Governed route only, configured regions only | Deny in cloud identity policy | Same roles | All |
| Retention election cannot be widened | Deny in cloud identity policy | Account scope | All |
| Client isolation | The cloud account itself | Your account | All |
| Model allowlist | Checked at listing and at invoke | Shared contract library | All |
| Per-person token quota | Atomic reserve then settle, fails closed | Metering store | All |
| Module capability ceiling | Admission at deploy time, intersected at vend | Module identity policy | All |
| Private model endpoint, network-attached chat | Isolated private network | Your account | Standard, Strict |
| Account-level audit logging | Multi-region, file validation, one year | Your account | Standard, Strict |
| Encryption keys at rest | Provider-owned, provider-managed, or customer-managed with rotation | Your account | Baseline, Standard, Strict |
| Inference residency pin | Allow scoped to in-country destinations, plus refusal in words | Model route | Strict |
Baseline is the low-cost entry posture: single-account isolation, encryption in transit and at rest, the mandatory content policy, least-privilege identity policy and everything as code, with no private networking and no account audit trail. It suits low-sensitivity use and a first evaluation; a security review will usually want Standard. The residency pin's real capability cost is on data residency.
The managed model service processes the request; the model does not run inside your network. A managed model service cannot. What that buys you instead is a route you control end to end: your content policy attached by cloud identity policy, your configured regions, your retention election, and on Standard and Strict a private network endpoint from inside your own account.
One account, one cloud. Moving the platform to another cloud provider would be a rebuild, not a migration. Composable refers to models: switching between them is a parameter change on the same governed route. The boundary, in full.
It is a posture decision, not a default. At Baseline no cross-account role exists at all. On Standard and Strict our access is a scoped role with a session cap and an external identifier, and you can revoke it without our help.
Its ceiling is fixed at admission and intersected again when a credential is vended, and a permission boundary denies the platform's own tables to every module role. The broker sits on an identity-authorized interface with no cross-origin configuration, so a browser cannot call it directly.
Every deploy emits a discovered model from the synthesized templates and compares it against the drawing. That proves the templates. A live acceptance run against your own deployment, which we run after each deploy, proves the running system.
Yes. Infrastructure-as-code and runbooks are deliverables, and the deployment lives in your account where you can inspect every resource yourself. That is the point of the glass box.
Users, roles, grants, quotas and whether a module channel is enabled. Nothing else. Models, the allowlist, the content policy, tier and residency are deploy-time parameters. See administration.
Bring your reviewer. The assessment ends in a written deployment plan with the tier, the residency decision and the standing exceptions named.