AI Platforms

Agents need boring boundaries

2 min read

“Let the agent use my files” is not a permission model.

A useful grant names the surface, the identity, the side effect, and the lifetime:

{
  "files": ["src/content/blog"],
  "network": "localhost-only",
  "shell": ["pnpm markdown:check"],
  "secrets": "none",
  "duration": "this run"
}

The exact schema will change by product. The boundary should still be legible to both the user and the runtime.

A coding agent needs a workspace limit. A browser agent needs origin and account limits. A document agent needs file and sharing limits. An MCP runner needs tool-level limits because a search tool and a migration tool are not the same kind of action.

The model’s goodwill is not where the boundary belongs.

Credentials make this sharper. A valid token proves that the action can happen. It does not prove that the action matches the user’s intent. When an agent uses a credential, I want to know which identity it used, which resource it touched, and which approval covered the action.

I also want side effects in separate buckets:

  • read-only context
  • local edits
  • external writes
  • shell commands
  • credentialed calls
  • irreversible actions

A read-only lookup can usually run inside scope. A local edit can produce a diff. An external write needs explicit approval. An irreversible action may not belong in the agent at all.

Permissions should expire with the run. A grant that survives forever is a different product decision from a grant that exists to finish one task. The interface should say which one the user is making.

An approval is useful only when it names the work:

approved action: edit local file
target: src/content/blog/agents-need-boring-boundaries.mdx
visible evidence: proposed diff
allowed follow-up: markdown check only
expires: end of run

That record gives the system something to enforce and the human something to review.

Agents will keep improving at tool use. I want the walls around that tool use to stay deliberately uninteresting: narrow scope, explicit identity, visible side effects, expiring grants, and receipts.

Jeremy London

About Jeremy London

Engineering leader and builder in Denver. I write about AI platforms, agents, security, reliability, homelab infrastructure, and the parts of engineering work that have to survive production.