Grant Rights, Don't Write Pleas
'Never touch production' in a rules file is a wish the agent can overlook. A scoped key that physically cannot reach production is a setting it cannot ignore. Every boundary you actually care about belongs in credentials and permissions, not in polite prose.
Why it works
'Never touch production' in a rules file is a wish: rules files get skimmed, compacted, and occasionally ignored under pressure — the agent that violates one isn't malicious, just probabilistic. A scoped key that physically cannot reach production is a setting, and settings don't have off days. Every boundary you'd be upset about crossing belongs in credentials, not prose.
How to do it
- Write the list: what must this agent NEVER be able to do?
- For each item, find the enforcing mechanism: key scope, read-only token, separate account, permission mode.
- Issue narrow credentials: staging keys for staging work; a token that can read but not delete.
- Point the agent at the scoped credential in .env — it can't exceed what the key allows.
- Keep the prose rule too, as documentation of intent — belt and braces, but the braces are the key.
- Audit quarterly: does any credential in .env grant more than its project needs today?
Copy this
prompt
Here's what you must never do in this project: [list]. For each item, tell me whether anything ENFORCES it — key scope, permissions, mode — or whether it's only a request in a file. I want the honest split.
What to watch for
- The dangerous drift: prose rules accumulate while credentials stay broad — six months in, the file says 'never' twelve ways and the key can still do everything.
- Fail the safe way: an over-narrow key produces a visible permission error you widen in a minute; an over-broad key produces an invisible risk you discover in an incident.
Sources
Original: conon.aiDocumentation: code.claude.com