Permissions define what an AI application may read or change; a sandbox restricts the environment in which code or tools operate; containment keeps failures from spreading beyond the intended boundary. These safeguards matter because a system’s ability to perform an action is not proof that the user authorised it.
This chapter builds a complete fictional library access matrix for Reader and Curator identities. You will distinguish public-read, scratch-write, staging and forbidden publication operations, work through time-limited approval and solve an independent museum example. It fills the Permissions, Sandboxes and Containment chapter of eduKateSG’s How Super Intelligence Works curriculum.
Super Intelligence here is an editorial umbrella for understanding AI technologies, not a claim that contemporary systems possess artificial superintelligence. The practical lesson is straightforward: a polite instruction to behave safely is not a substitute for enforceable restrictions.
Contents and reading routes
Understand the three controls · Open the library fixture · Read the access matrix · Independent transfer · Sources
- 1. What permissions, sandboxes and containment each do
- 2. Capability is not authority
- 3. The fictional Library Workspace
- 4. Create the access matrix before any tool runs
- 5. Do not confuse read, write and execute
- 6. Approval as a condition, not a claim
- 7. Time-bound credentials and expiry
- 8. Tool results need independent verification
- 9. A sandbox is a boundary, not a promise of perfection
- 10. Resource limits and failure reporting
- 11. Independent monitoring and its limits
- 12. Source content cannot widen permissions
- 13. An access matrix is not a substitute for evaluation
- 14. Independent transfer: a museum cataloguing helper
- 15. Transfer answers
- 16. Sources and the wider eduKate ownership map
1. What permissions, sandboxes and containment each do
Permissions determine which identity may access a resource or perform an operation. A sandbox limits the resources or effects available to running code or tools. Containment is the wider design that prevents mistakes and unexpected behaviour from escaping their intended operating boundary.
These controls complement rather than replace one another. A model can be instructed to behave carefully, but an enforced file permission can deny a prohibited read even when the model makes a mistake. A sandbox does not magically certify the content of the answer; it narrows what the process can affect.
2. Capability is not authority
A model may be capable of composing a message, editing a document or running a calculation. Capability does not imply that the user authorised those operations. The application must check the actual task, identity, resource, operation and approval condition.
This boundary becomes more important as AI tools gain access to files, browsers and external accounts. A correct plan should still fail safely when the requested action lacks permission. The reader should not have to trust a generated assurance that approval exists.
3. The fictional Library Workspace
Our original teaching case concerns an invented Brookfield Library Workspace. It has a public catalogue, private patron records, a temporary scratch directory, an editorial staging area and a live public website. No real account, credential, network or personal record is used.
Two fictional software identities will be considered: Reader, which analyses public catalogue entries, and Curator, which may prepare an approved staging edit. Neither is allowed to contact patrons or publish the live website. The exercise asks whether particular operations are authorised, not whether a model can describe them.
4. Create the access matrix before any tool runs
Reader may read the public catalogue and write temporary calculations to its own sandbox scratch space. It may not read patron records, modify staging or publish the live site. Curator may also read the public catalogue and use its own scratch space; it may modify the approved staging record only after an explicit approval.
Both identities are denied live publication, patron-record reads and outbound messages. These statements define the exercise. An attempted operation that the matrix forbids must be rejected by the host system rather than converted into a more enthusiastic prompt.
5. Do not confuse read, write and execute
Reading a file reveals information. Writing changes state. Executing code can alter files, consume resources or interact with other processes depending on its environment. Tool design should treat these as distinct permissions, not one broad ‘access to workspace’ toggle.
A public document read may be harmless within its intended purpose, while reading a private record could violate confidentiality. A write to an isolated scratch file differs from changing a production page. An execute permission needs careful resource boundaries even when the user only requested arithmetic.
6. Approval as a condition, not a claim
A staging edit is not allowed merely because Curator says the user approved it. The host must verify a genuine approval attached to the exact target record and proposed change. Approval for one record is not automatically permission to change every file in the folder.
In the fictional exercise, Reader can suggest a correction but cannot write staging. Curator can write only the approved staging record, while live publication remains forbidden to both. That design separates productive assistance from final institutional responsibility.
7. Time-bound credentials and expiry
Imagine Curator receives a fictional scoped token valid from 09:00 until 09:20 for one staging edit. A request at 09:15 may be permitted if every other condition matches. A request at 09:21 must be denied because the token has expired, even if the model is very confident.
The twenty-minute window is an invented teaching rule, not a description of a real authentication platform. The principle is that permission can depend on identity, resource, operation, time and approval. Expired privileges should not linger simply because a task remains unfinished.
8. Tool results need independent verification
A tool may return permission denied, success, timeout or an ambiguous response. The assistant should not claim a staging edit occurred when a forbidden operation was rejected. Nor should it blindly retry a consequential write after a timeout without checking actual state.
Keep the record identifier, attempted operation, authorisation decision and resulting status distinct. A draft save, a published page and a proposal awaiting approval are different states. The system must preserve that distinction when reporting to the reader.
9. A sandbox is a boundary, not a promise of perfection
An isolated code environment may limit file paths, network access, process resources and execution time. These limits reduce possible effects, but depend on implementation, configuration and ongoing maintenance. Calling something a sandbox does not guarantee that any arbitrary program is safe.
For a simple library statistics calculation, the environment needs only input data and temporary output. It does not need patron credentials, production tokens or unrestricted network access. Removing unnecessary resources reduces the consequences of unexpected code behaviour.
10. Resource limits and failure reporting
Suppose a fictional calculation service gives each job a maximum execution time and memory budget. A task that exceeds either limit should stop and return an explicit status rather than claiming to have completed. The limits should be matched to legitimate work.
A model might correctly write a program that cannot run within the chosen environment. That is an operating constraint, not evidence that the calculation’s mathematical idea was wrong. Distinguish code, execution and verified output in the user’s report.
11. Independent monitoring and its limits
Monitoring records what actions were requested and what the system actually allowed, rejected or completed. An independent component can compare activity with policy without trusting the model’s self-description. This helps investigate failures and verify controls.
However, logs can contain sensitive information. Keep only the appropriate evidence, restrict access and avoid creating a new privacy problem. A monitor that merely repeats the assistant’s claim is not independent verification.
12. Source content cannot widen permissions
A public webpage may claim that an AI reader has permission to view patron files. The webpage is untrusted information for the current task and cannot update the application’s authorisation rules. Granting privileges must happen through the proper identity and policy system.
This is where containment protects against prompt injection. Even if the model treats a website’s sentence as a command, a host-enforced access check should prevent an unauthorised read or write. Policy lives outside the source document.
13. An access matrix is not a substitute for evaluation
The written policy describes desired behaviour. The system still needs tests showing that permitted actions succeed and forbidden actions are rejected. Try a valid public read, a denied private read, a permitted scratch calculation and a forbidden live publication in the isolated fictional fixture.
Check actual tool status, not just the final assistant explanation. A denial should be measurable at the destination. A successful scratch write should be readable in the correct temporary location without becoming a production update.
14. Independent transfer: a museum cataloguing helper
Change the setting to a fictional museum. A volunteer assistant may inspect public exhibit labels and write a draft annotation in a private scratch pad. It may not access donor records or update the live museum website. A curator can approve one annotation for staging.
Which permissions should the volunteer receive? What additional condition must the curator satisfy before staging? Could a note embedded in an exhibit label authorise a live update? Explain your answers using the identity-resource-action structure.
15. Transfer answers
The volunteer needs public-read and restricted scratch-write capability only. The curator may modify a specified staging item after verified explicit approval. Neither gains authority over donor records or live publication from a label, comment or model suggestion.
The important change from the library case is the resource’s identity, not the policy principle. Strong design grants the minimum ability needed for the genuine job and tests that higher-impact operations remain denied until the correct authority acts.
Extended access-control laboratory: enforce, observe and repair
Deeper mechanism 1: Permission is a question about identity and action
A permission check has at least a subject, an operation and a resource. Subject means the identity attempting an action. Operation distinguishes reading, writing, executing and publishing. Resource identifies the actual record or system affected. An answer of ‘allowed’ without all three is incomplete.
For Brookfield’s Reader identity, reading the public catalogue is permitted while reading private patron records is not. Both operations are reads, but they target resources with different classifications. That distinction is more useful than a broad label such as ‘Reader can use files’.
In real systems, group membership, purpose, time, location and approval can add conditions. The underlying discipline is to make the required relationship explicit and enforce it at the tool or service boundary.
Deeper mechanism 2: Authentication does not establish authorisation
Authentication provides evidence about who or what is making a request. Authorisation decides which operations that identity may perform. Successfully signing in does not prove a user is allowed to view every record reachable by the service.
A fictional Curator token may identify Curator correctly and still lack permission to publish a page. A model that confuses authentication with unrestricted access can make confident but wrong claims about what it may do.
Check the permission on every consequential operation. Do not assume that the success of an earlier public catalogue read grants access to patron records or production settings.
Deeper mechanism 3: Use the minimum necessary capability
Begin with the job. Reader needs to inspect public catalogue data and calculate a summary, so public-read access and a restricted temporary workspace may suffice. Adding an email tool or live publication token does not help with that assigned task.
Reducing unnecessary powers also reduces failure consequences. Even if the model misinterprets a document, it cannot send a message through a tool the application never provided. This is the practical value of least privilege.
Least privilege does not mean denying every useful capability. It means enabling the narrow operations that make the legitimate task possible and keeping the rest outside reach until separately authorised.
Deeper mechanism 4: Scope access to the specific record
A staging permission can be narrow enough to cover one named draft, not all site content. The host can check the target record ID, permitted fields and whether the approval matches the proposed change.
For the fictional Curator, approval to revise a catalogue note does not include permission to replace a homepage image or edit a different exhibition entry. A mismatch should be rejected even when the generated explanation sounds plausible.
Record-level scope makes later auditing possible. It lets a reviewer see what change was intended, what was permitted and which concrete record actually changed.
Deeper mechanism 5: Time limits matter after the request begins
Suppose a fictional token is valid from 09:00 until 09:20. A request received at 09:15 may meet the time condition, while a fresh request at 09:21 does not. Define how the service handles long-running operations and the moment at which eligibility is checked.
Expiration controls must be enforced by the service; the model’s assertion that the token is still valid is not sufficient. A paused workflow should not silently regain authority later without an appropriate new grant.
Time limits reduce the duration of exposed privilege. They do not guarantee that a wrong operation during the authorised window is harmless, which is why resource and action restrictions remain necessary.
Deeper mechanism 6: Read-only external access and scratch writing
Reader is described as read-only with respect to external catalogue systems, yet it may write a temporary calculation inside its own isolated scratch directory. These statements are consistent because they refer to different resources.
The application should distinguish scratch output from published output. A chart saved in a temporary folder is not proof that the public website was updated. A draft file is not automatically the final shared document.
Teach learners to name the location and status of an artefact. That simple habit prevents many workflow misunderstandings about whether an operation actually affected the intended audience.
Deeper mechanism 7: Sandbox boundaries need concrete resource controls
An execution sandbox may limit network access, filesystem paths, process rights, CPU time and memory use. The restrictions depend on the actual environment; describing code as sandboxed does not establish a perfect isolation guarantee.
For a library arithmetic job, a restricted runtime could receive only the fictional catalogue input and save an output to scratch. It would not need credentials for the live site, the private patron database or the organisation’s messaging service.
A narrower environment allows useful computation while keeping unrelated assets away from unexpectedly generated code. Its configuration must still be tested and maintained by the responsible operators.
Deeper mechanism 8: A failed operation must be visible
When an access check denies an operation, the system should report the denial accurately rather than claiming completion. A denied private-record read is a successful enforcement of policy, not evidence that the requested information was obtained.
Application error handling should distinguish permission denied, timeout, invalid target, missing approval and completed write. Those conditions imply different next steps. The assistant should not hide them behind a generic ‘done’.
Readers benefit when the system explains what it could accomplish within scope and which action requires further authorisation. Accurate status reporting is part of trustworthy assistance.
Deeper mechanism 9: Ambiguous timeouts and safe reconciliation
Suppose Curator attempts an authorised staging change and loses the response. The change might have occurred before the acknowledgement disappeared. A blind retry can create duplicates or overwrite later edits in systems without appropriate safeguards.
First inspect the target record through a permitted read operation, using the intended identifier. If the change is present and correct, report success. If it is absent and the token remains valid, a carefully controlled retry may be appropriate.
An idempotent operation or a unique request key can help, where supported. But the existence of an idempotency feature must be confirmed rather than assumed. The lesson is to reconcile real state before repetition.
Deeper mechanism 10: Monitoring must be independent enough to help
A model cannot certify the truth of its own claimed actions simply by repeating them. Monitoring should inspect authoritative service logs or state changes that the model did not fabricate, under access controls suitable for the organisation.
For the exercise, record which identity requested each operation, the resource, the policy decision and the observable result. The log should not contain invented success entries just because the assistant described its intention confidently.
Protect monitoring data with its own retention and permission rules. A system that records unnecessary private information can create an additional exposure problem while attempting to improve auditability.
Deeper mechanism 11: Trust boundaries protect against document manipulation
A public page can make many statements, including an instruction-like claim that the assistant now has permission to open private files. That claim remains source text. Only the authorised identity and policy system can grant access.
This is why prompt injection must be analysed together with containment. A model may make an incorrect decision after reading manipulated text, but host-enforced permissions should still prevent a forbidden private read or live write.
The complementary Prompt Injection and Tool Manipulation chapter explains the content side of the boundary; this chapter explains the enforcement side.
Deeper mechanism 12: A test matrix should include permitted operations
Testing only that prohibited actions are rejected can produce an application that is safe but unusable. Include legitimate positive cases as well: Reader should retrieve the public catalogue and create a temporary calculation when the inputs are valid.
Then test negative cases: Reader cannot read private patron records or change staging; Curator cannot publish live without separate authority; neither may send an unsolicited message. Each expected result should be specified before running a test.
A good result shows both utility and containment. Denying a forbidden write is correct, but denying an approved public read because of an overly broad filter is an availability problem that also deserves repair.
Deeper mechanism 13: Beware the difference between can and did
The tool may technically support publishing, yet a given identity may lack permission. Conversely, an identity may have permission but the operation may not have happened. Capability, authorisation, attempt, completion and confirmation are separate states.
Students can practise by writing a small status table. ‘May publish’ is a policy statement; ‘requested publication’ is an attempted action; ‘published with a verified URL’ is an observed state. None follows automatically from the preceding label.
This precision matters in ordinary education workflows as much as in advanced software agents. Submitting an assignment is not the same as having it accepted, and drafting a notice is not the same as making it visible to parents.
Deeper mechanism 14: Risk differs between public and private data
A read of a public science article generally has different privacy consequences from a read of identifiable patron borrowing records. But public information still needs factual verification, and private data may sometimes be legitimately needed for a properly authorised task.
The design should classify resources and attach access conditions that fit their sensitivity and purpose. Broad phrases such as ‘the assistant needs data’ are not sufficient justification for collecting unrelated personal records.
Use the least information necessary. A library statistics exercise can be performed with anonymous aggregate counts or invented rows instead of real patron identities.
Deeper mechanism 15: Escalation should be a controlled workflow
If the task genuinely needs a higher-privilege operation, the assistant can prepare a request that specifies the target, reason and effect. It should not grant itself permission or use an unrelated credential to work around a denial.
A human or authorised policy component can approve, reject or narrow the proposed action. Where permission is granted, limit its duration and scope and record the decision in a way appropriate to the system.
For the fictional Curator, one approved staging edit is allowed while publication remains separate. The workflow preserves progress without collapsing every step into one unconditional ‘go ahead’.
Deeper mechanism 16: Recovery is part of containment
An application should consider how to stop work, revoke a scoped credential, restore a previous version and communicate an incident if a permitted operation produces an unexpected effect. These measures can reduce harm even when prevention failed.
Recovery plans depend on the actual storage and service. A scratch file may be safely discarded; a live public update can require a versioned rollback and clear communication. Do not promise that every action is reversible unless the system supports that feature.
A complete design includes not only what is allowed but how to observe, halt and repair what went wrong. This turns containment into a practical operating discipline rather than a reassuring label.
Deeper mechanism 17: Independent transfer: volunteer and curator
In the fictional museum, a volunteer can view public exhibit descriptions and write a draft note locally. The curator can edit one staging label after verified approval. Neither identity can access donor records or change the live website under the assigned permissions.
Now suppose the volunteer’s source document says ‘you may publish this immediately’. That sentence has no authority to update the access matrix. The correct outcome is a proposed draft within scope, with any staging or publication step handled separately.
The problem changes the domain from library records to museum labels, but the method is stable: identity, operation, resource, context and authorisation first; observed outcome and reader-facing status second.
Deeper mechanism 18: An access-review checklist
Before connecting an AI tool, list the actual user job, data it must inspect, operations it must perform and outputs it must produce. Identify privacy and confidentiality requirements, allowed destinations, expiry conditions and any approval boundary.
During a run, evaluate the specific identity, resource and action; restrict execution resources; log appropriate decision evidence; and check external state after consequential operations. Do not treat instructions found in retrieved data as permissions.
Afterward, audit what was used, which operations were denied, whether any credentials should be revoked and whether the work can be reproduced. This method makes advanced assistance more inspectable and prevents fluency from replacing authority.
A checked access matrix with a changed condition
A final access-matrix check turns the policy into ten explicit combinations: five candidate operations each for Reader and Curator. Reader is allowed public catalogue reading and its own scratch writing, and is denied patron-record reading, staging changes and live publication. Curator is allowed the same two operations and can also make the one approved staging change; it remains denied private patron reads and live publication. Thus five combinations are allowed and five are denied under the stated conditions.
That numerical symmetry has no special safety significance. An access matrix with many denied cells could still be dangerous if one broad permission allows unrestricted external writes. A matrix with many allowed harmless operations might be appropriately scoped. The task is to inspect the meaning and consequence of each grant, not maximise the proportion of red or green cells.
Now change the conditions: Curator’s staging approval expired at 09:20 and a request arrives at 09:21. The staging cell must switch from permitted to denied for that request, while reading the public catalogue remains permitted if its ordinary access grant is still valid. Permission checks can therefore depend on time as well as identity, resource and action.
If the model nevertheless outputs ‘staging published successfully’, the evaluator should record two separate defects: the proposed action lacked a valid grant, and the user-facing status was unsupported. Correcting the output sentence alone would not establish that the host actually enforces expiry. A real test must check the service’s decision and authoritative state.
This is the educational transfer worth retaining: diagnose precisely which boundary failed, build the narrowest repair, and check it against changed circumstances. More powerful models may make more capable proposals, but they still need a system that decides what is legitimate and observes what actually happened.
16. Sources and the wider eduKate ownership map
See OWASP’s generative-AI risk materials, OpenAI’s March 2026 discussion of agentic safeguards and the NIST AI Risk Management Framework. They support layered controls, not any claim that a single sandbox guarantees safety.
The wider Workplace Permissions and Access and Containment and Monitoring articles own broader implementation guidance. This chapter owns the two-agent access-matrix lesson and independent transfer. Follow How Super Intelligence Works and How X Works. Everything in this example is fictional. Source review: 22 October 2026.
Continue through this connected reliability-and-control learning route: Benchmarks · Red Teaming · Prompt Injection. These chapters distinguish evidence of model capability, adversarial testing, untrusted source instructions and enforceable permission boundaries. Return to the complete numbered Super Intelligence curriculum for the next chapter.
Connect this access-matrix exercise to The Gold Standard of Education: Learning That Transfers into Life: a student who can transfer the identity–resource–operation method from a library to a museum has understood the mechanism rather than memorised a tool’s name.