D1 Deployed
No inference without the content policy.
The call must carry your pinned content policy version. Without it the provider refuses the call. This is the deny the other three protect.
The strongest control in this product is also the least interesting to look at, which is usually how you can tell.
A request without your content policy is refused before a model sees it.
Not a setting in an application. A deny statement in cloud identity policy, evaluated by the cloud provider on every call, on the chat role and on every module inference role. The application cannot remove it, because the credentials the application holds are the ones the deny is written against. This page is for the reviewer who wants to know what is actually holding, and what is merely configured.
Four statements, one effect.
THE FOUR DENIES
Four deny statements are attached to the chat role and to every module inference role in a deployment. A deny is absolute in cloud identity policy: no allow anywhere else can override it, which means no new role, no new function and no clever caller can get past it without a change to the infrastructure and a release. Each of the four closes a way round the others.
Enforced at every deployment
Asserted in the test suite
D2 Deployed
No inference off the governed route.
Inference must go through the governed routing construct the deployment defines. A direct call to a model, bypassing it, is refused, which closes the obvious way around D1.
D3 Deployed
No inference outside configured regions.
Only the endpoint regions the deployment declares may be used. A caller cannot reach a model in an undeclared region, which is what makes any residency statement enforceable rather than aspirational.
D4 Deployed
No widening of the retention election.
The account's data-retention election is a recorded decision. A workload cannot widen it for itself, so nobody can opt your account into provider-side sharing from inside the application.
What a deny does not do
These four control the path a request takes and the policy it carries. They do not read the request. What the content policy itself filters, denied topics and personal-information rules, is configured per deployment and empty by default, which means the filtering you get is the filtering you specify in policy advisory. Enforcement is ours. Content is yours.
Where a rule lives decides what it is worth.
WHY POLICY, NOT CODE
Outside the application
An application setting is a promise. A deny is a refusal.
The difference matters most in the cases nobody plans for: a new function added in a hurry, a script run by an engineer, an add-on written by somebody who never read the policy document.
- 01Different enforcer. An application check runs in code we wrote. A deny is evaluated by your cloud provider, in the same place it decides whether the credential may do anything at all.
- 02Different blast radius. An application check protects the path through that application. A deny covers every caller using the role, including a module backend and including a person holding the credential.
- 03Different failure mode. Break an application check and requests succeed without the policy. Break the deny attachment and requests stop. We prefer the failure that generates a phone call.
- 04Different evidence. A refusal is a provider-side authorization event with an identity on it, not a log line our application chose to write about itself.
authorization · chat inference role
DENIED
invoke-model --no-policy --region undeclared-region
[identity] role: chat-inference · caller: named principal
Governed route present✕ absent
Content policy version✕ not attached
Endpoint region declared✕ not in configured set
Retention election✓ unchanged
explicit deny · request refused before any model is reached
Illustrative outputAccessDenied
Refusal·Provider-side, with an identity on it
A policy with a number on it.
THE POLICY OBJECT
Pinned, never draft
Change it and you get a new version.
Your content policy is always a pinned, numbered version, never the mutable draft that most tooling defaults to, and the digest of the policy is recorded in the version description. Two consequences, both of which a reviewer will care about more than the policy text itself.
- 01Last quarter stays identifiable. An answer produced in March was produced under a version you can still name, whatever the policy says today.
- 02A change is an event. Editing the policy does not quietly alter the behaviour of a running deployment. It produces a new version, and the deployment points at the new number through a release.
- 03Administrators cannot touch it. Nobody in the running system can change the policy, the model allowlist, the posture or residency. Those are deploy-time parameters. Administration sets out exactly where the line falls.
The policy objectGOV-02
- FormNumbered versionNever the mutable draft
- IntegrityPolicy digest recorded in the version description
- ScopeEvery inference call, chat and module alike
- Changed byA release, with a new version number
- ContentsYours to defineDenied topics and personal-information rules are configured per deployment, empty by default
Pinned version·Digest recorded
Weaken a deny, break the build.
TESTS · SYNTHESIS LEVEL
A control that depends on nobody editing the wrong file is not a control. The denies are asserted where the infrastructure is synthesized, before anything is deployed, so the question "is this still attached" is answered by a test rather than by memory. Those assertions live inside roughly 2,700 automated test cases across about 170 test files, and the release tool runs the suite before a tag exists. No tag, no deployment.
release · test suite · governance assertions
FAILED
npm test -- governance
[synth] resolving posture object → infrastructure templates
D1 content policy required on chat role✓ attached
D1 content policy required on module inference roles✓ 3 of 3
D2 governed route only✓ attached
D3 endpoint regions✕ region set widened beyond posture
D4 retention election✓ attached
Plan page matches resolved posture△ not evaluated: build stopped
1 deny weakened · build failed · no tag cut · nothing deploys
Illustrative outputexit 1
Synthesis-level assertion·Runs before a release tag exists
And the page that describes it
The same suite compares the in-product plan page against the resolved posture object. One typed object drives the infrastructure, the page the signed-in client reads and the machine-readable export, and a test fails the build if the page and the exceptions table disagree. It is difficult to accidentally describe controls you do not have when the description is generated from the code that builds them.
An add-on cannot walk around the claim.
EXTENSIONS
The usual way a governed system quietly stops being governed is the extension: a new application, added later, that talks to a model on its own terms. The platform treats that as a build error rather than a policy question.
01 Deployed
Admission is fixed at deploy time.
What a module may reach is resolved from your parameter file into a recorded ceiling, and all of its identity policy is built from that ceiling when the infrastructure is deployed. It cannot ask for more at run time, and no administrator can grant more from inside the product.
02 Deployed
Same four denies, same roles.
A module that is admitted to call a model gets an inference role carrying the identical four denies. There is no second, looser path to a model for extensions, which is the only reason the word "every" is usable on this page.
03 Deployed
The claim defends itself.
Admitting a directly-inferring module on a posture that promises private inference fails the infrastructure synthesis, because that module's compute is not attached to the private network and would route around the promise. If you buy private networking, an add-on cannot quietly undo it.
Client modules in use today run on the staging channel, and the production promotion path is built and exercised on our own deployment. The controls described here apply on both channels. The full picture, including what is still in pilot, is on modules and developer modules.
A control changes through a release.
CHANGING A CONTROL
The next question a reviewer asks is how any of this changes once it is running. The answer is the same for all four denies, and it is deliberately narrow: a control is changed by editing the typed object your deployment is built from, cutting a release, and deploying from a pinned tag and a clean checkout. Not by a setting, not by an edit in the console, and not by anybody inside the product.
01 Deployed
One object, one way in.
The denies, the posture, residency and the model allowlist are deploy-time parameters resolved from a single typed object. Nothing in the running system can edit them, so a change to a control is a commit, a release and a deploy that can be pointed at afterwards.
02 Deployed
The tests are the guard.
Weaken a deny or widen a region list and the synthesis-level assertions fail, the build stops and no tag is cut. An override you ask for is written into the posture object with its reason, and shows on your in-product plan page as a standing exception.
It's not a black box. You can see how it's set up, and that's exactly what lets you answer for it.Which is what makes a change to it checkable
01Could you weaken a deny for a client who asked?
A control can be overridden, up or down, but not silently. An override carries a written reason in the posture object, appears as a standing exception on your in-product plan page, and is part of what your own reviewer sees. What cannot happen is a quiet edit: the denies are asserted in the build, so a change that weakens one has to be a deliberate, recorded act. See posture tiers.
02What exactly happens to a refused request?
The provider refuses the call and the platform returns a refusal with a reason rather than a downgrade. In the residency case the wording names the constraint: this model has no route inside your pinned jurisdiction. The user is told what stopped the request and which models can serve it instead.
03Does the deny apply to your own access as well?
Yes for inference: the denies are on the roles, not on user accounts, so any caller using them is bound. Separately, at the Baseline posture there is no cross-account role for us at all, and at Standard and Strict our access is scoped and session-capped, with its use recorded in your account audit trail. Shared responsibility sets out the rest.
04Does the content policy stop prompt injection?
No. A content filter is not a defence against an instruction hidden in a document, and we will not present one as if it were. The policy engine supports denied topics and personal-information rules, configured per deployment. It is a content control. What reduces the damage is the rest of the architecture: short-lived credentials tagged to a person, capability ceilings fixed at admission, and modules that mostly do not call a model at all.
05How would our auditor test these claims?
Read the policies attached to the inference roles in your own account, then attempt a call without the policy and watch it refuse. The controls matrix maps 17 technical control rows to SOC 2 Trust Services Criteria and ISO/IEC 27001:2022 Annex A with an enforced, partial or not-enforced verdict on each, and it is part of the evidence pack.
⎯⎯ Book the strategic assessment ⎯⎯
Your private AI, inside your control ·
Bring your security reviewer to the assessment. The controls on this page are easier to check than to describe.