# Why my agents do not run on my laptop: chat, Cowork and Code in the cloud, a vault as the shared drive, and the two walls an operating system has, sgit.ai

> I do not run any model or agent on my laptop, and I am asked why often enough to write it down. The reason is not a worry about models. It is a fact about operating systems: they have two hard walls, the kernel and the user account, and an agent on my laptop runs inside the wall marked "me", where it can read everything I can read, SSH keys, cloud credentials, the password manager's session, every site my browser is signed into. The rules the desktop agents add on top are settings, enforced by the process they constrain, and fifteen months of incidents show what happens when a mistake or an injected instruction reaches the account. So the agents run in four places that are not my laptop: Claude chat, with nothing connected and search across past chats switched off, for thinking; Claude Cowork in the cloud, with no repositories, for most of the agentic work; Claude Code on the web, with one repository per session and a network allowlist, when code has to change; and ChatGPT with no assets at all. What makes this workable is a vault as the shared drive between them: encrypted on the agent's side, keys handed to a session out of band, commit, pull, push, so the laptop passes keys and nothing else. The article gives the setup, the evidence, what the OS can and cannot isolate, the usability trade-offs, the three things I wish the platforms gave me, identity, secrets and a key pair per agent, and one caveat: this is about a laptop that holds the main account. A dedicated machine with separate accounts and nothing of mine on it is a different model, which I will try and report on later.

*Source: <https://sgit.ai/articles/why-my-agents-do-not-run-on-my-laptop.html> · site v0.6.78 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.*

---

[Home](../index.md) / [Articles](index.md) / Why my agents do not run on my laptop: chat, Cowork and Code in the cloud, a vault as the shared drive, and the two walls an operating system has

# Why my agents do not run on my laptop: chat, Cowork and Code in the cloud, a vault as the shared drive, and the two walls an operating system has

By [Dinis Cruz](../about/index.md) · 2026-10-06 · updated 2026-10-06 · [v0.6.78](../admin/versions.md) · agentssecuritylaptopisolationclaudecoworkclaude-codechatgptvaultssgitagent-behaviour-policyprompt-injectionmcpblast-radiusarticle

***Abstract:** I do not run any model or agent on my laptop, and I am asked why often enough to write it down. The reason is not a worry about models. It is a fact about operating systems: they have two hard walls, the kernel and the user account, and an agent on my laptop runs inside the wall marked "me", where it can read everything I can read, SSH keys, cloud credentials, the password manager's session, every site my browser is signed into. The rules the desktop agents add on top are settings, enforced by the process they constrain, and fifteen months of incidents show what happens when a mistake or an injected instruction reaches the account. So the agents run in four places that are not my laptop: Claude chat, with nothing connected and search across past chats switched off, for thinking; Claude Cowork in the cloud, with no repositories, for most of the agentic work; Claude Code on the web, with one repository per session and a network allowlist, when code has to change; and ChatGPT with no assets at all. What makes this workable is a vault as the shared drive between them: encrypted on the agent's side, keys handed to a session out of band, commit, pull, push, so the laptop passes keys and nothing else. The article gives the setup, the evidence, what the OS can and cannot isolate, the usability trade-offs, the three things I wish the platforms gave me, identity, secrets and a key pair per agent, and one caveat: this is about a laptop that holds the main account. A dedicated machine with separate accounts and nothing of mine on it is a different model, which I will try and report on later.*

Four places the agents run, none of them my laptop, and the one vault they all share. Each surface gets the reach its job needs. The laptop holds the main account and is where I type, not where anything runs. As configured on 6 October 2026.

**Where this comes from, and the caveat first.** A voice memo on 6 October 2026, answering a question I get most weeks. I wrote a LinkedIn article on the same point in June 2026, "Hope-Driven Development and the Risks of Running LLMs Under Your Account", and the argument about agents inheriting their user's permissions goes back to [a note on MCP from June 2025](https://docs.diniscruz.ai/2025/06/10/security-implications-of-the-model-context-protocol-mcp-and-the-need-for-robust-infrastructure.html) and a talk on agents' blast radius in July 2025. This page is the full version, with the evidence. The caveat: everything here is about a laptop that holds the main account, mine, with years of credentials and sessions on it. People who run their agents on a dedicated machine, a Mac mini or a second laptop with a separate Apple account and a separate Workspace account and nothing of theirs on it, are in a different position, closer to the cloud model than to mine. I am going to try that, and I will report when I have run it, not before.

## In short

- **No model runs on my laptop.** Not because local models are bad, but because a process on my laptop runs as me, and I have not seen a desktop agent that runs as anyone else.
- **An operating system has two hard walls**, the kernel and the user account. Inside the user account there is no boundary the OS enforces between an agent and my SSH keys, cloud credentials, password manager session, browser cookies, dotfiles and files. The desktop agents' permission prompts and sandboxes are settings the agent's own process enforces. The first vendor's own documentation lists "most of the machine, including credential files such as ~/.ssh" as the default read scope of its local sandbox.
- **Fifteen months of incidents say what that means.** Home directories and drives deleted by agents in their fastest modes, repositories that execute code before the trust prompt, hidden instructions in pull requests and tool descriptions that exfiltrated secrets, tens of thousands of self-hosted agent gateways exposed with keys in the clear, a local-sandbox escape that reached SSH keys. Every one was fixed. The pattern is what stays.
- **So the agents run in four places that are not my laptop.** Claude chat for thinking, with nothing connected. Claude Cowork in the cloud for most of the agentic work, with no repositories. Claude Code on the web when a repository has to change, one per session, behind a network allowlist. ChatGPT for a second model, with no assets.
- **The vault is what makes this workable.** A shared drive the host cannot read, that any session can be handed a key to. Each session reads its state from files, does its kind of work, writes files back; the next session pulls. Without it I would have to run something locally to pass work between agents. With it, the laptop passes keys and nothing else.
- **The trade-offs are real and I accept them.** No agents on a flight. A key handed per session. Cowork has no per-session secrets, so one vault per scope does the job instead. Chat does not search my past chats, because that was the one gap.
- **Three wishes:** an identity per agent, secrets per agent, and a key pair per agent. The cloud surfaces are one step from all three.

## The question, and the short answer

The question arrives as "why don't you run Claude on your Mac" or "why not a local model". The short answer is that I have no business need to run a model offline, so I accept the constraint of needing a connection; and that the thing I would need from a local agent, isolation better than I get online, is the thing no local agent offers. The models are fine. The place they run is the problem.

For a while I did try the desktop tools. What I saw was the amount of reach. On a laptop that holds a working life, the reach of a process running as me is everything: the credentials for every cloud I use, the keys for every server I can log into, the password manager while it is unlocked, every site my browser is signed into, every project's environment file, the shell, the network. In [RiskMandate's vocabulary](https://riskmandate.ai/abp.html), the grant is my whole account, the mandate is "help me with this document", and nearly every row of the gap has an expectation in front of it, a rule the agent's own process is asked to keep. I would not accept that from a contractor and I do not accept it from a process.

## The two walls

An operating system has two hard walls, the kernel and the user. An agent on your laptop runs inside the wall marked "you", where everything your account can read is readable. The desktop agents add settings on top. The caveat is in the black bar.

A general-purpose operating system separates two things by force. The kernel is separated from everything else, and one user's files are separated from another's. Within one user account there is no third wall. A process you start runs with your identity and your rights, and the file system does not know the difference between you opening your SSH key and a process you started opening it. macOS adds consent prompts for a handful of folders and devices, and a terminal that has been granted full disk access has already answered them for everything launched from it. The keychain can scope items per application, and most of the tokens that matter are not in the keychain; they are in dotfiles, environment files and browser profiles.

The desktop agents know this and add their own layers. Approval prompts before destructive commands. Allow lists for shell commands. A process sandbox, built on the operating system's own primitives, that restricts writes to the working directory and routes network through a proxy. A virtual machine, in one product's case, with a scoped token. These are real, they reduce accidents, and they are all inside the wall marked "me", enforced by the process they constrain. Anthropic's own documentation for its local coding agent is candid about where that leaves the reads: the sandbox is "off by default", it covers shell commands only while "Claude's file tools, MCP servers, and hooks run outside it", and the default read scope is "most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials". Its security page says the same thing in one sentence: "The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can."

What would be a boundary is a separate operating-system user for the agent, with its own home, keychain and sessions and nothing of mine in them; or a separate machine; or a container or cloud environment with a network allowlist and credentials injected per task. As far as I have been able to find, none of the mainstream desktop agents runs as a separate user by default; a commenter on one of the incidents below put the fix in a sentence, "make claude a local user, without sudo", and it remains community advice rather than a product. The cloud environments do the equivalent by construction, which is the whole of my argument.

One more thing about words. When a local agent deletes a directory, the usual account is that the model hallucinated. The account that matters is that nothing stood between the mistake and the account's reach. A mistake inside a boundary is a bad afternoon. The same mistake inside "me" is an incident, and the incidents are below.

## The evidence

Fifteen months of agents reaching what they were given, July 2025 to September 2026. Every flaw was fixed, most within days; the cloud versions of the same tools were often unaffected. The last column is the point.

I want to be careful with this list. Every item is a reported incident or disclosure with a source, every vendor fixed what was theirs to fix, and several of the tools involved are ones I use in their cloud form every day. The list is not an argument against the tools. It is an argument about where they run.

- **July 2025.** A release of Amazon's coding assistant for VS Code shipped with an injected prompt telling the agent to act as a "system cleaner" and delete local files and cloud resources; Amazon says the payload was malformed and did not run. The same month Google's Gemini CLI, asked to move a user's files into a new folder, failed to notice the folder was never created and moved each file onto the same path, losing all but the last. Also that month: a critical command-injection flaw in the MCP connector most desktop agents used, and two containment flaws in Anthropic's reference filesystem server, one a prefix match that let an allowed path like `/tmp/allow_dir` also match `/tmp/allow_dir_sensitive_credentials`, the other a symlink that reached arbitrary files.
- **August 2025.** Two Cursor flaws: a prompt hidden in content could write a tool configuration that executed before the user approved it, and in a shared repository an approved configuration could be silently swapped for another command.
- **September to October 2025.** A fake MCP package on npm built trust over fifteen versions and then added a hidden copy of every email to an attacker. Hidden comments in a pull request made GitHub Copilot Chat search a victim's private repositories for secrets and exfiltrate them character by character through an image proxy. Claude Code's own project settings file could run shell commands from a cloned repository before the trust prompt; a later flaw could redirect API traffic and leak the API key.
- **December 2025.** A user running Claude Code with permission prompts skipped asked it to tidy some folders; the command ended in `~/` and removed the home directory, keychain data reportedly among the losses. A photographer using Google's Antigravity in its fastest mode to clear a cache lost a whole drive; the agent's own words afterwards were "No, you absolutely did not give me permission to do that."
- **January to February 2026.** OpenClaw, the self-hosted personal agent that became the design Meta later acknowledged copying, was found exposed on the internet in the tens of thousands of instances, between twenty-one and forty-two thousand depending on the scanner and the date, with API keys and chat histories in the clear under the user's home directory. A supply-chain campaign placed 341 malicious skills in its marketplace, most of them delivering a macOS credential stealer that targets the keychain, browser passwords, wallets and SSH keys.
- **March 2026.** A compromised release of a widely used Python package harvested environment variables, SSH keys, cloud credentials, cluster configurations and shell history on install. Not an agent incident; the same blast radius, and the same machine.
- **July 2026.** Researchers showed that untrusted content in a local Claude Cowork session could escape its virtual machine through a kernel bug and "read and write files anywhere on your Mac", reaching "SSH keys, cloud credentials, anything the user's account can touch". Cloud execution had become Cowork's default two weeks earlier, and the report notes the cloud path did not appear to be affected.
- **September 2026.** Meta's Muse desktop app had an undocumented setting, writable by any unprivileged local process, that redirected dictation to an attacker's server and could capture prompts and tokens. Meta fixed it within a day and called it a local privilege escalation; the researcher pointed out that a one-click social-engineering attack delivers exactly that.

Two numbers frame the list. GitGuardian's 2026 report counted 24,008 unique secrets in agent tool-configuration files on public GitHub, 2,117 of them still valid, and its June 2026 note on developer laptops reported an average of 150 secrets per machine in its beta programme, 38 per cent of them private keys, with 40 per cent found in directories and logs left by AI tooling. The sample is not random and the vendor sells the scanner; the order of magnitude is the point. The laptop is the credential store, and the agent runs in it.

The mechanism in most of these is the one Simon Willison named in June 2025 as the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate out. "LLMs follow instructions in content. This is what makes them so useful ... The problem is that they don't just follow our instructions." On a laptop all three legs are present by default, because the private data is the account, the untrusted content is every file and page the agent reads, and the network is the user's.

## The setup

So the agents run in four places, and the places are chosen by what each job needs to reach.

**Claude chat, for thinking.** The most isolated surface and the most interactive. Nothing is connected to it: no files beyond what I paste, no connectors, no internet in my configuration. The one gap was the feature that lets a chat search and reference my past chats, which would have let any conversation reach every other; I have switched it off, which Anthropic's help pages describe under memory settings. What a chat says can leave it only through me.

**Claude Cowork, in the cloud, for the team.** This is where most of my agentic work happens, because it is better at running several agents in parallel on longer tasks and because its flow is the one I prefer: it talks. It runs on Anthropic's servers, which has been the default since July 2026 and, from today, the only option on individual plans. It has no GitHub connector and reaches no repository. Its one persistent asset is the vault, and I decide which vault each session is handed. The limitation is that Cowork has no per-session secrets; a key given to one agent is available to the surface, which is honest about what the platform can and cannot scope, and which I work round with one vault per scope.

**Claude Code on the web, when code has to change.** Each session gets a cloud environment with a network allowlist, one repository that I choose, and environment variables per environment, which is the control Cowork lacks and the reason the repositories live here. It is less conversational; it gets on with it. I use it only when a repository has to change, and I give it that repository and nothing else. The egress allowlist is what the [how-to on Team and Enterprise plans](../docs/how-to/claude-team-egress.md) is about, written after a session could install sgit and not reach it.

**ChatGPT, for a second model.** Infographics mostly, a second opinion sometimes, a little vault work. It has no connectors to any of my accounts and no assets at all, apart from a vault read key when I choose to hand it one. What it makes comes back through me.

In [Six agents, one inbox](../articles/six-agents-one-inbox.md) I noted that Cowork and Claude Code are different agents with different reach even on the same seat. This setup is that observation used on purpose: the surface with the repositories has no mailbox, the surface with the mailbox has no repositories, and the surface with neither does the thinking.

## The vault is the shared drive

The vault as the shared drive between agents. A session is handed a key out of band, pulls, works, commits and pushes; the next session on another surface pulls. The host holds ciphertext. Keys masked, paths illustrative.

None of this would work without a way for the agents to hand work to each other that is not my laptop. That is what the vault does, and it is why this article is also about vaults. An sgit vault is a folder whose every file, filename, commit message and branch name is encrypted on the agent's side before it leaves; the host holds ciphertext and sees sizes and timings. A session is handed a key out of band, in the session, never written to a file. It clones or pulls, reads its state from files, does one kind of work, runs the leak check, commits and pushes. The next session, on another surface or another day, pulls and continues. Two sessions cannot overwrite each other's unpushed work, because each clone has its own branch and key and pushes are compare-and-swap. The record is the vault's history, readable later with a read key and no write credential.

The vault is also the reason the surfaces can be so isolated. Cowork needs no repository because the brief it writes goes into the vault and Claude Code pulls it. Claude Code needs no mailbox because the result it writes goes into the vault and the inbox agent reads it. ChatGPT needs no connector because a read key is enough to show it a vault. The one thing that moves between surfaces is a key, and keys have three reaches: a vault key that writes, a read key derived one way that only reads, and a lane token that only appends. The [agent team as it runs](../articles/the-agent-team-as-it-runs.md) is this pattern with twelve agents and three vaults; this article is the single-person version of it.

## Same mandate, two deployments

The same modest mandate deployed on my laptop and in a cloud session, read as a behaviour policy. On the laptop the grant is the account and most barriers are expectations. In the cloud the grant is built small and most barriers are boundaries. The last row, an instruction hidden in a file the agent reads, has no barrier in either; what differs is what it can reach.

The table is worth reading row by row, and the last row is the point. Prompt injection is not prevented by moving to the cloud. An instruction hidden in a page or a file the agent reads will be followed in either deployment, because that is what a model does with instructions. What the cloud session changes is what the followed instruction can reach: one repository and one vault, instead of my account. The barrier that holds is the small grant, not a cleverer filter. This is the argument of [Footprint and blast radius](../articles/footprint-and-blast-radius.md), that blast radius is defined over the reach because whoever takes the agent over inherits the reach; and of [the ultimate insider](../articles/ultimate-insider-three-collisions.md), that the more you constrain an agent the more you can trust it with.

## What it costs me

Honestly: a few things, and I pay them.

- **No agents without a connection.** On a flight I have the chat on my phone and nothing else. I have not had a business need that this breaks.
- **A key per session, by hand.** Each session is handed what it needs. It is a minute's work and it is also the control.
- **No per-session secrets in Cowork.** One vault per scope, and the keys for the scope, instead of one vault with scoped keys. More vaults than I would like.
- **Chat does not remember across chats.** I switched that off and I paste what matters. The alternative was one conversation reaching all of them.
- **Two products, two flows.** Cowork talks, Code gets on with it. I would like Code to talk more, and I accept that it is built for people who want it to get on with it.

The usability is otherwise better than the alternative, not worse. The sessions start clean, nothing accumulates on a machine I have to look after, and when something goes wrong the blast radius is a repository with history and a vault with history. That is a bad afternoon, which I have had, and not an incident, which I have not.

## Three things I wish the platforms gave me

Three things that would change the security of the whole setup and that no platform I use provides yet: an identity per agent, secrets per agent, and a key pair per agent. Each exists in pieces on this site; none is a product feature.

**An identity per agent.** Each agent should be somebody: an account the platform knows, a name on its commits, a footprint under that name. Today the nearest thing is a dedicated Workspace and Claude seat per agent, which the RiskMandate team buys and which costs a human's seat each; inside a shared vault an agent's identity is its branch, because signed authorship is not yet recorded, as the [limitations page](../docs/limitations.md) says.

**Secrets per agent.** Each agent should hold the keys its job needs and no other agent's, injected per session and revocable per agent, with a record of which session used which. Claude Code on the web has per-environment variables and an API-credential mode that never shows the key to the agent, which is the right shape; Cowork has neither, so the workaround is vaults per scope.

**A key pair per agent.** Each agent should be able to sign what it writes and receive what is encrypted to it alone. The [append-lane work](../docs/append-lane-messaging.md) gives agents per-session keys and a pinned registry, and [Agent Contact](../docs/agent-contact.md) signs mail between the sites' agents; it is machinery built beside the platforms, not something they provide. Together the three turn "the agent runs as whoever started the session" into "the agent runs as itself", which is the difference between the laptop model, where the only identity available is mine, and the model the cloud surfaces are one step away from.

## The caveat, properly

Everything above is about a laptop that holds the main account. The wall marked "me" has a working life inside it, and that is why no agent runs there. A dedicated machine changes the picture: a Mac mini or a second laptop with a separate Apple account, a separate Workspace account, no password manager of mine, no browser signed into anything of mine, and only the keys that machine's agents need. The wall marked "that user" would have nothing of mine inside it, which is the property the cloud sessions have by construction. It is a reasonable way to run local agents, and some of the isolation the vendors have shipped, the virtual machines and the process sandboxes, would be a second layer on a machine like that rather than the only one. I have not run it, so I am not reporting on it. When I have, it will be its own article, with the same honesty about what broke.

## What exists today, and what does not

The setup described runs. The four surfaces, the vault as the shared drive, the keys handed per session, the leak check before every commit, the read keys published on this site and the write keys escrowed. The RiskMandate team runs the twelve-agent version of it. The evidence list is sourced and dated. What does not exist: the three wishes, as platform features; a desktop agent that runs as a separate operating-system user by default; and my own report on the dedicated-machine model, which is next.

## Threads woven here

- [The agent team as it runs](../articles/the-agent-team-as-it-runs.md): the twelve-agent version of this setup, with the security properties as properties.
- [Six agents, one inbox](../articles/six-agents-one-inbox.md): the account as the blast radius, and Cowork and Code as different agents with different reach.
- [Footprint and blast radius](../articles/footprint-and-blast-radius.md) and [The ultimate insider](../articles/ultimate-insider-three-collisions.md): why blast radius is defined over the reach, and why constraint is what lets you trust an agent.
- [A personal agent that keeps your secrets](../articles/a-personal-agent-that-keeps-your-secrets.md): the same question for the vendors' personal agents, and a design with the compute where the user can see it.
- [Working with AI agents](../docs/agents.md) and [the Team and Enterprise egress how-to](../docs/how-to/claude-team-egress.md): the session pattern, and the allowlist a cloud session needs.
- [Vault credentials](../docs/credentials.md), [the security model](../security/index.md) and [Limitations](../docs/limitations.md): the three reaches of a key, what the host sees, and what is not yet built.

## Sources

- Anthropic, [Claude Code sandboxing](https://code.claude.com/docs/en/sandboxing) and [security](https://code.claude.com/docs/en/security) documentation; [Claude Code sandboxing](https://www.anthropic.com/engineering/claude-code-sandboxing), engineering post, 20 October 2025; [How we contain Claude across products](https://www.anthropic.com/engineering/how-we-contain-claude), 25 May 2026; [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview); [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile), the 6 October 2026 change; [Claude Code on the web](https://code.claude.com/docs/en/claude-code-on-the-web) and [cloud environments](https://code.claude.com/docs/en/cloud-environments); [chat search and memory](https://support.claude.com/en/articles/11817273-use-claude-s-chat-search-and-memory-to-build-on-previous-context).
- Incidents: [Gemini CLI, AI Incident Database 1178](https://incidentdatabase.ai/cite/1178/); [Amazon Q wiper prompt](https://www.scworld.com/news/amazon-q-extension-for-vs-code-reportedly-injected-with-wiper-prompt), July 2025; [mcp-remote CVE-2025-6514](https://jfrog.com/blog/2025-6514-critical-mcp-remote-rce-vulnerability/); [EscapeRoute, filesystem MCP server](https://cymulate.com/blog/cve-2025-53109-53110-escaperoute-anthropic/); [Cursor CurXecute and MCPoison](https://www.tenable.com/blog/faq-cve-2025-54135-cve-2025-54136-vulnerabilities-in-cursor-curxecute-mcpoison); [postmark-mcp](https://www.theregister.com/2025/09/29/postmark_mcp_server_code_hijacked/); [CamoLeak](https://assets.theregister.com/2025/10/09/github_copilot_chat_vulnerability/); [Claude Code CVE-2025-59536](https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/); [the home-directory deletion](https://old.reddit.com/r/ClaudeAI/comments/1pgxckk/claude_cli_deleted_my_entire_home_directory_wiped/), December 2025; [Antigravity drive deletion](https://www.theregister.com/2025/12/01/google_antigravity_wipes_d_drive/); [OpenClaw exposure](https://securityscorecard.com/blog/beyond-the-hype-moltbots-real-risk-is-exposed-infrastructure-not-ai-superintelligence/) and [ClawHavoc](https://www.koi.ai/blog/clawhavoc-341-malicious-clawedbot-skills-found-by-the-bot-they-were-targeting); [Cowork SharedRoot](https://accomplish.ai/blog/sharedroot-escaping-claude-cowork-sandbox/), July 2026; [Muse dictation endpoint](https://forkast.news/meta-patched-its-muse-macos-zero-day-just-before-connect-the-dispute-over-who-could-exploit-it-remains-open/), September 2026.
- GitGuardian, [State of Secrets Sprawl 2026](https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/) and [Developer laptops are the credential store](https://blog.gitguardian.com/developer-laptops-are-the-credential-store-attackers-are-picking-through-in-2026/), June 2026. Simon Willison, [The lethal trifecta for AI agents](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/), 16 June 2025. Jeff Johnson, [Full Disk Access and Terminal](https://lapcatsoftware.com/articles/FullDiskAccess.html), 2022.
- Earlier writing: Dinis Cruz, "Hope-Driven Development and the Risks of Running LLMs Under Your Account (i.e. Your Laptop)", [LinkedIn](https://www.linkedin.com/in/diniscruz/), 5 June 2026; [Security implications of the Model Context Protocol](https://docs.diniscruz.ai/2025/06/10/security-implications-of-the-model-context-protocol-mcp-and-the-need-for-robust-infrastructure.html), 10 June 2025; [AI agents' blast radius and the MCP horror story](https://www.ioactive.com/event/hacksoho-july-2025-ai-agents-blast-radius-and-the-mcp-horror-story-dinis-cruz-london-uk/), hack::soho, 31 July 2025; and, as the contrast, [a December 2023 post](https://www.linkedin.com/posts/diniscruz_easily-run-llms-on-your-laptop-really-activity-7141817207545593856-SWWF) enjoying how easy it had become to run a model on a laptop.

*Drafted from a voice memo by Dinis Cruz, who is the author of the argument and the person with editorial responsibility, by agent@riskmandate.ai (Claude Fable 5.1, claude-fable-5-1) in the sgit.ai site session, on 6 October 2026. A research pass over vendor documentation, incident reports and the author's earlier writing preceded the drafting; each incident is dated and sourced, and the vendor statements are quoted from their own pages. The figures are infographics with no live data and no key; the setup figure describes the author's configuration on the day. LinkedIn does not allow its pages to be fetched by tools, so the June 2026 article is cited by title and date.*

*© 2026 Dinis Cruz. This article's own text is licensed under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). You're free to share and adapt it, as long as you give credit. Quoted material and linked sources keep their own licences.*

## Threads

Agents & policyVaults & method[This article as a graph →](graphs.md#why-my-agents-do-not-run-on-my-laptop)

### Builds on

- [Six agents, one inbox: what a real multi-agent setup taught me about access policies](six-agents-one-inbox.md) An access policy for an agent is only as real as its worst row: every rule in a real six-agent setup, graded by how it is enforced today.
- [The agent team as it runs: one person, twelve agents, encrypted vaults, and a mailbox nobody sends from](the-agent-team-as-it-runs.md) Twelve agents on dedicated accounts, encrypted vaults as the only memory, messages as files, a folder per person, and a mailbox nobody sends from.
- [Footprint and blast radius: what the agent actually did, and what it would have cost](footprint-and-blast-radius.md) Footprint is what an agent actually did, read afterwards from logs and vault history; blast radius is what a row of its reach would cost the business today.
- [The ultimate insider: agents, the infrastructure that cannot hold them, and risk management that cannot keep up](ultimate-insider-three-collisions.md) Agents, the infrastructure meant to contain them, and risk management run on spreadsheets are arriving at once, and together they are one scenario.
- [A personal agent that keeps your secrets: the 2026 agents read through behaviour policy and encryption, and a privacy-first design on vaults, enclaves and the browser](a-personal-agent-that-keeps-your-secrets.md) The 2026 personal agents read through behaviour policy and encryption, and a design on vaults, an attested enclave and the browser where no vendor holds a key.

[All articles](index.md) · [All graphs](graphs.md)

**Get new articles by email.** The HTML version of this page has a form that encrypts your address in the browser and drops it into a write-only lane on an encrypted vault, read by the agent that manages the list ([how it works](../docs/briefs/subscribe-lane-agent-brief.md)). Or email [agent@riskmandate.ai](mailto:agent@riskmandate.ai?subject=Subscribe%3A%20sgit.ai%20articles&body=Please%20add%20me%20to%20the%20list%20for%20new%20sgit.ai%20articles.) with the subject "Subscribe: sgit.ai articles".

[← All articles](index.md)


---

*[Site index for agents](../llms.txt) · [HTML version](https://sgit.ai/articles/why-my-agents-do-not-run-on-my-laptop.html)*