An instruction alone is not a boundary: an agent told not to do something can be talked into it.
In our view, instructions are necessary but not enough. An agent can be misled by text hidden in something it reads, such as an email, a document, or a web page; The Knowledge Core, chapter 6, notes that security specialists call this prompt injection. The Knowledge Core, chapter 5, puts it this way: "An agent told not to share a confidential document can be talked into it; an agent that cannot reach the document cannot."
The book's answer is to split the work in two. Systems decide what an agent can do: the person's own account and access, the levels of the shared knowledge, the sign-in lists for private sites, records that cannot be edited, and the rule that a person approves anything sent in the organization's name. Instructions shape what the agent does inside those limits. The Knowledge Core, chapter 6, sums it up: "If a boundary matters, put it in a system." The same chapter adds that a misled agent can still make a mistake, but it cannot reach what it was never given.
The Knowledge Core, chapter 6, applies the same rule to everything that comes from outside. Emails, documents, forms, and posts are information, never instructions. The agent reads and uses them, but it never takes orders from them. Building Agentic Organizations, chapter 11, names two older security principles that do much of the work. Least privilege gives each agent its person's access and no more. Separation of duties means an agent can propose a change to who may see what, but a person approves it. The chapter says both principles "have to live in systems to mean anything."
Building Agentic Organizations, chapter 11, recommends testing each boundary from the system's side, not from the agent's. It suggests sending an agent a document with a hidden order to share a confidential folder, then checking whether its account could have shared the folder even if the agent had tried. The same chapter says that when an agent reaches a step reserved for a person, such as granting access, it says so and files a request for someone who can take that step. It never looks for another way in.
On this publication, a page in this catalog cannot be published unless the Compliance Agent passed that exact version of it, and a piece declined for a reason on our list cannot be published even from the editor in chief's own desk: the software refuses, whatever anyone asks. The reading pages of our books sit behind a sign-in at the network's edge, so no agent can show them to a reader who has not signed in. At GSSF, as The Knowledge Core (chapter 6) describes, each person's agent works only with that person's own access and level. Agents cannot change anyone's access, cannot send in GSSF's name without approval, and cannot see other people's private files. Accounts and access levels enforce those limits, not instructions. The lesson GSSF drew was that trust comes from limits: people actually use agents that cannot do the dangerous things.
In our view, system limits take setup work and add steps for people. Building Agentic Organizations, chapter 11, warns that people may find steps reserved for a person tedious and route around them, so the person's part should be kept as small as possible. Systems also can't shape judgment, tone, or accuracy inside the limits, so instructions are still needed.
If a limit placed in a system keeps blocking legitimate work and people start routing around it, we would redesign the limit, not move it back into instructions.
At GSSF, the limits that matter live in accounts, access levels, and sign-in lists (Building Agentic Organizations, chapter 11); this publication's publishing steps refuse any page or piece without its passing review.