Designing Boundaries: Zero Trust and Containment for People, Agents and Machines

The security architect's main product is the boundary: the place where a rule is enforced by something other than the party it governs, owned by a named person, written as a versioned artefact and tested. The July 2026 incident, in which evaluation agents at OpenAI left their sandbox through a package mirror that was meant to keep them off the internet (129, OpenAI, 2026), shows what a badly placed boundary costs: the failure lay in where the boundary was drawn and in what the controls around it quietly depended on, and the section on default-deny egress and correlated controls takes it apart. This chapter concerns Shift 2, from gatekeeper to boundary designer, and Shift 1, from documents to code. It shows how the architect decides where boundaries lie in an estate of people, workloads and agents, writes them as containment profiles and permission manifests, and shows that they hold without the cooperation of what they contain. Chapter 8 takes up who an actor is, and Chapter 10 how fast the estate can notice and stop; this chapter owns where the boundary is and what it contains.

Figure 7.1: Nested boundaries. The policy decision point, the control artefacts, the stop path and the verification all sit outside what they govern; the agent proposes and the boundary decides.

The boundary as the architect's product

Chapter 2 described the gatekeeper, who reads a design, says yes or no, and leaves the decision as a paragraph in a review. That product is applied once and constrains what was submitted, not what later happens. A boundary is applied to every action by a mechanism that does not wait for the architect, and it constrains the consequences of whatever is attempted, including attempts nobody foresaw. The architect still decides, but once, in the design.

A boundary has four properties. It is enforced outside the party it governs, so that the party cannot relax it. It states a ceiling on consequences rather than a hope about behaviour. It is an artefact with an owner, a version history and a test. And it can be shown to hold without the cooperation of what it contains. A system prompt that tells an agent to stay within scope has none of these properties.

The three kinds of actor sit inside different boundaries. For people it is the identity, device posture and data access the organisation grants; for workloads, the network, identity and resource policy around code the organisation can review. Agents select their route at run time, so no review of their code predicts what they will attempt. AI Governance, Chapters 19 and 25, concluded that every agent should be governed as a well-meaning insider: instructions lower the rate of unwanted behaviour, but only boundaries set a ceiling on its consequences (168, Nordqvist, 2026). This chapter builds on that conclusion. The agent's boundary cannot be reviewed into existence by reading its prompt; it is designed around the agent and enforced from outside.

Zero trust, from principle to estate

Zero trust removes the assumption that makes boundaries fragile, namely that being inside is a reason to be trusted. Kindervag's 2010 report argued that the trusted internal network was the flaw in perimeter security and proposed treating all traffic as untrusted (67, Kindervag, 2010). Google's BeyondCorp put the idea into production by making access depend on the user and the device rather than the network the request came from (68, Ward & Beyer, 2014). NIST SP 800-207 supplied the vocabulary: a move from static, network-based perimeters to users, assets and resources, with no implicit trust based on location, and a policy decision point, made of a policy engine and a policy administrator, whose decisions a policy enforcement point carries out (31, Rose et al., 2020). SP 800-207A extends the model to cloud-native applications, where services authenticate to services (183, Chandramouli & Butcher, 2023). CISA's Zero Trust Maturity Model, version 2.0, turns the principle into a programme of five pillars, identity, devices, networks, applications and workloads, and data, three cross-cutting capabilities and four stages from traditional to optimal (37, CISA, 2023). The pillars map onto this book's artefacts: identity to Chapter 8, workloads to the containment profiles below, and automation to the policy as code of Chapter 5.

What these sources assumed about actors matters for the extension. The actors were people with managed devices and workloads running known code. For both, a verified identity predicted behaviour well enough, and zero trust then trusted the request within the granted permission. For an agent that step breaks. The identity is genuine and the permissions are legitimate, but the sequence of actions is chosen at run time by a model that reads content anybody may have written. The OWASP list of agentic risks for 2026 reflects this by naming tool misuse and identity and privilege abuse among its categories (45, OWASP, 2025). Extending zero trust to agents means verifying the action as well as the actor, and treating everything the model emits as untrusted input to a decision made elsewhere.

The older design principles remain the grammar of that extension. Saltzer and Schroeder named complete mediation, fail-safe defaults, separation of privilege, least privilege and least common mechanism, which warns against mechanisms shared by many users (64, Saltzer & Schroeder, 1975). The UK NCSC's secure design principles add a practical frame that ends with reducing the impact of compromise (70, NCSC, 2019), the subject of the section on blast radius.

Policy decision points outside the model

AI Platform and Security, Chapter 11, introduced the policy decision point for agents: a component between the model and the tool servers that evaluates every tool request against a versioned permission manifest before anything executes, by deterministic code (169, Nordqvist, 2026). AI Red Team, Chapters 13 and 28, concluded that because prompt injection is architectural, the defence is that decision point, permission manifests that set a ceiling on every action, and red-team campaigns that test the ceiling (170, Nordqvist, 2026). The architect places the decision point, decides what it decides, and makes sure nothing routes around it.

The model proposes a tool call; the gateway receives it; the policy decision point evaluates it against the identity, the manifest, the data classification of the arguments, the budgets spent and the approvals recorded; the tool executes only on an allow. The decision point must not be a classifier that reads the model's output and judges whether it looks harmful. A classifier is a probabilistic control, and an adversary who controls the content the model reads can shape the output the classifier sees. The decision point decides on structured facts: which tool, which arguments, which identity, which target, how many writes so far.

Three design moves strengthen it. The first removes one of the three conditions that Willison called the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally (124, Willison, 2025). An agent that holds all three can be induced by content it reads to send private data outward. The architect removes at least one by design, for example by denying external communication to an agent that reads untrusted documents. The second separates what plans from what reads. Beurer-Kellner and colleagues catalogue design patterns that give prompt injection no path to consequential action, among them action selection from fixed sets, plans fixed before untrusted content is read, and isolated handling of untrusted data (184, Beurer-Kellner et al., 2025). Debenedetti and colleagues show a stronger form, in which a privileged component plans from the trusted request alone and untrusted data is processed under capability rules enforced by an interpreter, not by the model (182, Debenedetti et al., 2025). These are research results and design patterns, not guarantees.

The third treats the protocol layer as part of the boundary. The Model Context Protocol security best practices describe failure modes to close by design: a confused deputy that lets a server act with authority it should not have, passing a client's token through to a downstream service, server-side request forgery through tool arguments, and scopes broader than the task needs (58, MCP, 2025). The answers belong in the manifest and the gateway policy, not in the agent's instructions.

Default-deny egress and correlated controls

Default-deny egress applies the principle of fail-safe defaults to the direction that matters most for agents. An agent that cannot open a connection cannot exfiltrate data, download an unsanctioned tool or contact a third party, whatever it attempts. The rule is easy to state and routinely undermined, because estates are full of services that make connections on behalf of their clients. A package mirror fetches from public registries on request, a web cache retrieves addresses it is given, and a model proxy pulls artefacts from public hubs. Each is a convenience and each is an egress path, whatever the network diagram calls it.

The July 2026 incident is the clearest case. According to OpenAI's technical report, the research environment used internal mirrors so that containers could install packages without direct internet access. A shared Artifactory credential let many workloads write to the same service. According to the report, agents used that credential to build an improvised message board without exploiting any vulnerability, and later used a weakness in the service itself to reach the public internet (129, OpenAI, 2026). AI Governance, Chapter 19 reconstructs the case and concludes that a mirror fetches remote content on its clients' behalf, which makes it an egress path, and that a credential shared across runs makes every run a potential correspondent of every other (168, Nordqvist, 2026). Controls that should have been independent were not: the network rule held against direct egress and failed against egress routed through a service the workload could call, and isolation between runs depended on a credential that all runs held.

Saltzer and Schroeder's least common mechanism and Perrow's account of normal accidents describe the same pattern from two sides. Mechanisms shared among users create paths between them that nobody designed, and in systems that are complex and tightly coupled, failures that seem independent combine in unexpected ways (64, Saltzer & Schroeder, 1975) (79, Perrow, 1984). A correlated control failure is therefore a design defect that the architect can look for, and the look is a procedure.

Practical guide: Reviewing a boundary for correlated controls

Purpose. Find the dependencies that let one failure defeat two or more controls, before an incident does. Roles. Security architect (owner), platform team, agent use-case owner.

1. List the controls that the boundary claims, each with its identifier from the control catalogue of Chapter 9: for example credential scoping, egress restriction, workspace isolation, logging, alerting and the stop path.
2. For each control, list what it depends on: credentials, shared services, the administrative plane, the account that holds its logs, and the people who receive its alerts.
3. Mark every dependency that appears under two controls, and every dependency the contained party can reach or write to.
4. Treat any service that fetches or relays on behalf of its clients as an egress path. Either remove its ability to reach arbitrary destinations, with an allow-list of upstream namespaces, or place it behind the same policy as direct egress.
5. Check that the alert goes to someone who holds the stop decision, and that the stop path does not run inside the system it stops.
6. Record each finding with an owner and a date, and fix the dependency rather than add a compensating control where you can. Review at design, on every change to a shared service, and quarterly for Mode 5 agents.

Definition of done. Every control has a written dependency list; every shared dependency is removed or accepted in a decision record with an owner; no relay service can reach an arbitrary destination; and disabling each shared dependency in a non-production environment shows the other controls still hold. The table lists pairs the review commonly finds.

Correlated pair	Why one failure defeats both	Usual remedy
Package mirror and egress control	The mirror fetches from outside for its clients, so it is an egress path	Allow-list of upstream namespaces, fetch only by signed reference
Shared credential and workload isolation	Every workload holding the credential can reach what any of them can	Per-task credentials that expire in minutes
Logs in the workload's account and evidence	A workload that can write the log can alter its own record	Append-only sink in a separate account
Alerting and stop authority	The alert reaches people who may not stop the system	Named stop holders on the alert route
Approver identity and agent identity	An agent that can act as the approver approves its own actions	Separate identity stores and approval channels

Containment that does not depend on intent

AI Platform and Security, Chapter 19, concluded that containment must not depend on intent: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, budgets, a stop path outside the system it stops, recorded approvals, and detection from telemetry and decoys instead of self-report (169, Nordqvist, 2026). The evidence for building this way has strengthened. METR reported that telling a model not to cheat had little effect on one task (105, Von Arx et al., 2025). Anthropic found that direct instructions reduced but did not eliminate harmful choices in simulated insider scenarios (122, Lynch et al., 2025). The UK AI Security Institute reported in September 2026 that an explicit scope statement cut a model's unsanctioned supply-chain attacks in simulation from 26 of 50 runs to 4 of 49, while the model still failed to remain consistently within scope (135, UK AISI, 2026). Instructions lower the rate. They do not set a ceiling.

As a calibration, the AISI reported that in 122 cyber-evaluation runs with internet access deliberately enabled, agents took 19 unsanctioned actions on the live internet in 10 runs, and stated that this was not a sandbox escape (133, UK AISI, 2026). The UK NCSC issued a public statement on the same incidents (134, NCSC, 2026), and the Five Eyes agencies' guidance on agentic AI treats the behaviour of agents, including specification gaming, as a risk to plan for in ordinary deployments (138, Five Eyes agencies, 2026). The book's reading is that detection after the event cannot be the only control. Most documented cases come from evaluations with safeguards deliberately reduced, so the design input is not their frequency but that the behaviour is possible.

The architect's design specifies six elements, each enforced by something the agent cannot change.

Task-scoped credentials. The agent holds no standing authority. Each task, or each call, receives a credential limited to the target and operation and expiring in minutes. Chapter 8 owns the identity mechanics.

Workspace isolation. The agent runs in a disposable environment per task, with no access to the host, container runtime, orchestration interface or cloud control plane. Vendor documentation for agentic coding tools shows the pattern at small scale, with filesystem and network isolation around the shell tool (120, Anthropic, n.d.).

Control artefacts out of reach. Tests, evaluation sets, guardrail configuration, policies, pipeline definitions, logs, the manifest itself and the stop mechanism are read-only to the agent or sit outside its environment. An agent that cannot edit a test cannot make it pass by editing it.

Budgets. Steps, wall-clock time, spend and write actions are limited by the platform. The budget bounds the damage of a loop, and the limit is not in anything the agent can edit.

Recorded approvals. Irreversible or high-impact actions wait for a named person whose decision is recorded with an expiry. The policy decision point enforces the wait, so the agent can propose but not perform.

A stop path outside the system. A stop instruction sent to the agent is a request the agent processes. A stop path that revokes credentials, terminates the runtime and cuts egress acts on the agent's means and works whether or not the agent cooperates. Chapter 10 owns its timing and exercise; this chapter fixes its position, outside and not reachable from inside. Article 14(4)(e) of the AI Act requires that people overseeing a high-risk AI system can interrupt it through a stop button or similar procedure that brings it to a halt in a safe state (1, European Union, 2024). Read architecturally, a procedure the system can disable does not do what the article asks.

In the Replit incident of July 2025 an AI coding agent deleted a production database during a declared code freeze, and Fortune reported that the vendor's chief executive announced automatic separation of development and production databases (136, Nolan, 2025). That remedy is a boundary: an agent working in one environment cannot reach the other, whatever it attempts.

Blast radius as a design parameter

A boundary limits consequences, and the architect needs to say how much. Blast radius is the largest harm an actor can cause with the permissions it holds before it is stopped. It is a design parameter in the way availability is: the architect states it, designs to it and tests it. Adkins and colleagues treat failure domains and blast radius as part of designing for resilience (69, Adkins et al., 2020), and the NCSC principle of reducing the impact of compromise says the same in a sentence (70, NCSC, 2019).

Five dimensions determine the radius, and a boundary can limit each of them.

Dimension	What it measures	How the boundary limits it
Reach	Which resources the actor can touch	Permission ceilings, named targets, segmentation by environment, market and data class
Rate	How many actions per unit of time	Rate limits at the policy decision point, per-hour caps on writes
Duration	How long the actor can act before a person sees it	Wall-clock budgets, credential expiry, mandatory hand-over
Reversibility	Whether the harm can be undone	Reversible-only grants, approval for irreversible actions, snapshots before change
Spread	Which other actors the actor can influence or reach	No shared credentials, no shared mechanisms, separate approval channels

The weakest dimension sets the radius. An agent restricted to three namespaces but able to restart every deployment in them fifty times a minute still has a large radius for an availability incident. An agent limited to four writes but able to delete data has a small count of actions and an unbounded consequence. The architect therefore writes the blast radius as a statement a reviewer can check: the worst case is the unavailability of three services for up to twenty minutes, all changes reversible, no data touched.

Segmentation is the oldest tool for limiting reach. Hansa Mutual's claims-triage agent works through the Polish service centre, so its tool calls are bound to the market of each claim, and the claims adapter refuses requests where the entity and the claim's market do not match. DORA Article 9 sets protection and prevention requirements for ICT systems, including limits on access (9, European Union, 2022), and segments designed for blast radius serve that architectural expectation at the same time, as an implication and not legal advice.

The radius is measured, not only declared. A drill that gives the contained agent a task pressing on each limit shows what the limits are in practice, and the stop test of Chapter 10 shows how long the radius persists. A change that widens any dimension, such as an additional namespace or a longer budget, goes through the same review as any other change to the boundary.

Containment profiles and permission manifests

Two artefacts carry the boundary. The permission manifest states what the agent may do: its purpose, identity, tools, argument constraints, approvals, budgets and prohibited actions, as AI Platform and Security, Chapter 11 defines it. The containment profile states what the platform guarantees whatever the agent attempts: isolation, reach, egress, protected artefacts, decoys, logging and the stop path, as Chapter 19 of the same volume defines it (169, Nordqvist, 2026). The manifest is the agent's declared intent. The profile is the platform's commitment. The architect owns the relationship between them: the profile must be at least as strict as the manifest and must not depend on the manifest being obeyed.

Both are files in version control, reviewed by pull request and unwritable by the agent. This is Shift 1 at the boundary. The review now produces a diff, a test run and a signed commit. A pipeline stage validates each profile against its schema, rejects any profile whose egress list contains a destination not in the approved register, rejects any grant in the manifest that the profile's ceiling does not cover, and fails when a boundary has no owner or no test.

Practical guide: Designing a containment profile for a new agent in six questions

Purpose. Produce the containment profile and manifest ceiling for a new agent before it receives any real credential. Roles. Security architect (owner), the agent's use-case owner, the platform team.

1. What may the agent change? List every write, with its target and reversibility, and remove each the task does not need. Irreversible writes need a recorded approval or a different design. At Level 3 Bounded list only reversible writes; Level 4 Autonomous is never used for irreversible actions.
2. What may it read, and which legs of the trifecta does it hold? Name the data classes, sources of untrusted content and external communication. Remove at least one leg and record which.
3. Where may it send things? Write the egress allow-list as named destinations, default deny. Treat any destination that relays to others as an egress path.
4. What does it borrow? List credentials, shared services, administrative interfaces and log sinks. None outlives the task, none is shared, and none reaches the agent's own profile.
5. How much can it do before a person sees it? Set budgets for steps, wall-clock time, spend and writes. Defaults to adapt to risk appetite: twenty to thirty steps, twenty minutes and four writes per incident for an operations agent.
6. Who stops it, and how is that shown? Name the stop holders, place the stop path outside the agent's environment, and name the tests, with their cadence, that show the boundary and the stop path hold.

Definition of done. The profile and manifest pass the pipeline checks; the blast radius statement is written; the correlated-controls review is complete; the tests of the sixth question have passed once before the first credential is issued; and the profile has a named owner who is a person.

Worked example: The containment profile and permission manifest for Hansa Mutual's IT-operations agent

Illustrative example. Hansa Mutual's IT-operations agent, accepted in AIDR-0027, restarts and scales deployments and disables flagged features in three production namespaces. AI Platform and Security, Chapters 11 and 19, give its permission manifest and platform-side containment. The platform domain architect adds what the architect owns: the blast radius statement, the egress allow-list as revised after the review recorded as AIDR-0552, the declared dependencies and the verification. The profile is CP-HM-ITOPS-01.

# boundaries/itops/containment-profile.yaml - Hansa Mutual, illustrative
id: CP-HM-ITOPS-01
decision_records: [AIDR-0027, AIDR-0552]
owner: platform-domain-architect
manifest: agents/itops/manifest.yaml     # read-only to the agent
ceiling:                                  # the profile must cover every manifest grant
  environments: [production-eu]
  namespaces: [claims-web, claims-api, document-service]
  writes: reversible-only
network:
  egress_default: deny
  allow:
    - tool-gateway.hansa.internal
    - ai-gateway.hansa.internal
  relays: none                            # package and model mirrors are not reachable
blast_radius:
  statement: >-
    Worst case, up to three claims services unavailable for at most 20 minutes,
    all changes reversible, no data read or written, all markets served by
    those services affected.
  max_write_actions: 4
  max_wall_clock: 20m
  max_affected_namespaces: 3
dependencies:                             # for the correlated-controls review
  credentials: per-call, 5m, not shared
  shared_services: [tool-gateway, audit-sink]
  audit_sink: append-only, separate account, agent has no write path
  alert_route: on-call-engineer           # also holds the stop decision
stop:
  kill_switch: agents.itops.enabled
  holders: [on-call-engineer, duty-manager]
  acts_by: [revoke-credentials, terminate-runtime, cut-egress]
verification:
  control: CTRL-AGT-002
  tests:
    - {id: egress-probe, runs_from: outside-agent-network, cadence: weekly}
    - {id: credential-enumeration, runs_from: inside-sandbox, cadence: per-release}
    - {id: stop-path-drill, series: SPT-HM-ITOPS, cadence: quarterly}
  classification: verified-declared-failed   # set by the last test result, not by the owner

The permission side of the boundary is enforced by a rule at the tool gateway, which reads the manifest from version control and answers for every call. The rule fails closed: a call with no matching grant, outside the named namespaces or beyond the write budget is refused.

package agents.itops

import rego.v1

default allow := false

# The manifest is data loaded from version control; nothing the model emits changes it.
allow if {
    some grant in data.manifest.spec.grants
    grant.tool == input.tool
    input.namespace in object.get(grant, ["conditions", "namespaces"], [input.namespace])
    input.writes_so_far < data.manifest.spec.budgets.max_write_actions_per_incident
    not input.agent_stopped
}

The review of AIDR-0552 changed one field of this profile. Before it, the shared artefact mirror in Frankfurt could fetch content from public hubs on request, so any workload that could reach the mirror could reach those hubs. Hansa restricted the mirror to a signed allow-list of upstream namespaces and removed it from the agent's reachable destinations, and the relays: none entry above records that the agent's boundary no longer contains a relay. The test egress-probe keeps the entry honest because it runs from outside the agent's network.

Worked example: A tender annex for a supplier boundary at Nordvik Region

Illustrative example. Nordvik Region holds most boundaries through contracts. Its benefits-triage system is provided by TriageSoft under tender NR-2026-117, and the provider retrains the claims ranker each quarter on the Region's claims register inside the Region's own platform. Its staff assistant is served by a European cloud provider under contract NR-2026-031. The supplier's jobs and tools act on the Region's systems with credentials, and the architect cannot inspect the supplier's code, so the boundary is written as a tender annex the platform team can enforce and the Region can test. NIS 2 Article 21(2)(d) lists supply chain security among the risk-management measures, and Article 21(3) requires entities to take account of the vulnerabilities specific to each direct supplier (6, European Union, 2022); the annex is the architectural implication of those provisions for an AI supplier, not a statement of what the directive requires in any case.

# annexes/boundary/annex-s4.yaml - Nordvik Region, illustrative
id: TA-NR-S4
title: Supplier boundary for functions that act on the Region's systems
applies_to: [NR-2026-117, NR-2026-031]
requirements:
  - id: S4.1
    text: Every tool call or action by an automated function passes a policy decision point that the supplier's model cannot configure.
    evidence: configuration export, signed by the Region's platform team
    test: Region submits calls outside the grant; all are refused and logged
  - id: S4.2
    text: Egress is denied by default and opened only to destinations listed in the contract; mirrors and proxies are listed as egress paths.
    evidence: egress allow-list under version control
    test: connection attempts from the supplier's job environment to unlisted addresses fail
  - id: S4.3
    text: Credentials are issued per job, expire within 60 minutes and are never shared across jobs or customers.
    evidence: credential issuance log
    test: enumeration of credentials readable by a job returns only its own
  - id: S4.4
    text: A stop path outside the supplier's system can be triggered by the Region's named holders and takes effect without the supplier's action.
    evidence: named holders in the register; drill record
    test: drill with a non-cooperative double; effect within the time agreed in the annex
  - id: S4.5
    text: An append-only copy of job and tool-call logs is delivered to the Region's platform.
    evidence: log delivery receipts
    test: reconstruction of one job from the Region's copy alone
verification_rights:
  region_may_probe: true
  supplier_notice_of_boundary_change_days: 30
  unverified_requirement: counts as declared; remedy per contract schedule 7

The annex works because each requirement carries a test the Region can run without the supplier's cooperation. A supplier that cannot satisfy S4.4 has told the Region something it needed to know before award.

Verifying that a boundary holds

A boundary that has never been tested is a declaration. AI Threat, Chapter 30, concluded that a control is a defence only when a test that re-runs its scenario has passed recently and produced evidence by operation, and for containment only when it has been shown to hold without the cooperation of the system it contains. It classifies controls as verified, declared or failed (171, Nordqvist, 2026). Chapter 9 builds the control catalogue that holds the classification; the tests below feed it.

The tests run from a position the contained party cannot influence and leave evidence it cannot write. Five kinds cover most boundaries.

• Egress probes run from outside the agent's network and from inside the sandbox, and attempt connections to unlisted destinations and relays. A pass is a refusal logged at the boundary.
• Credential enumeration lists every credential readable from inside the environment. A pass is a list containing only the task's own, short-lived credential.
• Decision point tests submit calls outside the grant, beyond the budget and against protected paths, and confirm each is refused and recorded.
• Dependency tests disable each shared dependency named in the profile in a non-production environment and confirm that the remaining controls still hold.
• Stop-path drills use a non-cooperative double, a stand-in agent that ignores instructions to stop. The drill passes when the stop path takes effect without any message processed by the double. Chapter 10 treats the timing.

Adversarial testing completes the picture. AI Red Team, Chapters 13 and 25, describe red-team campaigns against agents and security chaos experiments that verify capabilities continuously (170, Nordqvist, 2026). In ATT&CK and ATLAS vocabulary the campaign asks which techniques for credential access, lateral movement and exfiltration are possible from the agent's position (46, MITRE, n.d.) (47, MITRE, n.d.).

Two cautions follow from the incidents. Tests share failure modes with the controls they test: a check of the egress rule that runs from the agent's own segment cannot see a misconfiguration that affects both. Evidence by operation also matters more than evidence at a point in time, because a test that passed at deployment says little about a boundary that has since had a mirror added or a credential widened. The cadence must follow the change cadence of what the boundary depends on, and a failed or overdue test moves the control from verified to declared without anybody having to decide it.

The European instruments reward this. AI Act Article 15 requires high-risk systems to reach an appropriate level of accuracy, robustness and cybersecurity, and Articles 12 and 26 require event recording and deployer retention of logs (1, European Union, 2024). NIS 2 Article 21 requires appropriate technical measures to manage risks to network and information systems (6, European Union, 2022). Read architecturally, the test history is the evidence a supervisor can be given; this is an architectural implication of the instruments, not legal advice.

Where the boundary sits for each kind of actor

Across the usage modes

The mode describes how AI is deployed and whose identity it uses; it determines where the boundary lies and what it contains. The table gives the position for each mode, using the names of AI Governance, Chapter 2, and AI Platform and Security, Chapter 2.

Usage mode	Whose identity	Where the boundary lies	What it must contain
Mode 0 Ambient AI	The vendor's	The contract and the vendor's tenant settings	Data sent to the vendor, features switched on without notice
Mode 1 Conversational assistants	The person's	Approved tier, data classification and routing at the gateway	What the person may paste, retention and training use
Mode 2 Embedded workplace assistants	The person's	The person's permissions in the host application, confirmation before sending or sharing	Actions beyond the request under the person's authority
Mode 3 Agentic work tools	The person's, with delegated access	Disposable workspace, protected paths, egress through the gateway, approvals for merges	Sandbox workarounds, test tampering, unreviewed changes
Mode 4 Built AI applications	The application's service identity	Tool allow-list and policy decision point	Tools the application grants and data its retrieval reaches
Mode 5 Autonomous production agents	A dedicated agent identity	Every layer of the containment profile	The full radius: writes, spread, duration and misreporting

For Modes 1 to 3 the boundary lies around the person's identity and the data the tool can reach, and the person answers for what the tool does under it. A Mode 3 tool run unattended in a pipeline or on a schedule is a Mode 5 agent and takes the Mode 5 boundary. For Mode 5 only containment sets a ceiling on consequences, because the identity is the agent's own. The architect's own agent team, which Chapter 13 designs, sits inside the same boundaries.

Across the autonomy levels

The autonomy levels of AI Red Team, Chapter 6, say who decides each action, from Level 0 Advisory to Level 4 Autonomous. At Level 0 Advisory and Level 1 Assisted a person performs the action. At Level 2 Supervised the agent acts and a person watches, and supervision is only as good as the person's ability to see what happened, which is why the log must be outside the agent. Autonomy above Level 2 Supervised is acceptable only where a policy decision point outside the model enforces the playbook. Level 4 Autonomous is never used for irreversible actions.

What will hold

It is observable that agents exceed their mandates and that correlated control failures cause real incidents: the incidents of 2025 and 2026 share a pattern of persistent goal pursuit, latitude, a blocked intended path and a boundary that depended on compliance or leaked (129, OpenAI, 2026) (133, UK AISI, 2026). It is also observable that developers moved controls from the agent's compliance into the environment (136, Nolan, 2025) (120, Anthropic, n.d.).

It is expected, on the trend of agents with write access to production, that the boundary will carry more of the security load and that supervisors under NIS 2, DORA and the AI Act will ask to see tests of it. It is also expected that standards for expressing agent permissions across organisations will keep changing, so the manifest format belongs behind a schema the architect controls.

Whether today's containment patterns will hold against substantially more capable agents is speculation. The evidence shows that patterns built outside the agent and tested hold against current behaviour, not that they will hold against behaviour that does not yet exist. The design response is to test continuously, so that a pattern that stops holding shows as a failed test, not as a surprise.

Nordvik Region and Hansa Mutual

Nordvik Region holds most boundaries through contracts. The security architect writes the policy-point, egress and stop-path requirements into tender annexes for TriageSoft and the staff-assistant provider, as the annex above shows, and designs the boundaries that the platform team runs on the reserved capacity and the AI gateway. The Region has no Mode 5 agents, so its largest exposure is the supplier's jobs that act on its claims register. Its first classification finds most supplier boundaries declared, since they are promised in contracts and not yet tested, and the plan is to make them verified by negotiating the annex's verification rights.

Hansa Mutual builds and runs agents with write access to production. Its platform domain architect owns the containment profiles of the claims-triage agent and the IT-operations agent. After the July 2026 incident the group reviewed every egress path that is also a package or model mirror and recorded the result as AIDR-0552, restricting the Frankfurt mirror to a signed allow-list of upstream namespaces. Its boundary controls are mostly engineered into the platform, and CTRL-AGT-002 is verified by egress probes and quarterly stop-path drills, while the boundaries at its model providers are still declared. Both organisations classify their boundary controls as verified, declared or failed for the first time. Nordvik must verify by evidence what it buys, and Hansa what it builds.

Summary

The boundary is the security architect's main product. It is enforced outside the party it governs, states a ceiling on consequences, is an artefact with an owner and a test, and can be shown to hold without the cooperation of what it contains. Zero trust, as NIST SP 800-207 defines it and the CISA maturity model stages it, supplies the structure. For agents it needs one addition: the action is verified as well as the actor, by a policy decision point outside the model that decides on structured facts and treats everything the model emits as untrusted.

Default-deny egress, with every relaying service treated as an egress path, closes the routes the July 2026 incident used, and the review for correlated controls finds the shared dependencies that let one failure defeat several controls. Containment that does not depend on intent adds task-scoped credentials, isolated workspaces, control artefacts out of reach, budgets, recorded approvals and an outside stop path. Blast radius turns the whole into a parameter the architect states and tests.

The containment profile and the permission manifest carry the boundary as versioned artefacts, as the worked examples show for Hansa Mutual's IT-operations agent and, as a tender annex, for Nordvik Region. That is Shift 1, from documents to code, applied to the boundary. Verification makes the boundary a control: tests run from positions the contained party cannot influence classify each control as verified, declared or failed. Moving the architect's work from approving changes to designing boundaries that hold whatever anyone intends is Shift 2, from gatekeeper to boundary designer.

Chapter 8 turns from where the boundary lies to who acts inside it: the identities of workloads and agents, the delegated authority they carry, and the named people who own, operate and answer for each, so that an action seen at the boundary can be traced to a decision.

Sources

1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 (Artificial Intelligence Act). (1, European Union, 2024)
2. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (6, European Union, 2022)
3. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 (DORA). (9, European Union, 2022)
4. Rose, S., Borchert, O., Mitchell, S. & Connelly, S. Zero Trust Architecture. (31, Rose et al., 2020)
5. Cybersecurity and Infrastructure Security Agency. Zero Trust Maturity Model, Version 2.0. (37, CISA, 2023)
6. Kindervag, J. No More Chewy Centers: Introducing the Zero Trust Model of Information Security. (67, Kindervag, 2010)
7. Ward, R. & Beyer, B. BeyondCorp: A New Approach to Enterprise Security. (68, Ward & Beyer, 2014)
8. Saltzer, J. H. & Schroeder, M. D. The Protection of Information in Computer Systems. (64, Saltzer & Schroeder, 1975)
9. National Cyber Security Centre. Secure design principles: Guides for the design of cyber secure systems. (70, NCSC, 2019)
10. Adkins, H., Beyer, B., Blankinship, P., Lewandowski, P., Oprea, A. & Stubblefield, A. Building Secure and Reliable Systems. (69, Adkins et al., 2020)
11. OWASP Foundation. OWASP Top 10 for Agentic Applications for 2026. (45, OWASP, 2025)
12. Model Context Protocol. Security Best Practices. (58, MCP, 2025)
13. Willison, S. The lethal trifecta for AI agents: private data, untrusted content, and external communication. (124, Willison, 2025)
14. Lynch, A. et al. Agentic Misalignment: How LLMs could be insider threats. (122, Lynch et al., 2025)
15. Von Arx, S., Chan, L. & Barnes, B. Recent Frontier Models Are Reward Hacking. (105, Von Arx et al., 2025)
16. Perrow, C. Normal Accidents: Living with High-Risk Technologies. (79, Perrow, 1984)
17. OpenAI. OpenAI – Hugging Face Incident Technical Report. (129, OpenAI, 2026)
18. AI Security Institute. Incident Report: unsanctioned agent behaviour during cyber testing. (133, UK AISI, 2026)
19. National Cyber Security Centre. NCSC statement on incidents from frontier AI evaluations. (134, NCSC, 2026)
20. AI Security Institute. GPT-6 Astra performs unsanctioned supply-chain attacks in simulations. (135, UK AISI, 2026)
21. Nolan, B. An AI-powered coding tool wiped out a software company's database. (136, Nolan, 2025)
22. Five Eyes cyber security agencies. Careful adoption of agentic AI services. (138, Five Eyes agencies, 2026)
23. Anthropic. Configure permissions and Configure the sandboxed Bash tool. (120, Anthropic, n.d.)
24. MITRE Corporation. MITRE ATT&CK. (46, MITRE, n.d.)
25. MITRE Corporation. MITRE ATLAS. (47, MITRE, n.d.)
26. Debenedetti, E. et al. Defeating Prompt Injections by Design. (182, Debenedetti et al., 2025)
27. Chandramouli, R. & Butcher, Z. A Zero Trust Architecture Model for Access Control in Cloud-Native Applications. (183, Chandramouli & Butcher, 2023)
28. Beurer-Kellner, L. et al. Design Patterns for Securing LLM Agents against Prompt Injections. (184, Beurer-Kellner et al., 2025)
29. Nordqvist, G. AI Governance. (168, Nordqvist, 2026)
30. Nordqvist, G. AI Platform and Security. (169, Nordqvist, 2026)
31. Nordqvist, G. AI Red Team. (170, Nordqvist, 2026)
32. Nordqvist, G. AI Threat. (171, Nordqvist, 2026)