Agent safety and the sandbox

One topic: why the tool you build with is allowed to touch some things and not others, and why that is your problem, not the vendor's.

Why a boundary exists

You already met the reason in week 1. Gemini Enterprise lives in a browser. It cannot reach a file on your machine. Antigravity runs on your laptop: it reads and writes your files, and it drives GitHub and the database — and it can take those steps without asking you first.

A tool that acts needs a boundary. A chat window does not. A browser tab that can only answer needs no wall around it, because nothing it says reaches your disk. The moment a tool can run a command, the question “what is it allowed to touch” has to have an answer.

Untrusted text can become instructions

The agent is constantly reading text nobody on your team wrote:

• A README in a repository you cloned.
• An issue or a comment someone else wrote.
• A web page you pointed it at.
• A data file you did not create.

None of that text came from you. All of it arrives as words the agent reads, and it cannot always tell the difference between text to answer from and text to obey.

That is indirect prompt injection: instructions hidden inside content the agent reads, which it may follow as if you had typed them. You never see the instruction — you see the result. It is called indirect because the attacker never talks to you. They write something, and wait for an agent to read it. A team told to “read the client's website and build the booking form” is pointing an agent at text written by someone else, and that is not a hypothetical for this course.

One documented case: CVE-2025-54135, in Cursor

Injected content caused the agent to write a configuration file. That file was then executed automatically. The result was remote code execution on the developer's machine.

This case is worth studying because it is fixed and fully documented — every claim above can be checked. Read the shape, not the product:

• Nothing was broken into. The agent did what it was told.
• The instruction arrived in content, not from the user.
• The damage came from a step that ran without a human.

Cursor patched this one. The shape it belongs to is not a bug that gets patched once — it is a property of agents that read untrusted text and act, not a property of one vendor. This is also the argument the OWASP reading below makes.

What is on your laptop

The abstract version of this threat does not move anyone; the fact that the agent runs on the same machine as your other four courses does.

• SSH keys — your access to every repository you can push to.
• Environment files — database passwords and API keys, in plain text.
• Cloud tokens — signed-in sessions for services that hold real data.
• Your coursework — every other course you are taking, on the same disk.

What the sandbox does

Inside the wall, the documented boundaries are these:

• Sandboxed commands write only to project, temp and build-cache paths.
• Anything not mounted is invisible from inside — a stronger claim than “refused”. A path that was never mounted does not appear to exist, so an agent cannot even enumerate it.
• System directories such as /usr and /etc are read-only.

Two paths are called out by name in the documentation, because they are the two that matter most and they are exactly the two on the list above:

• ~/.ssh — your keys. Blocked.
• .env — your secrets. Blocked.

Network access is limited to approved domains. The boundary is not only about the disk.

Source for the three items above: antigravity.google/docs/sandbox/, checked 12 September 2026.

The sandbox limits what a command can reach. It does not judge whether the instruction was a good idea. A perfectly sandboxed agent will still cheerfully delete your own project files if it is told to. Containment is not judgement.

The approval prompt is the feature

The prompt appears exactly when an action crosses the boundary. It is the one moment a person is in the loop. Clicking through it without reading is the whole defence, discarded. The modal is not friction in your way — it is the design working.

Approval fatigue is real. The twentieth prompt of the morning gets the same click as the first, and by then you are approving a category, not an action. An agent that asks a hundred times has trained you to say yes — that is the cost. Too few prompts and the agent acts unsupervised; too many and supervision becomes reflex. The practical rule: slow down when the prompt names something outside your project. The path in the modal is the signal worth reading, and it takes two seconds.

Verify the boundary, do not trust it

Three checks, run on your own machine rather than watched on a teammate's:

1. Write inside your workspace — expect it to succeed.
2. Read something outside it — expect a refusal or a prompt.
3. Trigger one crossing action — read the modal, and describe what it says.

Then, on what you saw:

• A refusal you expected and did not get is a finding — tell the instructor.
• A refusal you did not expect is normal; read the path in the message.
• Do not disable the sandbox to make an error go away.

Who owns what ships

The agent acted without asking. You still own what shipped. This is why every pull request declares AI use:

• The tool, what it produced, and what you changed.
• Or AI-Assisted: none — equally legitimate.
• Not declaring is the offence.

The declaration is not a confession. It is the record of who checked what, and it is the only one that exists. The connection worth holding onto: the declaration is the mechanism by which “you own what you ship” stops being a slogan and becomes something visible in the repository.

Know where the wall is. Read the modal. Own what you ship.

Phase 2, due at the end of this week

Personas, stories, the schema and acceptance criteria, the split, the environment, and your token plan — 10 marks, due Wed 7 Oct 2026 before class. The delivery contains:

• A backlog at or above the floor, ordered, with acceptance criteria.
• Acceptance criteria for every boundary between members, checked against the schema.
• The split — who holds which named stories this sprint.
• Your schema, as db/schema.sql with keys marked and row-level security enabled on every table, and docs/schema.md saying what each table means and who may read and write it.
• A verified environment, working for every member.
• Your token plan, and the first ledger entry.

Presented to the room, with questions from the room. See deliverables for the date and the checklist.

Required reading

For the OWASP page, read the Description and Prevention sections only. Skip the reference list. The Antigravity page documents the mechanism the three checks above test on your own machine — verify first, then read what you verified.

Optional reading

The clearest short argument that there is no complete fix. Read it if you want to argue about this one — it is also the best answer to “why doesn't someone just fix it”.

Keeping the agent inside the course's stack

Every team repository carries an AGENTS.md, written for the AI assistant rather than for students. It says the same things as docs/how-we-work.md, in the form an assistant needs, and it has to stay in the repository.

It exists because the boundaries in this reading are about what an agent can reach. AGENTS.md is the other kind of boundary: what an agent operating well inside the sandbox is still expected, or not expected, to build. It enforces the stack the course is built on:

• Plain HTML, CSS and JavaScript. No framework, no npm, no build step, no bundler. If a task seems to need one, the agent is instructed to say so and stop rather than scaffold it.
• Supabase for data and logins, loaded from a CDN <script> tag — not installed as a package.
• Only the anon key. The project URL and the anon key are public and belong in js/config.js, committed to the repository — that is correct and safe. The service_role key is never used in this course; if a task appears to need it, the design is wrong, and the agent is instructed to say so and stop rather than use it.
• Row Level Security stays on, for every table. The agent is instructed never to suggest turning it off to make something work.

Two more rules keep an agent that can act from acting past what was asked:

• Ask the agent for a plan before it writes code. An agent that states what it is about to do, and why, is one whose actions you can check against the acceptance criteria before they happen — not only after, in review.
• Keep each pull request to one story. One branch, one story, one thing a teammate can review and a Client Lead can accept. An agent asked to do one thing produces a pull request a human can actually check.