“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.
Related posts

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.