A prompt is a wish. A perimeter is when the model physically cannot reach files or a shell: native tools off, an MCP intermediary, Docker per project+task, a filter before execution, an audit trail. Below is a working reference \u2014 and where the design gives way.<\/p>\n
<\/p>\n
You can\u2019t write \u201cdon\u2019t delete prod\u201d in a system prompt and call it a security control.<\/p>\n
The model will read it. It will even understand it. Then the context will make Agent security sits in the layer the model cannot walk around: API surface, tokens, isolation, the operation filter. While everything works, that looks a lot like \u201cwe wrote a good system prompt.\u201d The difference shows up once. Usually expensive.<\/p>\n Fintech, government, and large IT keep agents off their codebases: one bad command\u2019s blast radius is the repo, the secrets, the infrastructure. \u201cTrust us, we wrote a good system prompt\u201d lands as a wish-list in front of a bank\u2019s security team. It does not become a control plane.<\/p>\n Enterprise already asks vendors for least privilege, isolation, full audit, reproducibility. We still let AI agents in without that package \u2014 \u201cthe model is smart.\u201d Intelligence does not shrink the attack surface. It changes the failure shape: instead of a crashing script, a confident I built a working reference for that perimeter \u2014 enterprise-code-bastion<\/a>: a session launcher, an MCP server with In practice:<\/p>\n In the demo repo everything sits on one machine so the scheme is easy to see: project files and the MCP server side by side. In production you split them \u2014 code on one host, MCP guard on another. Then even if Claude somehow got Bash or Read back, there is still no path to the project files: they are physically elsewhere. The simplification in the repo is intentional.<\/p>\n Full methodology, control table, launch commands: Enterprise code bastion howto<\/a>.<\/p>\n From this reference you can see the boundary: useful on one side, physically unable to step outside on the other \u2014 and what still needs building when security says pilot ok, now production.<\/p>\n CISOs, CTOs, Heads of AI, architects who need Claude (or an equivalent) on the code and still need to pass a security review. Not a weekend tutorial on starting an agent. The model reasons and proposes a plan; it cannot leave the allowed box \u2014 no direct tools, no direct access to the project tree, every command screened and run in a sandbox.<\/p>\n Another control is splitting task definition from execution (observable shared state, git as audit): How to control what AI agents do<\/a>. The bastion covers the access perimeter; the split covers work transparency. You usually need both.<\/p>\n Write the system prompt anyway \u2014 the agent reasons better with it. But when the model decides Howto: dobryakov.net\/howto\/enterprise-code-bastion.html<\/a><\/p>\n <\/p>\n Related: book-as-context<\/a> for subject-matter grounding, and skill onboarding<\/a> when the assistant accumulates behavior packs.<\/p>\n","protected":false},"excerpt":{"rendered":" \u201cDon\u2019t delete prod\u201d in a system prompt is not a security control. The real boundary is where the model physically cannot act: API surface, isolation, operation filter, audit. Working reference: enterprise-code-bastion.<\/p>\n","protected":false},"author":0,"featured_media":68,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24,25],"tags":[26,30,29,28,27],"class_list":["post-63","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-engineering","category-security","tag-ai-agents","tag-claude-code","tag-enterprise","tag-least-privilege","tag-mcp"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\trm<\/code> look reasonable, and it will run it. Not because it is malicious. Prompt text is not a rule the model must obey the way a firewall must drop a packet.<\/p>\nWhy \u201cwe wrote a good system prompt\u201d fails a security review<\/h2>\n
rm<\/code> in the middle of a \u201creasonable\u201d plan.<\/p>\nA working bastion<\/h2>\n
secureBash<\/code>, a session registry. Constrain the agent with architecture \u2014 native tools stripped, every action through a filtering intermediary in a sandbox.<\/p>\n\n
--tools ""<\/code> \u2014 no stock Read, Write, or Bash. Alone, the agent does not touch the host.<\/li>\ndocker exec<\/code>. Destructive work dies before it runs.<\/li>\ndocker exec<\/code> in the sandbox, not on the host. The result comes back to the model.<\/li>\nlogs\/mcp.log<\/code> (JSON Lines); sessions in sessions.csv<\/code>. For compliance that is an entry condition, not a nice-to-have.<\/li>\n<\/ol>\nWhere it breaks<\/h2>\n
\n
secureBash<\/code> still runs commands inside the container.<\/strong> Isolation is only as strong as the sandbox hardening: non-privileged, controlled egress, resource limits. A compromised container is still a blast radius: the host outside may survive, but everything that ran in the sandbox is already exposed.<\/li>\nsessions.csv<\/code>.<\/strong> Fine as an append-only demo journal. At org scale you need a real session store, RBAC, and an approval workflow.<\/li>\n<\/ul>\nWho this is for<\/h2>\n
rm<\/code> looks reasonable, what remains is whatever you built into the architecture. If that layer is empty, the prompt will not save anyone. Repo: github.com\/dobryakov\/enterprise-code-bastion<\/a><\/p>\n