You are not opposed to AI. You are opposed to a data flow you cannot scope, approved by someone who will not carry it.
Every artifact on this page exists because a reviewer asked for it, and each one is linked rather than described. Where a control is enforced, the page says what enforces it. Where it is partial, the page says that too.
The security owner carries the risk of saying yes. The operating owner carries the cost of saying no. Both are real, and the standoff between them is where most organizations have been sitting for two years. Nothing moves until the person holding the veto can defend a yes on their own evidence.
Nobody wants to be the person who approved the tool that leaked something. That is not timidity, it is an accurate reading of how these events are reviewed afterwards, and it is why "the vendor has a report" is not an answer you can stand behind.
A vendor's attestation describes the vendor's controls. It does not certify you, and accountability for personal information travels with the data even when processing is somewhere else. Your obligation stays yours whichever product you buy.
The policy exists, and the surveys on unsanctioned use are not flattering to any of us. Saying no has not produced zero AI in most organizations; it has produced AI with no record. The sourced picture is here.
The boundary is a defined term on this site, not an atmosphere. It is the cloud account you own and the region it runs in. Data at rest stays in your account. The managed model service still processes the content of a request, which is why we never write that data never leaves your boundary, and why the connection to that service can be a private network endpoint rather than the public internet on the Standard and Strict tiers.
Four things are denied by cloud identity policy rather than by application code: a call without the content policy, inference outside the configured endpoint regions, inference that bypasses the governed route, and any widening of the account's data-retention election. The content policy itself is a pinned, numbered version, so what applied last quarter stays identifiable. What is configured rather than enforced: the policy's denied topics and PII rules, which are set per client and empty by default. We will not sell PII redaction or prompt-injection defence as guaranteed outcomes. The full list is here.
| Control | Baseline | Standard | Strict |
|---|---|---|---|
| Single-account isolation, encryption in transit and at rest, everything as code | ✓Yes | ✓Yes | ✓Yes |
| Content policy mandatory on every inference call, enforced as a deny | ✓Yes | ✓Yes | ✓Yes |
| Private network endpoint to the model service, network-attached chat compute | ✕No | ✓Yes | ✓Yes |
| Account-level audit logging, multi-region, file validation, one-year retention | ✕No | ✓Yes | ✓Yes |
| Encryption keys | △Provider-owned | △Provider-managed | ✓Customer-managed, with rotation |
| MFA enforced | △Optional add | ✓Yes | ✓Yes |
| Management access for us | ✓No cross-account role exists | △Scoped, session-capped | △Scoped, session-capped |
| Inference residency pinned to your jurisdiction | ✕No | ✕No | ✓Yes, at a capability cost |
Baseline is the low-cost entry posture and suits low-sensitivity use and a first evaluation. A security review will usually want Standard. The residency row is the one to read twice: of the 104 active models in the catalogue generated on 5 September 2026, 13 run in-region in Canada and every current frontier model routes outside it, so a Strict pin is a real choice with a real capability cost. Residency, honestly.
Baseline, Standard or Strict, with any individual control overridden up or down and the reason recorded. The questionnaire produces a recommendation; you approve it, and it is committed as the input the infrastructure is built from. A drift between the two fails the deploy.
Prompts are not used to train models and are not shared with model vendors by default. The newest frontier tier from one vendor requires provider-side data sharing with retention up to 30 days; those models stay unavailable until you elect that explicitly, in writing, as a change rather than an upgrade.
One or more named people who hold grants, quotas and module promotion. An administrator reading someone's chat transcript is itself written to the audit record. Administrators cannot change the model allowlist, the policy, the tier or residency: those are deploy-time parameters changed through a release.
It is the right question, and the first half of the answer is that we hold no third-party attestation and we are a small practice. Nothing here rests on our word being taken. The evidence is checkable by you, in your own account, without us. The page describing your controls is generated from the same typed object that builds the infrastructure, and a test fails the build if the two disagree. The deployment comes from a tagged release and a clean checkout. The audit trail sits in your account, not ours. The standing exceptions are shown to you inside the product rather than discovered later. That is the mechanism that bounds the risk: you verify it where it runs, instead of trusting it.
Hosted sign-in with PKCE, tokens in httpOnly cookies, passkeys, TOTP and second factors as self-service, and the user directory in your own account. Federation with an existing enterprise identity provider has been done once and is scoped per engagement. There is no SAML, and single sign-on is not a shipped feature.
Model invocation logging carries model, caller identity, latency and token counts. It deliberately carries no prompt or answer text, so nobody should tell you every prompt and response is auditable. Account-level audit logging with one-year retention is available on the Standard and Strict tiers, and evidentiary storage with object lock and a seven-year default is available where a deployment needs it.
Everything loaded into a deployment's knowledge base is readable by every user of that deployment, so you load only what everyone may see. Per-user and per-document permissions on retrieval are not built. If your use case needs them, say so at the assessment and we will tell you it is not a fit today. The limits are on the product page.
At Baseline, no cross-account role exists at all. On the Standard and Strict tiers our management access is scoped and session-capped. Anything we do arrives through a release from a tagged build, and the operations journal is dated. You hold the root credentials and the billing relationship throughout.
An acceptance suite the factory runs over HTTPS against the real deployment after every deploy: replayed tickets, forged sessions, one module's session presented at another module's host and corrupted uploads. Each must be refused, or the deploy is not accepted. In the product's own suite, roughly 2,700 automated test cases across about 170 files include tests that fail the build if a governance deny is weakened.
The assessment produces a network topology and data-flow map written for your review process. You keep it whether or not you proceed.