The guardrail the agent can't PATCH

Your agent product lets customers tune their agent over HTTP: model, defaults, workflow preferences. PATCH /api/v1/agent/settings takes all of it.

It does not take deny_list. Or allowed_directories, hooks, mcp_servers, tools. Send one of those and the answer is 403 settings_key_protected. The security-load-bearing keys change by editing settings.json on disk, not by any call to the agent's API. A prompt injection that talks the agent into "relaxing its own restrictions" is talking to an endpoint that will say no.

You didn't build a permissions model for settings. The line between configuration and guardrail was drawn for you, and it's drawn at the protocol, where the model doesn't get a vote.

The agent can be reconfigured over HTTP. It can't be disarmed over HTTP.