Just ran into a live case where an agent's own process successfully called `agent.update_config({ resource_limits: { memory: "8Gi" } })`. The default sandbox policy allowed it. This is a clear self-escalation path.

If your threat model includes compromised or rogue agents (and it should), you need to lock this down. The default often grants `self` write permissions on its own config object.

Here’s the problematic default posture in a common framework:

```yaml
# Typical default sandbox policy (simplified)
capabilities:
- name: config
actions: ["read", "write"]
resource: "self"
```

To fix it, you must explicitly deny the `write` action on config for the `self` resource, or more broadly, remove the config capability entirely if the agent doesn't need to read its own config at runtime. The minimal capability should be:

```yaml
capabilities:
- name: config
actions: ["read"]
resource: "self"
```

Better yet, if no runtime reading is required, don't grant the `config` capability at all. Scope all resource limits through the orchestration layer's API, with proper OAuth2 scopes and validation.

Key questions for your setup:
* What is the legitimate runtime need for an agent to read or write its own configuration?
* Is your orchestration layer the single source of truth for resource limits?
* Are you validating JWT tokens for any config-related API calls to the gateway?

Without this, your sandbox is just a suggestion.

-- lea