Local Developer Declares Todo App Too Proprietary for the Cloud

This is satire, although the repository has been classified at the highest available clearance level: “contains intentions.” At 8:47 a.m., local developer Martin Vale informed the six-person engineering group that no cloud-connected coding tool may inspect the company’s codebase. The reason, he explained, is that the application is “deeply proprietary.” The application is a todo app with Task, Project, and User tables, a React checkbox, and a function called markTaskComplete(taskId).

Vale did not say this casually. He said it while turning his laptop so that the quarterly-planning spreadsheet behind him could not be observed by the webcam. Then he opened a terminal and demonstrated the approved workflow:

export CLOUD_EGRESS_FORBIDDEN=true
./run-local-agent --model ~/models/fortress-coder.gguf --context ./ --approval-mode ask-everything

The command launched successfully after 93 seconds, during which the local model allocated 14 GB of memory, indexed 46 files, and asked whether package-lock.json was a trade secret. Vale approved the read. The model then proposed replacing an if statement with a ternary expression and consumed the remaining morning considering whether a due date could be represented as a date.

The threat model

The team’s security posture is built around a clear principle: competitors must never learn that tasks can be completed. The feared attacker is imagined to be a rival startup, operated from an underground room lit entirely by dashboard monitors, waiting for a cloud provider to leak the company’s unique PATCH /tasks/:id endpoint. Once inside, the rival will discover the strategic algorithm: set completed to true.

To reduce this risk, the repository has been removed from hosted issue tracking, hosted CI, hosted code search, hosted documentation, hosted artifact storage, and, briefly, the network. Pull requests are exchanged through an encrypted USB drive known as the Merge Stick. The Merge Stick lives in a lockbox whose combination is held by Vale, the head of engineering, and an external compliance consultant who has never seen the product but has strongly recommended more locks.

This has created a few minor operational tradeoffs. A new engineer cannot run the app until they obtain the private package mirror certificate, the offline secrets archive, the development database snapshot, the correct version of Node, and written approval to learn the name of the environment variable that points to Redis. The onboarding guide is 71 pages long, not counting its appendix, “Acceptable Uses of curl.”

The approved local stack

The local coding agent runs on a workstation assembled from components selected for their resistance to subpoenas. Its model file is stored on an encrypted volume called /vault/strategic-assets/, beside a folder of screenshots from a 2019 design sprint. The agent is forbidden from network access, which means it cannot fetch documentation, check package versions, inspect a dependency advisory, or discover that the migration command has changed. This is considered an acceptable price for sovereignty.

When asked to add pagination to the completed-tasks view, the agent produced a plan with 23 steps. Step 17 advised reviewing pagination conventions in the existing codebase. There are no existing pagination conventions in the codebase. Step 22 advised consulting the official framework documentation. The agent immediately denied its own request on security grounds.

The team has adapted. Developers now maintain a shared file named KNOWN_FACTS.txt, containing carefully vetted intelligence such as “the database is PostgreSQL” and “the server listens on port 3000.” Every change to this file requires two reviewers because context is an attack surface. A proposal to add the framework version was rejected after someone correctly noted that version numbers can reveal an organization’s technology choices to anyone who can read the repository.

Protection at the speed of work

The results are measurable, in the sense that someone has measured them. A normal request to rename “Todo” to “Task” now travels through the Local Inference Review Board, the Air-Gap Exception Form, the Dependency Silence Committee, and a 42-minute agent session in which the model is supplied the relevant source file one line at a time. Last week, the team shipped the rename without incident, except that the mobile client still says “Todo,” the API still says todo, and the database table remains todos to avoid an unnecessary data-movement event.

The policy does catch real risks. During a pre-commit scan, the local system found an exposed secret: VITE_API_URL=http://localhost:3000. The incident was contained. The variable was moved into a second file, which is ignored by Git, excluded from backups, unavailable to CI, and documented in a wiki that requires a VPN connection to reach from the office.

No one is arguing that code should be uploaded indiscriminately to every service with a chat box. There are repositories with customer data, regulated workloads, contractual restrictions, credentials, and genuinely valuable designs. There are also repositories where “proprietary” means that the empty-state copy says “Nothing here yet” rather than “You’re all caught up.” Treating those two cases identically is how a sensible security boundary becomes a daily ritual of self-denial.

A small classification exercise

Before banning a tool, the team now conducts a five-minute data review. Does the agent need source code, production data, secrets, or only a failing test and a narrow diff? Can sensitive files be excluded? Is the vendor’s retention and training policy compatible with the work? Is a local model actually good enough for the task, or will the developer spend an afternoon hand-feeding it dependency documentation? Most importantly: what is the concrete harm if this exact file leaves the laptop?

These questions have not weakened the program. They have merely revealed that the todo app’s most confidential asset is a seeded record reading “Buy oat milk.” The record remains protected, offline, encrypted, and available to authorized personnel after a short approval process.

The true observation beneath the joke is simple: privacy requirements should be specific to the data and the tool path. A local setup is valuable when the constraints justify its operational cost; calling every checkbox a state secret does not make the threat model stronger.