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 (127, OpenAI, 2026), shows what a badly placed boundary costs, because the failure lay in where the boundary was drawn and in what the controls around it quietly depended on. This chapter concerns Shift 2, from gatekeeper to boundary designer, and Shift 1, from documents to code. It shows where the architect draws boundaries around people, workloads and agents, how they are written as containment profiles and permission manifests, and how they are shown to hold; Chapter 8 takes up who an actor is, and Chapter 10 how fast the estate can stop.
The gatekeeper of Chapter 2 says yes or no once, constraining what was submitted, not what later happens. A boundary, by contrast, is applied to every action by a mechanism that does not wait for the architect, and it constrains whatever is attempted, including attempts nobody foresaw. A boundary has four properties: it is enforced outside the party it governs, 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.
People and workloads sit inside identity, network and data policy around behaviour the organisation can predict or review. Agents, however, 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 (162, Nordqvist, 2026).
Primary topics explored
- The boundary as the architect's product
- Zero trust, from principle to estate
- Policy decision points outside the model
- Default-deny egress and correlated controls
- Containment that does not depend on intent
- Blast radius as a design parameter
About The Transformed Security Architect
The Transformed Security Architect is Book 6 of The Transformed Architecture. It describes how the security architect role is transformed when architecture is code, when AI drafts and acts, and when adversaries move at machine speed: the craft, the architect's own AI team, the role in the organisation, the competences and the career, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team and AI Threat.
Security architects, CISOs and heads of security architecture, enterprise, solution and AI architects, engineering leads, competence and hiring leads, procurement and programme leaders, and risk, compliance and audit.
Continue with the full chapter
Chapter 7: Designing Boundaries: Zero Trust and Containment for People, Agents and Machines in The Transformed Security Architect gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Craft” and is one of 31 drawn from the manuscript.