Sandboxes, permissions and least privilege

Video lecture

Sandboxes, permissions and least privilege

15 chapters · about 8 min · full transcript

Coming soon

Chapter 1 of 15

Sandboxes and least privilege

Assume mistakes will happen
Isolation
Least privilege
A locked-down sandbox

The narrated lecture is in production

Every chapter is scripted and ready. Browse the chapters and read the full transcript now — the video will appear here when it’s published.

Chapters

Transcript of the narration, chapter by chapter.

0:00 Sandboxes and least privilege

Here is the mindset that keeps computer-use agents safe. Assume that one day, the agent will do something you didn't intend. Maybe it misreads a screen. Maybe a web page tricks it. Your job is to make that moment boring. In this lesson you will learn how to isolate agents, give them only the permissions a task needs, and build a locked-down browser sandbox.

0:28 What vendors recommend

You're not alone in this view. The vendors say it too. Anthropic's computer use guidance recommends a dedicated virtual machine or container with minimal privileges, keeping sensitive data and credentials away from the agent, limiting internet access to an allowlist, and asking a human to confirm consequential actions. Google and OpenAI similarly recommend close supervision and confirmations for anything sensitive. This is the baseline, not an advanced extra.

0:58 Why it matters

Why does this matter? Because computer-use agents act with whatever access you give them, and they can be wrong or manipulated. If an agent runs in your everyday browser, a single bad decision can reach your email, your ad accounts and your banking. If it runs in a sandbox with a minimal account, the same bad decision touches almost nothing. Isolation and least privilege are what make it reasonable to let an agent act at all.

1:31 The contractor

Here's an analogy. When you hire a contractor to fix a bathroom, you don't give them the keys to your house, your car and your office, plus your bank card. You let them into the bathroom, maybe the hallway, for the hours they're working, and you take the key back afterwards. That's least privilege. And if they flood the bathroom, the damage stays in the bathroom. That's isolation. Treat every agent like a contractor you've only just met.

2:05 Simple example: downloading a report

A simple example. A marketing assistant wants an agent to download last month's report from an ad platform. The unsafe way: run it in their everyday browser, where they're logged into the ad account as an admin, plus email and banking. The safe way: a fresh container, a dedicated read-only reporting user on that ad platform, a domain allowlist containing only that platform, and a temporary download folder that's wiped afterwards. Same result, a fraction of the risk.

2:39 Five isolation layers

Think in five layers. Compute: a container, VM or hosted cloud browser, never your laptop. Browser profile: fresh and empty each run, no saved passwords, no synced accounts. Network: all traffic through a proxy that only allows specific domains, and internal addresses blocked. Identity: a dedicated service account with the smallest role that works. Data: only the inputs this task needs. Then destroy or reset the environment after every run, so nothing leaks between tasks or clients.

3:12 Hands-on: locked-down container

The lesson text gives you a working pattern. A Playwright container running as a non-root user, with a read-only file system, all Linux capabilities dropped, and no direct internet. Its only route out is a Squid proxy that allows a short list of domains. API keys come from the environment, never baked into the image. Then your harness refuses navigation outside the allowlist too. Two independent controls, so a single misconfiguration doesn't expose everything.

3:44 Least-privilege accounts

Now accounts. Create a dedicated agent account on each system, with the smallest role that works. Viewer rather than admin. One client rather than all clients. Prefer read-only, and add write access only for specific, reviewed workflows. Keep sessions short. In agencies, separate accounts per client, so one client's run can never touch another's data. And keep an inventory: which agent accounts exist, what they can do, who owns them, and when they were last reviewed.

4:17 Worked example: creator analytics

A talent agency in London wanted an agent to collect monthly analytics from creators' dashboards. The tempting shortcut was to reuse every creator's login in one shared browser. Instead, they used official analytics exports where platforms offered them. For the rest, creators granted delegated read-only access where available. Each task ran in a fresh container that could only reach that platform. No passwords were stored. In testing, the agent wandered toward a messages tab, and the read-only role simply didn't allow it.

4:53 Mistakes and metrics

Avoid four classic mistakes. Running agents in your personal browser just to try it, and forgetting to stop. Allowlisting whole categories instead of specific domains. One shared super-account for every automation. And persistent environments that pile up cookies and downloads across clients. To measure your posture, audit monthly: agent accounts and roles, share of runs in fresh environments, blocked egress attempts, and how quickly you can revoke an agent's access.

5:23 Files and downloads

Don't forget files and downloads. Agents may download reports, invoices or exports as part of a task. Those files land somewhere, and they can contain sensitive data or even malicious content. Give the sandbox a dedicated, temporary download folder. Scan or validate files before anything else touches them. Move only what's needed to controlled storage, and wipe the rest when the environment is destroyed. Uploads matter too: an agent should only be able to upload files you placed in its input folder.

5:59 Plan revocation

And think about revocation before you need it. If an agent account is compromised or misbehaving, how fast can you cut it off? Write down the steps: disable the schedule, revoke the service account or token, rotate any stored session, and destroy running environments. Rehearse it once. Teams that practice revocation can do it in minutes. Teams that don't often discover, in the middle of an incident, that nobody knows which accounts the agent was using.

6:32 Shrink the blast radius

Let's put a number on the principle, illustratively. Suppose an agent can reach ten systems but a task needs only one. If something goes wrong, you're exposed on all ten. Cut it to one, and the worst case shrinks dramatically. That's why the most effective security control isn't a smarter model or a longer prompt. It's making sure the agent simply can't reach things it doesn't need. Measure it monthly: how many systems each agent account can touch, and whether that number is going down.

7:09 Try this now

Try this now. Pick one agent workflow and write a one-page isolation spec. Where does it run: container, VM or hosted browser? Which domains are allowed, listed exactly? Which account does it use, and what role does that account have? What data does it receive as input? Where do downloads go, and when are they wiped? How is the environment reset after each run? And who can revoke access, and how quickly? If any answer is not sure, that's your first fix.

7:45 Recap

Recap. Assume the agent will err, and design for containment. Isolate compute, profile, network, identity and data, and reset after each run. Use two independent allowlists. Give agents minimal, dedicated, per-client accounts. Your next step: write the isolation spec for one workflow, environment, domains, account role, inputs, and reset. Next lesson: the biggest threat to browser agents, prompt injection.

Assume the agent will make mistakes

Design every computer-use deployment on one assumption: at some point the agent will do something you did not intend, either through its own error or because a web page manipulated it. Security is about making that moment boring. The two tools are isolation (the agent can only touch a contained environment) and least privilege (inside that environment, it can only do what the task requires).

Vendor documentation says the same. Anthropic's computer use guidance recommends a dedicated virtual machine or container with minimal privileges, avoiding access to sensitive data and credentials, limiting internet access to an allowlist of domains, and asking a human to confirm consequential actions. Google's and OpenAI's guidance similarly recommends close supervision and confirmation for sensitive actions.

Layers of isolation

Layer	Options	What it contains
Compute	Dedicated VM, container, or hosted cloud browser	The agent cannot reach your laptop, files or corporate network
Browser profile	Fresh, empty profile per run; no saved passwords or synced accounts	No accidental access to your email, banking or admin sessions
Network	Egress proxy with domain allowlist; block internal IP ranges	Agent cannot wander to arbitrary sites or internal services
Identity	Dedicated service accounts with minimal roles	Mistakes are limited to what that role can do
Data	Only the inputs needed for this task	Nothing extra to leak

A container is usually enough for browser automation: a headless Chromium in a container with no host mounts, a non-root user and an egress proxy. For full desktop agents, a VM or disposable cloud desktop provides stronger separation. Destroy the environment after each run, or at least reset it, so nothing persists between tasks or clients.

Hands-on: a locked-down browser container

# Dockerfile: headless browser agent sandbox (illustrative; pin versions you test)
FROM mcr.microsoft.com/playwright/python:latest
RUN useradd -m agent
USER agent
WORKDIR /home/agent/app
COPY --chown=agent:agent requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY --chown=agent:agent . .
ENV HTTPS_PROXY=http://egress-proxy:3128 HTTP_PROXY=http://egress-proxy:3128
CMD ["python", "run_task.py"]

# docker-compose.yml: agent can only reach the internet through the allowlisting proxy
services:
  agent:
    build: .
    env_file: .env            # API keys come from the environment, never baked into the image
    read_only: true
    tmpfs: ["/tmp", "/home/agent/.cache"]
    cap_drop: ["ALL"]
    security_opt: ["no-new-privileges:true"]
    networks: [sandbox]
  egress-proxy:
    image: ubuntu/squid:latest
    volumes: ["./squid.conf:/etc/squid/squid.conf:ro"]
    networks: [sandbox, outside]
networks:
  sandbox: { internal: true }   # no direct internet from the agent container
  outside: {}

# squid.conf (excerpt): allow only the client's domains
acl allowed dstdomain .example-client.com .example-cdn.net
http_access allow allowed
http_access deny all

Pin image versions you have tested rather than latest in production. Also enforce the allowlist in your harness (refuse goto to other domains) so you have two independent controls.

Least privilege for accounts

Create dedicated agent accounts on each system with the smallest role that works: viewer or analyst rather than admin; one client, not all clients.
Prefer read-only roles; add write permissions only for specific, reviewed workflows.
Use short-lived sessions: log in (by a human or a secrets-managed flow) at the start, expire at the end.
Separate accounts per client in agency settings, so one client's run can never touch another's data.
Keep an inventory: which agent accounts exist, what they can do, who owns them, when they were last reviewed.

Worked example: a creator-management agency in the UK

A London talent agency wanted an agent to download monthly analytics screenshots from creators' platform dashboards. The first idea was to reuse each creator's login in a shared browser. Instead they (1) used official analytics APIs or exports wherever the platforms offered them, (2) for the remaining dashboards, had creators grant delegated, read-only access where the platform supports it, (3) ran each creator's task in a fresh container with an allowlist containing only that platform's domains, and (4) never stored creators' passwords. When the agent misbehaved in testing (it tried to open a messages tab), the role simply did not allow it.

Pitfalls

Running agents in your personal browser "just to try it" and forgetting to stop.
Allowlisting whole categories ("any .com") instead of specific domains.
One shared super-account for all automation.
Persistent environments that accumulate cookies and downloads across clients.

How to measure success

Audit monthly: number of agent accounts and their roles, share of runs in fresh environments, blocked egress attempts (a spike is a signal of injection or bugs), and time to revoke an agent's access.

Assume the agent will err or be manipulated; isolation and least privilege make that moment harmless.
Isolate compute, browser profile, network, identity and data; destroy or reset environments after each run.
Use an egress proxy allowlist plus harness-level domain checks as two independent controls.
Give agents dedicated, minimal, preferably read-only accounts, separated per client, with an inventory.

Write the isolation spec for one agent workflow: environment type, allowed domains, account role, data inputs, and how the environment is reset after each run.

Enrol for free to save your progress

Reading is always free. Enrol to keep your place, take the final assessment and earn a verifiable certificate.

Sandboxes, permissions and least privilege