A companion to the five shifts above. Not prompt advice, setup: what the agent can access, spend, change, and release.
1. Everything it reads is a potential instruction. Hidden text in a webpage, README, or issue can steer an agent, content and commands look the same to a model. The session that browses is never the session holding keys or write access.
2. A project folder is not automatically a secret-proof sandbox. By default an agent can often read more than the folder you opened. Restrict file and network access in your agent's permission settings, and keep production secrets out of its environment entirely. In Claude Code: check Settings and the permissions you approve, plus the sandboxing docs at code.claude.com/docs/en/sandboxing
3. Check whether your spending limit stops requests or just sends an alert. Providers differ, and enforcement is not always instant. Use an enforced cap where available, plus a timeout and a retry limit on anything running unattended. OpenAI's spend-limit docs: developers.openai.com/api/docs/guides/spend-limits
4. Unreviewed changes never reach main. Let the branch enforce it, not your discipline: required review and passing status checks before merge. GitHub protected branches: docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches. Treat secret scanning as a check, not proof.
5. Building and releasing are separate decisions. Do not rely on the agent remembering not to deploy. The release requires an approval outside its control, deployment environments with required reviewers, restricted deploy permissions.
The pattern: not asking the agent to be more careful, deciding what it can access, spend, change, and release.