Addendum on Architecture Choices: Local, Cloud, and Boundaries

The night before launch, Xiao A brought his deployment plan to Lao Z: "Let's put this Agent in the cloud and let everyone use it. That saves trouble." After a pause, he added: "And the cloud must be safer than local, right? The cloud vendors have professional teams."

Lao Z did not answer directly. He asked back: "Is local always safer? Is cloud always simpler?"

Xiao A froze. He was about to say "yes," but the words caught: he had seen a local Agent delete files by mistake, and he had heard of credential leaks in the cloud. Safety and simplicity, it seemed, had no direct relation to "where you deploy."

"That's a false premise," Lao Z said. "Security and operational cost come from concrete permissions, network, credentials, isolation, and operating procedures — not from a deployment label. This appendix serves Part I · Concepts and Part III · Build It. Consult it when you need to decide where an Agent runs and what data may leave. It offers no product rankings; vendor capabilities, prices, and regional availability are not verified here."

Lao Z went on to split the question in two: "'Where to deploy' is an architecture question. 'Who is responsible for what after deployment' is an operations question. Many people merge the two into one thing, and label-style conclusions like 'local is safer' and 'cloud is simpler' appear. Each of them cuts one half of a different problem away."

Xiao A wrote the two judgments in his notebook with a vertical line between them. Before, the moment someone said "security," the only picture in his head was "don't let data out." He had never asked separately: on my own machine, who can touch this data.

Why "local is safer" is wrong

Xiao A was not convinced. "Local data never leaves my machine. How is that not safe?"

Lao Z had him list what a local Agent can actually access:

• File system: the Agent process runs with your user permissions. It can read everything under your home directory.
• Network: unless you explicitly restrict it, the Agent can reach any internal or public address.
• Environment variables and credentials: .env, ~/.ssh, ~/.aws — if the process can read them, the Agent can read them.
• shell: the bash tool can run arbitrary commands, including rm -rf, curl calls that send data out, and installing a backdoor.

Xiao A glanced at those four lines and went a little red. "I really did think local was 'isolated by nature'."

"That illusion comes from one conflation," Lao Z said. "'Data doesn't leave my machine' and 'data on my machine is safe' are two different things. The first is a data-flow question; the second is an access-control question. A local deployment only places execution or storage on your machine; it does not guarantee that data stays there. Cloud model requests, telemetry, and tool network calls may all send data out. Keeping data physically on the machine also requires a local model and restrictions on all network egress. Access control still needs attention. An executor sharing your user identity with your files and credentials may have excessive permissions; verify the actual attack surface against the configuration."

"So the word 'local', by itself, guarantees nothing?"

"Right. The 'security' of local depends on how you configure permissions, how you restrict tools, and how you audit logs — exactly what you would do in the cloud. Treating 'local' as a security talisman is the most harmful illusion of all."

Xiao A looked at the four lines again and caught a detail: "None of the four says 'least privilege'."

"Because least privilege runs through all four, it doesn't take a line of its own," Lao Z said. "File system asks 'what can it read', network asks 'what can it connect to', credentials ask 'what can it take', shell asks 'what can it execute'. Each of them does the same thing: push the Agent's default capabilities down. The problem with a local deployment is precisely that it pushes them down the least by default: the process runs under your identity and can naturally read everything of yours. So what you verify locally is whether permission control was made explicit, rather than inherited by default."

Xiao A: "Is there a minimum bar for the security of a local Agent?"

"There is. One sentence: 'The Agent on my machine must not have more permissions than I explicitly granted it.'" Lao Z said. "It looks simple, but meeting it takes four concrete things: it cannot read directories you did not let it read, cannot connect to addresses you did not let it connect to, cannot take credentials you did not let it touch, and cannot run commands you did not allow. Only when you can answer 'yes' to all four can local talk about security. If even one cannot be answered, it is just a high-privilege process installed on your machine, and the deployment label has nothing to do with it."

"What is local actually good for, then?"

"Two things," Lao Z said. "First, a hard constraint that data must not leave the domain: if compliance requires data to physically stay on the machine, execution, storage, and model inference must all stay there, with restrictions on network egress such as telemetry and tool calls. Second, low latency and working offline: a local model does not wait on the network and keeps working when the network is down. But note, neither of these brings security automatically. Data staying in the domain only satisfies the data-flow dimension; the access-control dimension still has to be done. 'What is local good for' is a capability question. Don't use it to answer a security question."

Then what about the cloud?

"The cloud is not automatically safe either," Lao Z said. "An Agent in the cloud faces a different threat surface, but no smaller one: whether multi-tenant isolation is reliable, whether your API key scope is too wide, whether your logs leak user data, whether egress control really blocks outbound traffic. The cloud vendor provides the capability, but 'is it configured correctly' is your responsibility."

"Where exactly does the cloud save trouble?"

"It outsources operations: patching, scaling, backups, the machine room — none of that is yours," Lao Z said. "But every task you save turns into another one: you have to verify one more layer of trust. Whether the vendor's default configuration is isolated, whether you can get its audit logs, whether its deletion is a real delete or a soft delete. 'Outsourcing operations' is not 'outsourcing verification'. You hand the operations over; the verification still comes back to you."

The two threat models have different shapes as well: local risk concentrates in "the executor has too much permission" — it can do everything you can do; cloud risk concentrates in "default configuration" — you assume the default is isolation, when it may actually be shared. What you must check is completely different on the two sides, but neither side may skip verification because of a deployment label.

Xiao A thought for a moment and raised a concrete question: "If I run the Agent locally under a dedicated account with least privilege, doesn't that sidestep the 'too much permission' trap?"

"It reduces it, but doesn't sidestep it," Lao Z said. "A dedicated account limits the files it can touch, which is right. But that account still has to hold the API key used to call the model, still has to reach the network, and still has to run shell in some working directory. Least privilege is not 'is there a dedicated account'; it is 'how short is the list of capabilities actually granted to that account'. Many people open a new account and relax, only to find the new account can still read .env and still curl the public internet — a full-privilege account under a different name."

"So the verification action is," Xiao A picked up, "list what this account can actually do, and ask one line at a time: 'is this line really necessary'."

"Right. A deployment label does not buy you a shorter verification checklist. It only changes which items the checklist has to check," Lao Z said.

"Audit logs are also commonly left out," Lao Z warned. "The laziness most typical of a local deployment is 'the data doesn't leave anyway, so it doesn't matter whether I log'. But when something goes wrong, what do you trace with? Which commands the local Agent ran on your machine, which files it changed, what it sent out — if none of that lands in a log, a local incident is harder to investigate than a cloud one, because the cloud at least has vendor-side auditing, while local has nothing. This minimum observability has nothing to do with how you deploy. Any Agent deployment must have it."

"Applied locally, that's permission lists, network restrictions, log auditing, and backup and recovery — not one missing. The only thing that changes is where you do it: from the vendor's console to your own machine."

Five decision dimensions

Lao Z gathered the things to verify into one table. The core principle: each dimension must be asked as "what do I verify," not "which label do I pick."

Decision dimension	Verify for local / self-hosted	Verify for a hosted service
Data flow	Which files enter the context, the logs, and the model requests	Data retention, region, sub-processors, and the deletion path
Identity and credentials	Process user, credential storage, workspace permissions	Tenant isolation, token scope, revocation, and auditing
Execution boundary	The actual limits of shell, network, container / VM	Remote tool permissions, egress control, approval
Availability	Local model, disk, upgrades, and backups	Rate limits, service failures, degradation, data export
Cost	Hardware, maintenance, people, energy	Requests, storage, bandwidth, and runaway-loop budget

Xiao A looked at the table and asked: "How do I read this? Do I have to fill in both columns before it counts as safe?"

"You don't have to fill in both," Lao Z said. "Verification works by comparison against evidence. This table does not pick a side for you. Each dimension asks: on the side you intend to choose, which concrete things must be verified. Say you decide data flow goes local. Then you answer 'which files get read into the context? will the logs hit disk? do the logs on disk contain PII? who cleans them up when the process exits?' Only after those four questions do you know whether your local data flow is really safe."

"When two options are fighting, this table can also turn the fight into evidence gathering," Lao Z said. "When 'local is safer' and 'cloud is simpler' each insist they are right, don't argue over who is correct. Spread the five dimensions out and list what each side 'must verify'. The column that can state concrete questions stands; the column that can only shout slogans is running naked. The use of this table is to force both sides to trade abstract conclusions for concrete to-dos."

"Of the five dimensions, the deletion path is the one most easily forgotten entirely," Lao Z warned. "Everyone checks how data comes in; few check how data goes out. PII in the logs, old versions in the cache, backup copies in the cloud — after this data 'came in', when is it deleted, who deletes it, and can the deletion be verified? An unverified deletion path means the data has no life cycle in your hands. That holds on both sides, but in the cloud, which adds one more layer of 'the data is on someone else's disk', it deserves a question of its own."

Three trade-offs people commonly stumble on are hidden inside this table:

• Data flow vs availability: keeping data local is steadier, but once the local disk dies and no backup was made, the whole cost of data recovery lands on you. Cloud redundancy is better, on the condition that you accept data leaving the domain.
• Execution boundary vs cost: a container or VM sandbox locally gives strong isolation, but both operations and compute are expensive; outsourcing operations to the cloud is cheaper, but egress control depends on the vendor's configuration, and the vendor's defaults are not necessarily in your favor.
• Identity and credentials vs availability: locally you can build the finest-grained credential isolation, but who rotates and who revokes — you carry that yourself; the cloud has managed key services, but you gain one more thing to verify: the access scope of the key service.

"These three trade-offs," Lao Z said, "show that not one column is a free lunch. Take the benefit on one side, and you must pay the matching verification cost on the other. What this table lists is the price each option charges. The decision is still yours to make."

Xiao A pointed at the "execution boundary vs cost" row and asked: "Isn't this row often fobbed off with 'one Docker container and it's solved'?"

"It is, and the fob-off is very common," Lao Z said. "Docker is indeed an isolation mechanism, but 'using Docker' is not 'isolation configured': the container's root user, the host directories you mount, CPU and memory with no limits set — any one of these is a bypass. What you verify is 'once the container runs, what can the process actually still touch', not 'does the docker run command line contain the word docker'. This is the same lesson as local and cloud: a container is also a boundary, and it too must be verified line by line. Slapping a label on it doesn't count."

Xiao A ran the three trade-offs through his head and asked the reverse question: "Is there a combination where all three pairs fall on my side, with the cost minimal?"

"No. But there is one approach that comes close: layer by asset," Lao Z said. "Split your data into three tiers by sensitivity. Public: it may go out freely. Internal: it doesn't leave the domain but must stay usable. Sensitive: local only, and least privilege. Then let each layer choose the boundary that suits it: sensitive data goes local with strict isolation, internal data goes local or to a trusted region, public data may go to any cloud model. The cost of layering is higher configuration complexity and several boundaries to maintain. But compared with 'put everything in one cage and pray', layering is the more honest approach."

"This layering sounds close to the idea behind zero-trust networking," Xiao A said.

"The idea is shared; the landing is different," Lao Z said. "Zero-trust is 'never trust, always verify' at the network layer. Here it is 'each data flow has its own boundary, each verified separately' at the Agent layer. Don't mistake the name for the solution. The point is that action of verifying per asset."

"For each tier, you not only pick a boundary," Lao Z said, "you also write down where it goes when it degrades. Public data goes to the cloud — what happens when the cloud is down? Fall back to a small local model, or fail outright for the user? Sensitive data stays local — what happens when local space runs out? Delete old backups, or stop and wait for a human? A boundary without a degradation path will, on failure, automatically make a decision you have never verified. Security incidents often start exactly there."

"Layering follows the data," Lao Z added. "A file goes to the cloud as 'public' today, gets marked 'sensitive' tomorrow, and its path has to switch with it. During the switch, did some copy get forgotten? That is why the deletion path and the degradation path must be written together: data changes sensitivity, and the boundary sensitive data deserves must be able to catch it."

Xiao A finished the whole table and asked: "How, exactly, do I verify 'local is safer'?"

"Don't ask 'which is safer'. Ask verifiable questions," Lao Z said. "A vague conclusion — 'local is safe', 'cloud is simpler' — cannot be falsified; a concrete question can."

Verifiable questions beat conclusions

Lao Z had Xiao A translate "local is safer" into four verifiable questions:

• Can an untrusted repository read files outside the workspace? If the read tool's workspacePath check can be bypassed with .., then "local" is not safe at all.
• Does the UI show the actual destination and arguments before anything goes out? If the model wants to curl an address, can the user see it and refuse before execution?
• Is there an idempotency strategy after a dropped connection? If one request was half executed when the network broke, will a retry charge twice or send the email twice?
• After the source document is deleted, when are the index and the backups deleted? Data residue is a privacy risk, and local and cloud must both answer it.

"Translating these four questions is a two-step trick," Lao Z said. "First take the other side's conclusion and break it into an assertion, say 'local is safe'. Then give each assertion a test that could overturn it. If the test cannot overturn it, the conclusion holds provisionally; the moment one does, the conclusion is void on the spot. A security conclusion you cannot translate into at least one executable test stays as talk only. If you cannot answer even one of these four questions, the deployment should not go live — local or cloud, either."

"In what order are these four questions arranged?"

"In the order of 'most easily overlooked'," Lao Z said. "Everyone asks the first one — out-of-bounds reads are the most obvious. Already half as many ask the second, because outbound visibility only shows up once you run the UI. Half as many again for the third, because an idempotency strategy only comes to mind after an accident. Almost no one asks the fourth: deletion is the last mile, forgotten long before acceptance. The order itself is a checklist. Answer the first two and you guard against 'being stolen from' — data read out. Answer the last two and you guard against 'being misused' — double charges, and 'being left behind' — deletion that isn't thorough."

Xiao A pressed: "Why does 'translate into verifiable questions' work so well?"

"Because the sentence 'local is safer' can be neither confirmed nor falsified. Anyone can stick to their own version and no one convinces anyone," Lao Z said. "But the question 'can .. bypass workspacePath' — run one test and you know: either it can, and there is a hole, or it cannot, and you are safe for now. Translating a conclusion into a question drags you from quarreling to running tests."

"These kinds of answers expire," Lao Z said. "'.. cannot bypass workspacePath' means it cannot bypass it today. Change the version, the file system, or the URL decoding method, and maybe it can. So after translating into questions, write 'when do I re-verify' into your calendar. This is the same requirement as 'a conclusion must be reproducible' in a laboratory, only with the interval stretched from 'at commit time' to 'at every change of environment'."

What pi-mono's code can prove

Xiao A asked a concrete question: "If I read the pi-mono code as finely as possible, can that prove the deployment is safe?"

"It can only speak to certain boundaries. It cannot prove the whole deployment safe," Lao Z listed the boundaries visible in pi-mono one by one:

• Provider authentication is resolved in applyAuth in packages/ai/src/models.ts: this proves credentials are merged; it does not prove credential storage is secure.
• Tools and sessions are assembled by the host: this proves capabilities are declared explicitly; it does not prove the declaration is least privilege.
• The protocol decoder has a size limit: this proves an oversized frame won't blow up memory; it does not prove the protocol layer is immune to all attacks.
• Mutations are serialized through a queue: this proves writes to the same path won't step on each other concurrently; it does not prove the written content itself is correct.

"It cannot, on its own, prove that a given deployment meets a compliance or isolation requirement," Lao Z stressed. "Code boundaries are part of deployment security, but compliance (GDPR, SOC 2), network isolation, key rotation, and audit log retention all have to be verified separately at the deployment layer."

Xiao A went on: "How do I tell whether a security claim should be verified against the code or against the deployment?"

"Look at the subject of the claim," Lao Z said. "If the subject is code, verify it against code. If the subject is the environment, verify it against the deployment. 'Authentication is merged before a model request' — the subject is applyAuth, check the code. 'This deployment only allows internal network access' — the subject is the network configuration, check the firewall and the routing. 'Keys are rotated on a schedule' — the subject is an operations process, check the schedule and the alerts. Find the subject of the claim and you know which layer's evidence to open. Using code to prove an environmental claim is cross-layer evidence gathering — and it proves nothing."

"So no matter how finely I read the code, I still can't 'prove security'."

"Right. Code tells you that certain boundaries exist. The complete security evidence chain also includes: how the runtime configuration takes effect, how keys are injected, who has access, and how you trace a failure. Code is one link in it. Miss any other link and the deployment claim can't stand."

"'Done in the code' and 'done at deployment' must be viewed separately," Lao Z said. "A path check in the code does not mean the live process runs that check: it may have been switched off by an environment variable, may have been bypassed, or may be an old version. Reading the code confirms what should be. What actually is, running in production, has to be confirmed by deployment verification — and between them sit configuration and version, the two layers most prone to surprises."

Mixed boundaries are the norm

At last Xiao A asked: "So do I pick local or the cloud?"

"Most real systems are mixed," Lao Z said. "Model inference runs in the cloud, because a big model won't run locally. Session storage stays local to retain a local copy, but session content in model requests may still leave the domain. Tool execution runs local, because it has to change your code. Each layer has its own boundary, and each one must be verified separately."

"Let me clear up one common misunderstanding first," Lao Z said. "A compromise means the same data giving ground in the middle. A mix means different data each taking its own best path, without interfering with one another. The test is simple: have you drawn an explicit path for every class of data? If you cannot draw that path, what you have is a mishmash of 'a bit of everything everywhere'."

"A common counter-example is 'sessions stored locally'," Lao Z added. "If the sessions really are stored locally, but the local process's logs then send the whole session content to the vendor as telemetry, your 'sessions never leave the domain' is nominal. To verify where data lands, you verify where every copy of it lands: the source file, the logs, the backups, the telemetry — not one may be missed."

Lao Z sketched for Xiao A the path data takes through a mixed system: the user's request first goes to local tool execution, which changes files; the context is assembled locally and sent to a cloud model for inference — the code may leave at this hop; after the cloud returns, the result is written back to the workspace locally, and then the logs are written to disk. Every hop on this chain is a boundary. At the hop from local to cloud, data left the domain. At the hop back from cloud to local, returned content entered your file system. The threat models of the two hops differ, and so do the verification methods: at the outbound hop, ask "what was sent? was it minimal enough?"; at the return hop, ask "will the returned content be executed as code?".

Xiao A stared at the "logs written to disk locally" hop: "Does the logging hop count as a boundary too?"

"It does, and it's the one most often missed," Lao Z said. "The log is the third copy of your data: one in the file, one on the model's side, one in the log. Many systems verify the first two carefully, while the log copy is assumed 'it's local anyway, it's fine'. The result is a log holding the full conversation, the full commands, even plaintext keys — a copy of sensitive data nobody guards. When you verify data flow, verify what the logs record as part of it. This has nothing to do with whether the system is mixed, but a mixed system misses it most easily, because that hop looks the least conspicuous."

"The benefit of a mix is taking the best of each side," Lao Z said. "The cost is that the number of boundaries doubles. Each extra hop adds one more to-do: 'what verification does this hop have'. Many people think a mix means taking the cheapness of both sides. In fact it means doing the verification of both sides."

"Where do I start verifying the boundaries of a mix?"

"Start at the hop where data leaves the domain," Lao Z said. "In a mixed system, most of the risk concentrates in one or two critical hops: local to cloud, where data goes out; cloud to local, where content is written back. Make those two hops solid first. Rank the remaining hops by value density: the hop whose failure causes the worst damage gets verified first. Don't aim to verify every hop at once — that isn't sustainable. Ranking by risk is."

"Every hop must have its own switch," Lao Z added. "The hop that sends context to a cloud model, for instance, must be switchable off by a single configuration. After you switch it off, can the Agent still degrade to a purely local mode? If it can degrade, the boundary really exists. If it can't, your so-called mix is a one-way binding, and sensitive data had no choice at all."

Lao Z had Xiao A copy this principle into his notebook:

Decision principle

First clarify the assets (what data, what permissions, what side effects), the threat model (who can attack, from where, how much is lost), and the acceptable loss; then choose the boundary of each layer (local, cloud, or mixed). Deployment location cannot substitute for authorization, approval, and verification.

"This decision principle can actually be compressed into a plainer question," Lao Z said. "For this asset: where do I accept it appearing, who may touch it, and how bad a loss can I accept when things go wrong?" Write all three answers clearly, and the deployment location surfaces on its own. Conversely, people who choose the location first and talk about the assets afterward usually discover on the night before launch: this location cannot carry the threat model of this asset at all.

Back to the goal of the whole book: an Agent's security depends on every layer having a verifiable boundary; the deployment location itself cannot give that guarantee. The threat model, trust boundaries, least privilege, and approvals established on the security side of this book must land here in concrete deployment decisions, and every decision must be translatable into an executable question to verify.

Xiao A flipped his notebook back to the first page and struck out both "local is safer" and "cloud is simpler", writing the same question beside each: "Which dimension, verify what, and how often re-verify?" He knew that next time someone tried to persuade him with a deployment label, this one sentence could pull the discussion straight back to verification.