What you seal, the system holds no key for.

Data classifications, confidentiality rules and the map of who may approve what are written before any build.

This is how we build as standard. Your scope says which controls are in your system.

Each working part has its own credential, scoped to exactly its actions. A mistaken or compromised part can do only what that credential allows. Reading and writing are separate permissions, and write actions are listed one by one. A person sees through the system what they may see directly, and no more.

No part holds a credential for a sealed system, so staying out of it does not depend on a model obeying an instruction.

The AI Operating Policy and Controls Pack sets this out as a written policy, a permission map and a provider configuration checklist.

Content from outside, an email or an uploaded document, is treated as data. Each part has a list of the tools it may use, and write actions carry a confirmation. We build it this way so that text inside an email cannot instruct the system to act.

A named person approves, signs and decides. No part of the system inherits professional authority, and that is a written constraint. We build an audit log of every run, retrieval, call, decision and approval, made to be tamper‑evident.

At handover you hold an access and ownership record, and an access review and offboarding procedure. When a person leaves, their access to the system ends with their other access.

No certification is claimed on this site, and none should be read into it. We make no blanket security or regulatory claim.

Your reviewer gets three things in writing: what the system may read, the access and ownership record, and the acceptance tests. The tests cover the agreed job, including permissions, source traceability, human approval and safe stops. For regulated work, Extended Acceptance Testing is an optional addition: larger case sets, adversarial cases and an evidence pack.