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.