Written for the person who has to sign off on this, and who will be asked, later, why they did.
Most governance in this market is a document that describes a system nobody can inspect. Here the controls are denies evaluated by your cloud provider before a request reaches a model, the content policy is a numbered version with a recorded digest, and the page inside the product that describes your controls is generated from the code that builds them.
There are three places a rule about AI can live, and only one of them survives a bad afternoon. A rule in a document depends on everybody reading it. A rule in an application depends on nobody changing it. A rule in cloud identity policy is evaluated by the cloud provider itself, on every call, outside the application, using credentials the application cannot widen. We write the first two as well. We only count the third.
Useful, and necessary for an audit. It binds behaviour only as far as attention goes. Nothing in a document refuses a request at three in the morning, and nothing in it tells you whether last quarter's answers were produced under this version or the one before.
Better. It acts on every request that goes through the application. It is also a value someone can change, a code path someone can branch around, and a second caller, a script or an add-on, can miss entirely.
The request carries your content policy or the cloud provider refuses it. The refusal happens before a model is reached, for every caller using that role, including a module backend. Weaken the deny and the test suite fails the build.
Your policies, applied in the system. Not a PDF, not a black box.The line this section exists to earn
Governance is easier to hold when the thing being governed belongs to you. One deployment is one organization in one cloud account that the organization owns and is billed for directly. That single decision is what makes the rest of this section answerable rather than promised.
Your cloud provider bills you directly at list price. We do not resell compute and hold no client data on our own infrastructure. At the Baseline posture there is no cross-account role for us at all.
Documents, the knowledge index, chat sessions and messages, usage records and module data sit in your account, in the storage region you chose. What crosses the line, and why, is set out on the boundary.
Model invocation logging records the model, the caller, latency and token counts, and deliberately carries no prompt or answer text. Administrator access to someone's transcript writes its own audit row.
The monthly fee buys the service, not access. Stop it and the deployed platform, its source and its data stay where they already are. Running it afterwards needs a competent cloud engineer, which is why runbooks and infrastructure as code are deliverables.
Data at rest stays in your account. That is not the same as "nothing leaves". A request to the managed model service leaves the account by design, which is why the boundary names what crosses, where it goes and under whose terms it is processed.
This is the whole stack on one page. The middle column is the part most vendor security pages leave out: not that a control exists, but what actually holds it in place when somebody tries to get around it.
| Control | How it is enforced | Posture |
|---|---|---|
| Client isolation | One organization, one cloud account you own and are billed for | All |
| Content policy on every inference | Deny in cloud identity policy, on the chat role and every module inference role | All |
| Governed route only | Deny on any inference that bypasses the governed route | All |
| Endpoint regions | Deny on inference outside the configured endpoint regions | All |
| Retention election | Deny on any workload widening the account's retention election | All |
| Policy version | Pinned numbered version with the policy digest recorded, never a mutable draft | All |
| Model invocation logging | Model, caller identity, latency, token counts. No prompt or answer text | All |
| Per-person quotas | Reserve then settle against the provider's own record of the call. Fails closed | All |
| Module credentials | 15 minutes at most, tagged to a named person, access record written before the credential exists | All |
| Promotion to production | A named administrator approves the exact artifact hash. Our automation cannot promote | All |
| Encryption keys | Provider-owned, provider-managed, or customer-managed with rotation | Baseline / Standard / Strict |
| Private network endpoint | Private path to the model service, network-attached chat compute | Standard and Strict |
| Account-level audit logging | Multi-region, file validation, one-year retention | Standard and Strict |
| MFA enforced | Identity policy. Can be added at Baseline | Standard and Strict |
| Our management access | Scoped and session-capped. At Baseline no cross-account role exists | Standard and Strict |
| Inference residency pin | Allow scoped to in-country destinations, plus a request-time refusal in words | Strict |
Posture column names the lowest posture at which the control is on. Every row is either enforced by cloud policy or by a deploy-time parameter an administrator cannot edit at runtime. The four rows marked as denies are covered in detail on enforced in cloud policy; the postures themselves on posture tiers.
Two mechanisms hold this section to the code, and both of them can fail us rather than flatter us.
Most vendor security reviews start with a questionnaire you send us and end with a document we send back. This one runs the other way round, because the questions we most want answered are about your requirements, not our marketing.
We publish the questions before the call. It covers your current AI landscape, residency with the capability tradeoff stated plainly, the security controls you need, your compliance program, and a recommended posture. It also asks you, in writing, to confirm you understand we hold no third-party attestation.
The controls matrix with its per-row verdicts, the resolved posture object for your deployment, the data-flow description, the shared-responsibility split, and the standing exceptions. Nothing in it is written for the occasion: the matrix is the only control narrative in this company tied directly to code, and the posture object is the same file that builds your infrastructure.
A live walk through the deployment: where each store sits, which role carries which deny, what the invocation log holds and what it deliberately does not, and what happens on a request that violates the policy. Questions we cannot answer become items, with owners. Questions that expose a gap go on your plan page as an exception rather than into a drawer.
Nine pages. Read them in order if you are preparing a review, or jump to the one your objection lives in.
No. Administrators manage users, roles, grants, quotas and module channels. They cannot change the model allowlist, the content policy, the posture, residency, or admit a module. Those are deploy-time parameters, changed through a release, and the policy itself is held by a deny in cloud identity policy rather than by the application. Detail on administration.
No. Model invocation logging records the model, caller identity, latency and token counts, and deliberately carries no prompt or answer text. You get request metadata and token evidence. An administrator reading a user's chat transcript is a separate, audited action that writes its own record.
No. We hold no third-party attestation. The platform is designed to align with SOC 2 and ISO/IEC 27001, and we provide the technical controls that support your program, mapped row by row with an honest verdict per row. An independent CPA firm issues a SOC 2 report; a vendor cannot hand you one. See compliance alignment.
A small senior practice, one principal with a bench of contractors, and worth weighing as such. What holds the controls is machine-checked rather than attested by headcount: the denies are asserted in tests, the plan page is generated from the code, and the exceptions are published to you inside the product. Your own reviewer is the second pair of eyes, and the questionnaire is built to make that easy.
It goes on your plan page as a standing exception, with what it is and what closes it, and into the operations journal. The denies are asserted in the build, so closing it is a recorded change rather than a quiet edit: see enforced in cloud policy. We fix in the direction of refusing: when a control is ambiguous, the system denies and we get a support call, rather than allowing and nobody noticing.
It is: own the environment, inspect the evidence, and keep the exit open. Every page in this section is written so that a sceptical reviewer can check it rather than believe it.
A bounded first engagement that ends in a network topology and data-flow map you keep, whether or not you proceed.