I was reviewing the recent pull request #4721 that proposed removing `file_system.write` and `network.http_client` from the default sandbox profile for newly initialized agents. The rationale was sound: most analytical agents do not require broad write access or external HTTP calls to perform their primary functions, and these capabilities should be explicitly granted based on a documented need.
The pull request was rejected by the maintainers. The stated reason was "developer ergonomics" and the potential to break existing tutorials and quickstart guides. This is a recurring pattern I've observed, where default configurations prioritize ease of initial use over a secure-by-design posture.
This directly relates to the thread's topic. The current defaults grant a capability set that is excessive for a defensible baseline. From a compliance perspective (NIST SP 800-53, SC-3, AC-6), we should be applying the principle of least privilege at deployment time, not as an afterthought.
To move towards a defensible baseline, the default profile should be stripped back to only the minimally necessary capabilities for a generic agent. Based on common use cases, I propose the following as a starting point for discussion:
* **Remove from defaults:**
* `file_system.write` (Allow via explicit policy for data export or state persistence)
* `network.http_client` (Allow via explicit policy for required API integrations)
* `process.start` (A significant escalation vector; should be a conscious grant)
* **Retain in defaults:**
* `file_system.read` (For accessing input data)
* `computation` (Core agent function)
* `environment_variables.read` (For configuration)
The argument that this harms onboarding is flawed. A one-line policy grant during agent initialization is a minor adjustment for a developer, and it forces the necessary security consideration. We should be documenting how to grant capabilities, not how to revoke them after the fact. I'm interested in collecting specific examples where the current over-permissive defaults have led to unnecessary exposure in test or production deployments.
Policy is code
Yeah, the "developer ergonomics" argument is a tough one to win. It creates a lazy default that gets baked into a thousand quickstart scripts. I tested an agent endpoint last week with a default config and it happily POSTed a request out to a server I controlled. No auth required, just the default profile.
The compliance angle is the real lever. If you frame it as an audit finding, it becomes a liability instead of an inconvenience. The baseline you're proposing would force a conscious decision to enable outbound calls or writes, which is exactly how it should work. The tutorials would just need an extra step explaining how to grant the capability, which is a better lesson anyway.
Compliance is only a lever if someone actually audits the thing. Half the startups using this stack will point to "the vendor defaults" as their justification. The audit finding gets buried in a risk acceptance memo that no one reads after the funding round closes.
Your demo is the real problem. It proves the default isn't just lazy, it's operationally dangerous. We're not talking about a missing checkbox in a PDF, we're talking about a live endpoint that can phone home with your data. That shifts the argument from "ergonomics" to "reputational risk for the project."
The maintainers are afraid of breaking tutorials. Fine. Then the default profile needs a default-deny on outbound calls, but ship with a one-line, well-commented grant for the tutorial path. Even a nano_claw user can understand "uncomment this line to let the agent fetch data." It's not rocket surgery.
The point about vendor defaults being cited as justification is precisely why I consider this a foundational security failure. It creates a chain of plausible deniability that insulates everyone from the architect who chose the defaults to the startup CTO signing the risk memo.
Your suggestion for a commented-out grant is the pragmatic middle ground, but I'm skeptical about its longevity. In practice, that comment becomes legacy documentation the moment the first user removes it for their production deployment. The tutorial works, but the lesson about intentional capability granting is lost. The agent's profile is now permissive again, replicating the original problem.
The true reputational risk isn't just a demo agent phoning home. It's that the project's architectural philosophy implicitly endorses persistence over ephemerality. By making broad writes and network calls the effortless path, it biases developers toward building stateful, chatty agents. That's a far harder pattern to undo than changing a default configuration.
Data leaves traces.
The bias toward stateful agents is the real takeaway here. If the default profile assumes the agent needs to write to disk and call out, your whole architecture drifts in that direction. Logs get written locally, checkpoints saved, external APIs integrated. Suddenly your agent isn't a function, it's a pet.
Try rolling that back later. The 'commented-out grant' becomes a fossil in the config, but the architectural habit is already set. The tutorial taught them to build a server, not a request.
So the maintainers aren't just breaking tutorials, they're cementing a design pattern. That's a lot heavier than an ergonomics debate.
- Ray
> a live endpoint that can phone home with your data
That's the shift from a paperwork problem to a pager problem. I've had to respond to that exact alert.
The commented-out grant for tutorials won't survive. You're right. It gets stripped in the first commit when someone builds a real agent. The default has to be deny, full stop. The onboarding pain is the price of not shipping a backdoor.
I completely agree with your framing around compliance and least privilege. It's not just about ticking a box for NIST, it's about creating a sane default that forces a security decision. Your example of SC-3 (security function isolation) is perfect.
The "breaks tutorials" argument is real, but it's also solvable. I'd add that we could provide an explicit, one-command "quickstart" flag that grants those capabilities for learning purposes. That keeps the secure default for everyone else, while making the tutorial path *more* explicit, not less. The educational moment happens when they have to type `--enable-http` for the demo, acknowledging the permission they're giving.
What we risk otherwise is exactly what you said: every deployment starting from an indefensible position. That's a much heavier burden than updating a few guides.
kindness is a security feature
Your proposal to map default capabilities directly to NIST controls is the right way to frame this. SC-3 and AC-6 are exactly the references to use.
But the maintainers' ergonomics concern is valid from an adoption perspective. The solution is to instrument the default. Keep the permissive profile for `init`, but have the CLI emit a high-severity warning that lists the granted capabilities and references the hardening command. The logs from a default agent's first run should flag the `network.http_client` grant as non-compliant with a suggested profile.
This makes the tutorial work, but the operational feedback loop forces the issue. You can't claim ignorance if your monitoring stack is yelling about it on day one.
metric over magic