What are we allowed to run, and how is it locked down?
Baseline: 3Enhanced: 4Advanced: 29 controls
Who it applies to
Enter for every AI system. Some of its controls apply only where you integrate, configure or train it (B1). Go as deep as your system letter, and implement in your mode.
Why it exists
Decide what is allowed to run, and enforce that decision in the systems themselves — not in a document someone is supposed to remember. An AI estate that anyone can extend with any model, connected to any internal system, able to reach any address on the internet, is not an architecture; it is an open surface waiting for its first incident. The inventory you built in Governance tells you what exists. This dimension decides what is permitted, and locks each permitted component down.
What to actually do
Pin the exact model version in production; never run against a floating “latest”. Providers offer convenient aliases that always point to their newest model. Behind an unchanged name, the model itself changes when the provider ships an update — and with it the behaviour, the tone, and the security properties you tested, while not a single line of your own systems has changed. Fix the exact version in every production deployment, and make any change of version a deliberate, controlled event: reviewed, re-tested, and connected to the model-change warning you secured from the provider in the Sourcing dimension.
Run an approved-model list, and let nothing outside it reach production. Maintain an explicit list of which models, in which versions, may be used at all — for which kinds of use, by which teams. This is the same discipline you already apply to software: employees do not install arbitrary programs on company systems, and teams do not wire arbitrary models into company processes. A model not on the list does not reach production, whatever its benchmark scores; the list, not enthusiasm, is the gate.
Write the deployment rules as rules the systems enforce, not guidance a reviewer must remember. Express “this service may use this model, with these powers, on this class of data” as machine-checkable policy — rules your platforms verify automatically at deployment and at every call. Human review is essential and insufficient: reviewers rotate, forget, and are absent at three in the morning; enforced policy is not. The larger your AI estate grows, the more this single measure carries.
Treat the model’s standing instructions as controlled configuration — and keep secrets out of them. Most deployed AI systems are shaped by a standing set of written instructions that tells the model what it is, what it may do, and how to behave. Wherever those instructions materially determine behaviour, place them under change control like any critical configuration: versioned, reviewed, with a history of who changed what. And never put credentials, keys, or internal addresses inside them — attackers routinely trick models into revealing their instructions, and everything embedded there leaks the moment they succeed.
Limit where AI components can send data. An AI component that can reach any address on the internet is a ready-made channel for stealing data: an attacker who manipulates the system can make it transmit whatever it can see to wherever the attacker chooses. Deny outbound connections by default and allow only the specific destinations each component genuinely needs. This one restriction defuses a large share of the practical attacks against AI systems, because most of them end with an attempt to send something out.
Write the enforced rules in a policy language. “This service may use this model, with these powers, on this class of data” is expressed in a declarative policy language, versioned with the code, and evaluated automatically by the platform at deploy time and at call time.
Controls
Baseline3 controls
Control 80
Version every model you train or adapt.
BaselinePreventivedeveloperper system
What it is
Each trained artefact has a unique version identifier stored with the model and referenced in the inventory.
How to implement it · Minimum content
Version identifier: unique, never reused, stored in the model file's metadata and in the inventory
Base model and its exact version, if you adapted an existing one
Training-data snapshot reference, training code revision and key training settings
Fingerprint (hash) of the resulting model file
Date, author and the systems that use this version
Rule: every retraining or fine-tuning, however small, produces a new version
How to start
Agree a naming scheme (for example name-major.minor-date) and apply it to the models already in use, recording each in the inventory.
Evidence
The version register and the inventory entries showing which version each system runs.
Mode: light / standard / full
light
A named person keeps the versions in a spreadsheet and stores each model file in a folder named after its version.
standard
The training pipeline assigns the version and stores it in a model registry with the linked training record.
full
A central model registry assigns versions automatically and the deployment platform rejects any unversioned artefact.
Control 81
Pin exact model versions in every production deployment.
BaselinePreventivedeployer or developer (deployer+)per system
What it is
Version changes are controlled events with review and re-testing, never silent updates.
How to implement it · Minimum rules
Every production configuration names the full version identifier the provider publishes, never an alias such as “latest”
Covers all production calls: applications, integrations, scheduled jobs and agents
A version change is a change request: reason, new version, test results, approver
Before switching, re-run the system's test set and compare outputs with the current version
Provider notices of model changes or retirement go to the system owner with a planned switch date
How to start
List every production configuration that calls a model and replace any alias with the exact version identifier.
Evidence
The configuration showing pinned versions and the change record for each version switch.
Mode: light / standard / full
light
Whoever set up the integration fixes the version in its settings and notes each change, with a quick re-test, in a simple change log.
standard
Pinned versions live in versioned configuration and switches go through the normal change process with a documented re-test.
full
Automated checks reject any deployment that references an alias, and every version change triggers the test suite before approval.
Control 82
Place standing instructions under version control, with no secrets embedded.
BaselinePreventivedeployer or developer (deployer+)per system
What it is
Versioned, reviewed, and free of credentials, keys, and internal addresses.
How to implement it · Minimum rules
Store each system's standing instructions in a versioned repository or the platform's versioned configuration; no live editing
Every change records author, date, reason and a reviewer other than the author
Forbidden content: passwords, API keys, tokens, connection strings, internal hostnames and IP addresses
Scan instructions for secrets by pattern before each release
The deployed instructions always match a stored, reviewed version
How to start
Export the current standing instructions of each system into a versioned store, remove any credentials or internal addresses, and rotate any credential you found.
Evidence
The instruction version history with reviewers and the latest secret-scan result.
Mode: light / standard / full
light
Keep the instructions in a shared document with change history, and have a second person read every change before it goes live.
standard
Keep them in the code repository with peer review and an automated secret scan on each change.
full
Instruction changes pass through the release pipeline with mandatory review and secret scanning, and deploy only from the repository.
Enhanced4 controls
Control 83
Operate the approved-model list as the production gate.
EnhancedPreventiveall rolesper system
What it is
Models and versions approved per use, per team; nothing outside the list deploys.
How to implement it · Minimum content
Model or AI service name and exact approved version
Approved uses and the data classes allowed (e.g. public, internal, confidential, personal)
Teams or systems permitted to use it
Approver, approval date, conditions and what triggers re-approval (new version, new use)
Status: approved, under evaluation, withdrawn
Gate rule: deployment and purchase requests are checked against the list; anything absent is refused
How to start
Build the list from the AI inventory, mark each model in use as approved or to review, and announce that nothing new reaches production without being listed.
Evidence
The current list and the records of requests approved or refused against it.
Mode: light / standard / full
light
A named person keeps the list in a spreadsheet and checks it before any AI tool is bought, connected or deployed.
standard
The list lives in the change or procurement system, and every deployment or purchase request must reference an entry.
full
The list is held in a registry the deployment platform queries automatically, blocking any unlisted model or version.
Control 84
Maintain hardening standards per component type.
EnhancedPreventiveall rolesper system
What it is
A written secure-configuration standard for model services, agents, tools, and MCP servers and other connectors, applied at deployment.
How to implement it · Minimum structure
One section per component type: model services, agents, tools, MCP servers and other connectors
Required settings per type: authentication on, default credentials removed, logging on, debug off, rate limits
Network exposure: no public endpoint without approval; outbound destinations limited
Data settings: provider retention and training-use options, encryption in transit and at rest
Go-live checklist per type, signed before deployment; deviations recorded with owner and expiry date
Review when a new component type or provider is adopted, and at least annually
How to start
Write the standard for the component type you deploy most, using the settings of your best-configured instance, then extend it to the other types.
Evidence
The standards and the completed go-live checklists for each deployed component.
Mode: light / standard / full
light
A short checklist per type, kept by the person who sets up AI tools and filled in before each go-live.
standard
The security lead owns the standards and the checklist is part of the release process.
full
A platform team publishes the standards as configuration templates and checks deployed components against them automatically.
Control 85
Produce and maintain a written security standard for agents, tools, and MCP servers and connectors.
EnhancedPreventiveall rolesper system
What it is
Setting how much autonomy each kind of component may hold, how its tools and their parameters are constrained, how connectors and MCP servers are trusted and isolated, and what a component of each kind must satisfy before it is allowed to deploy
How to implement it · Minimum structure
Autonomy levels per kind of component: suggest only, act after approval, act alone within stated limits
Tool constraints: allowed tools per agent, parameter limits (amounts, recipients, file paths), read separate from act
Connector and MCP server trust: approved sources, verification before use, pinned versions, isolation from one another
Identity and credential requirements for each kind of component
Pre-deployment requirements: named owner, security review, tests passed, logging enabled
Exception route and annual review
How to start
Inventory the agents, tools and connectors in use, group them by kind, and write the autonomy level and pre-deployment checks for each group.
Evidence
The approved standard and the pre-deployment records showing each component met it.
Mode: light / standard / full
light
A two-page standard owned by the person responsible for AI, applied as a checklist before any agent or connector is switched on.
standard
The security lead maintains the standard and the architecture or change review checks each new component against it.
full
A dedicated function maintains the standard, encodes its constraints in the agent platform and blocks components that do not meet it.
Control 86
Manage models as controlled assets under a written model-management standard.
EnhancedPreventiveall rolesper system
What it is
A single register of which models exist in which versions, how each is approved for use, re-validated when it changes, checked for integrity, and retired — the discipline that binds the approved-model list to the integrity checks of the Model Integrity dimension
How to implement it · Minimum structure
Register: every model and version, owner, source, fingerprint, systems that use it
Approval: who approves a model for which use, and the link to the approved-model list
Change: re-validation and tests required when the version, provider or adaptation changes
Integrity: origin and fingerprint checks before first use and at load
Retirement: criteria, notice to users, removal from the list, revocation of access
Roles and annual review of the standard
How to start
Merge the inventory and the approved-model list into a single register, then write the approval, change and retirement rules around it.
Evidence
The standard, the register, and records of approvals, re-validations and retirements.
Mode: light / standard / full
light
One spreadsheet kept by the person responsible for AI serves as register and list, with the rules on a single page.
standard
The register lives in a model registry or asset system, and approvals and re-validations run through the change process.
full
A model-management function runs the registry, which drives approval, integrity checks and retirement automatically.
Advanced2 controls
Control 87
Enforce deployment rules as machine-checked policy.
AdvancedPreventiveall rolesper system
What it is
Model, powers, and data class verified automatically at deploy time and at call time.
How to implement it · Minimum rules
Policy per service: allowed model and version, permitted powers and tools, permitted data classes
Written in a declarative policy language, versioned with the code and reviewed like code
Deploy time: the pipeline refuses any deployment that violates the policy
Call time: the gateway or platform checks each model call against model, power and data class
Every denial logged with service, rule and reason; exceptions approved and time-limited
How to start
Express the approved-model list as the first rule enforced in the deployment pipeline, then add powers and data classes.
Evidence
The policy repository and the logs of denied deployments and calls.
Mode: light / standard / full
light
Use the provider's or platform's built-in allow rules for models and permissions, configured by the person who runs the deployment.
standard
Policies are written in the policy language and checked in the deployment pipeline, with call-time checks at a central gateway.
full
A platform team owns the policy set, enforces it at every deployment and call, and reports denials to security monitoring.
Control 88
Deny outbound connections by default for AI components.
AdvancedPreventiveall rolesper system
What it is
Each component reaches only its explicitly allowed destinations.
How to implement it · Minimum rules
Default rule: all outbound connections from AI components are blocked
Allowlist per component: the specific domains or addresses and ports it genuinely needs (model endpoint, named internal services)
Covers model servers, agents, code-execution environments and connectors
Addresses produced by the model (links, image URLs, callbacks) are not fetched unless allowlisted
Blocked attempts logged and alerted to the owner
Allowlists reviewed on every component change and at least every six months
How to start
Log outbound traffic from each AI component for two weeks to learn its real destinations, build the allowlist, then switch to deny-by-default.
Evidence
The allowlists per component and the log of blocked attempts.
Mode: light / standard / full
light
Apply the rule in the firewall or the hosting platform's network settings with a short allowlist kept by the IT provider; for hosted tools, turn off web access you do not need.
standard
Network and security teams maintain allowlists per component in the firewall or egress proxy, with alerts on blocks.
full
Egress is enforced centrally per workload, allowlists are versioned with the deployment, and blocks feed security monitoring.
Evidence
The approved-model list; version-pinning configuration; the instruction change history; the hardening standards and their application records; the enforced policy rules; the outbound-connection allowlists. the agents-tools-MCP security standard and the model-management standard.