Enter for every AI system. Some of its controls apply only where you integrate, configure or train it (B1), where it acts on its own (B3), or both. Go as deep as your system letter, and implement in your mode.
Why it exists
Treat every AI that can act as an employee you have just hired: it gets its own identity, only the access its job requires, and its keys back when it leaves. Every agent, assistant, and connector that takes actions does so under some identity, holding some credential — and the most damaging AI security failures are rarely a model saying something wrong. They are an autonomous component acting with more privilege than its task ever required: reading what it did not need to read, sending what it should never have been able to send. Privilege, not speech, is where the damage lives; scope it accordingly, and more tightly than you would for a person, because an AI acts faster, tirelessly, and with no instinct for when something feels wrong.
What to actually do
Give every agent and every connector its own identity — never a borrowed one. Do not let an AI act under a developer’s personal account or share a broad, powerful service account with other systems. Each acting component receives its own identity, with its own credentials, scoped to its own task. This is what makes least privilege possible, what makes an audit trail attributable — you can see what the agent did, as the agent — and what makes retirement clean: when the system is decommissioned (the Governance lifecycle), its identity is revoked and nothing else breaks. A borrowed identity can do everything its owner can do, and that is always too much.
Separate the power to read from the power to act, and put a human in front of the dangerous actions. An agent that can read your calendar and one that can send email in your name are different animals; grant the two capabilities separately, and never bundle them by default. For the actions that can do real harm — sending outside the organisation, moving money, deleting data, changing anyone’s access — require a human to approve the specific action at the moment it happens. A carefully written instruction telling the agent to be careful is not a control; a human approval the system cannot proceed without is. This is the technical enforcement of the reversibility rule you set in Governance: irreversible actions do not execute on a machine’s judgement.
Never let one agent hold all three dangerous properties at once. Three properties, combined in a single agent, form a complete data-theft pipeline: access to sensitive data; exposure to content from outside your control (documents, email, web pages — anything an attacker could have written); and the ability to communicate outward. An attacker who can plant instructions in the content such an agent reads can walk your data out through the agent’s own communication channel, with no further access of their own. For every agent workflow, deliberately remove at least one of the three — most often the outbound communication, or the exposure to untrusted content. Design the triangle broken; do not discover it whole in an incident report.
Where an agent must run code or act on systems, run that work in a room it cannot walk out of. Give the executing agent an environment that holds only what the task needs, reaches only where the task must reach, and is thrown away when the task ends — a single-use container or micro-virtual-machine, for example. This is the containment that decides how far a manipulated or mistaken action can travel: even where you cannot break the three-property combination in the design, isolating the execution shrinks what a compromised agent can touch to a disposable space, instead of your host, your network, and your data.
Issue credentials just in time; never bake them in. Prefer short-lived credentials, issued to the agent for the task at hand and expiring with it, over permanent keys stored in the agent’s configuration. A permanent key inside an agent walks out with the first successful manipulation of that agent — and keeps working for the attacker long after the manipulation is over. A credential that expires in minutes limits the theft to minutes.
Controls
Baseline3 controls
Control 89
Keep credentials out of code, prompts and configuration files.
BaselinePreventivedeployer or developer (deployer+)per system
What it is
Keys and tokens that let an AI component reach other systems are held in a secret store and injected at run time, never written into instructions or repositories.
How to implement it · Minimum rules
All keys and tokens an AI component uses live in a secret store (the secrets manager or the platform's secret settings)
Injected at run time by reference; never written in code, standing instructions, configuration files or repositories
Scan repositories, instructions and configuration for secrets by pattern before each release
Any secret found: revoke and rotate at once, then remove it from history
Secret-store access limited to named people and the component that needs each secret
How to start
Scan your repositories and AI configurations for keys, move each one into the secret store, and rotate every key that was exposed.
Evidence
The list of AI credentials held in the secret store and the latest clean scan report.
Mode: light / standard / full
light
Use the secret settings built into the hosting platform or the AI provider's console, managed by one named person.
standard
A shared secrets manager holds all AI credentials, with automated secret scanning in the code repository.
full
A central secrets service issues all AI credentials, scanning blocks any commit or release with a secret, and access is audited.
Control 90
Scope every AI to the least privilege its task requires, with read and act granted separately.
BaselinePreventiveall rolesper system
What it is
Reviewed whenever the task changes; unused powers are removed, not kept for convenience.
How to implement it · Minimum rules
For each AI, write its task and the data and systems that task needs; grant only those
Grant read and act separately (reading a calendar is not sending email); never bundle them by default
Use the narrowest scope offered: specific folders, mailboxes or tables, not whole drives or directories
Switch off connectors, plug-ins and integrations the task does not use
Review permissions whenever the task changes; remove unused powers rather than keeping them for convenience
How to start
For each AI system or tool, list what it can currently read and do, compare that with what its task needs, and remove the rest.
Evidence
The permission list per AI with the date and outcome of its last review.
Mode: light / standard / full
light
The person who administers the tool reviews its connector and permission settings and notes the result in a spreadsheet.
standard
System owners keep permission scopes per AI in the identity system and review them at each task change.
full
Identity and access management issues scopes per AI from approved role definitions and flags unused permissions automatically.
Control 91
Require in-the-moment human approval for high-impact actions.
BaselinePreventiveall rolesper systemagentic
What it is
External sending, payments, deletion, and access changes do not execute without a human decision, recorded.
How to implement it · Minimum rules
Actions that need approval: sending outside the organisation, payments or transfers, deleting data, changing anyone's access
The human approves the specific action, shown in full (recipient, amount, content), at the moment it happens
The agent cannot proceed without that approval; an instruction telling it to be careful does not count
No blanket or standing approvals for these actions
Record each decision: action, approver, time, approved or rejected
How to start
List the actions each agent can take, mark those in the four high-impact categories, and switch on a confirmation step for each.
Evidence
The list of gated actions per agent and the approval records.
Mode: light / standard / full
light
Use the confirm-before-acting setting built into the agent tool and keep its activity log.
standard
Approval steps are built into each agent workflow, with decisions logged in the workflow or ticketing system.
full
A central approval service gates high-impact actions for all agents, with logs reviewed by the security function.
Enhanced4 controls
Control 92
Assign a distinct identity to every agent and connector.
EnhancedPreventiveall rolesper system
What it is
No shared accounts, no inherited personal credentials; every action attributable to the component that took it.
How to implement it · Minimum rules
Each agent and connector gets its own service identity, registered with owner, purpose and system
No personal accounts and no service accounts shared across systems
Credentials bound to that identity only
Logs record every action under the identity of the component that took it
Identity register entry closed and the identity revoked when the component retires
How to start
List which identity each agent and connector uses today, then replace every personal or shared account with a dedicated one, starting with the most privileged.
Evidence
The identity register for AI components and logs showing actions attributed to them.
Mode: light / standard / full
light
Create one dedicated account per agent or connector in the tools you use, and list them in a spreadsheet with their owner.
standard
AI identities are created in the central identity system following a naming rule, and the register is reviewed each quarter.
full
Identities are provisioned automatically at deployment from the AI inventory, and attribution is monitored in security logs.
Control 93
Use short-lived, task-issued credentials instead of embedded permanent keys.
EnhancedPreventiveall rolesper system
What it is
Standing secrets in agent configuration are treated as findings to remediate.
How to implement it · Minimum rules
Credentials issued per task or session and expiring with it (typically minutes, at most hours)
Issued on request by the identity provider or token service, scoped to the task
No permanent keys in agent configuration; any found is logged as a finding with owner and fix date
Where a provider only offers permanent keys: keep them in the secret store, rotate on a fixed cadence, record the exception
Issuance and expiry of every credential logged
How to start
Identify the agents holding permanent keys and move the most privileged one to short-lived, task-issued tokens first.
Evidence
The credential-issuance configuration and the list of remaining permanent keys with their remediation status.
Mode: light / standard / full
light
Use the short-lived token option the tool or provider offers; where none exists, rotate keys on a calendar reminder.
standard
The identity system issues short-lived tokens to agents, and remaining permanent keys are tracked to closure.
full
All agent credentials come from a central token service on demand; permanent keys are blocked by policy.
Control 94
Execute AI-generated code and agent tool-calls in an isolated, ephemeral environment scoped to the task.
EnhancedPreventiveall rolesper system
What it is
Strong isolation from the host and other workloads, reach limited to what the task requires, and disposal at task end; where execution is a hosted feature, confirm the provider enforces the equivalent
How to implement it · Minimum rules
Run AI-generated code and agent tool-calls in a single-use container or micro-virtual-machine, isolated from the host and other workloads
The environment holds only the files and tools the task needs; no host folders mounted, no stored credentials
Network denied by default; only the destinations the task requires
Limits on CPU, memory and run time
Destroyed at task end; nothing persists to the next task
Hosted execution features: obtain the provider's confirmation that equivalent isolation and disposal apply
How to start
List every place where AI-generated code or tool calls run, and move the first one into a disposable sandbox with no network access.
Evidence
The isolation configuration and, for hosted features, the provider's written confirmation.
Mode: light / standard / full
light
Use only the provider's hosted execution feature and keep its documented isolation guarantees on file.
standard
Engineering runs agent execution in a standard sandbox template with network and resource limits.
full
A platform team provides a managed isolated-execution service that every agent must use, with monitoring of escape attempts.
Control 97
Record every agent-to-agent delegation, and let no agent grant another more authority than it holds itself.
EnhancedPreventivedeployer or developer (deployer+)per systemagentic
What it is
The delegation chain is logged and attributable; privilege cannot be amplified by passing a task from one agent to another.
How to implement it · Minimum rules
Log every delegation: delegating agent, receiving agent, task, permissions passed, time and originating request
Each agent has a documented authority ceiling: the tools, data and actions it may use
Delegated authority is a subset of the delegator's; any request for more is refused and logged
The chain is traceable back to the person or trigger that started it
High-impact actions keep their human approval wherever they sit in the chain
How to start
Map which agents can hand tasks to others, write each one's authority ceiling, and turn on delegation logging.
Evidence
The delegation logs and the per-agent authority ceilings.
Mode: light / standard / full
light
Limit delegation to the agent platform's built-in hand-off feature, keep its logs, and record ceilings in a short table.
standard
Engineering configures ceilings per agent in the orchestration layer and reviews delegation logs monthly.
full
The orchestration platform enforces ceilings on every hand-off, and delegation chains feed security monitoring with alerts on refused escalations.
Advanced2 controls
Control 95
Analyse every agent workflow for the three-property combination, and break it.
AdvancedPreventiveall rolesper system
What it is
Sensitive data, untrusted content, and outbound communication never coexist in one agent unmitigated; the removed leg is documented.
How to implement it · Steps
For each agent workflow, record whether it accesses sensitive data, reads content from outside your control, and can communicate outward
Where all three are present, remove one, most often outbound communication or exposure to untrusted content
If no leg can be removed, document the mitigation: human approval of every outbound message, isolation, fixed destinations
Record the removed leg, the reasoning and the decision owner in the workflow record
Repeat whenever the workflow gains a tool, data source or communication channel
How to start
Take the agent with the widest data access and complete the three-question analysis for it this week.
Evidence
The per-workflow analyses with the documented removed leg or mitigation.
Mode: light / standard / full
light
The person responsible for AI answers the three questions per agent in a spreadsheet and switches off the leg to remove.
standard
Analyses are part of the design review of every agent workflow, signed off by the security lead.
full
The analysis is mandatory in the agent release process, and the platform enforces the removed leg through policy.
Control 96
Revoke automatically on decommission.
AdvancedPreventiveall rolesper system
What it is
Retirement of a system (Governance lifecycle) triggers the revocation of its identities, credentials, and connections without manual chasing.
How to implement it · Minimum rules
Marking a system as retired in the lifecycle register triggers the revocation workflow automatically
Revokes: identities, credentials, tokens, API keys, connector authorisations and network allowlist entries
Every AI identity and credential is mapped to its system in the register, so nothing is missed
A revocation record lists items revoked and time; failures alert the owner
A periodic check finds orphaned identities with no live system
How to start
Link each AI identity and credential to its system in the inventory, then connect the retired status to the identity system's deprovisioning.
Evidence
Revocation records tied to retirements and the latest orphaned-identity check.
Mode: light / standard / full
light
A retirement checklist generated from the spreadsheet inventory, executed by the named owner the same day, with a monthly orphan check.
standard
Retirement opens a ticket that runs scripted revocation across the identity system, secret store and network rules.
full
The lifecycle register drives deprovisioning through the identity platform with no manual steps, and orphans are reported automatically.
Evidence
The secret store holding AI credentials and the scan showing none in code or prompts; The identity register for AI components; the permission scopes and their reviews; human-approval records for high-impact actions; the credential-issuance configuration; the per-workflow three-property analyses; revocation records tied to retirements. the isolation configuration for agents that execute code or act on systems. The delegation logs and the per-agent authority ceilings.