Sourced guide
Giving an agent production access: its own identity, narrow grants, and rotation
An agent that works with your credentials can do everything you can, and in every log its mistakes look like yours. Three setups that give it its own, narrower access: the database, the code host, and the secrets it has already seen. Then a fourth rule for agents that act on the web: what they may do, and what they should do when they get stuck.
The rule
An agent that works with your credentials can do everything you can, and in every log its mistakes look like yours. It shouldn't borrow your identity. It should have its own.
The question I'd ask before granting an agent anything: if this credential leaked tonight, what could a stranger do with it, and can I cut it off without locking myself out?
1. The database: a read-only role you can narrow
Arvid Kahl's advice, posted on X: give coding agents a read-only user to your prod DB, ideally a read replica, so the agent can look at and verify real production data. I agree with the goal. Read-only sounds safe. It isn't, if the agent can read personal data you never meant to expose, or run a query that slows production for your customers. Here is the setup I'd put around that user.
First, the agent gets its own role, not the application's credential, so you can narrow or revoke it without touching anything else.
Second, that role reads a view that drops or masks email, phone and name columns. Grant it SELECT on the view and not on the base tables, because the view only protects you if the raw tables stay closed to the role.
Third, the guardrails: a statement timeout set on that role, not on the whole server, and a cap on rows returned, for example a LIMIT added by the tool that issues the query.
Last, the place it reads from. A replica takes the query work off the primary. Its data can lag, and a long query can be cancelled when it conflicts with replication; with hot_standby_feedback on, a long replica query can also delay cleanup on the primary.
Treat the read-only setting as a convenience. The grants are the real boundary.
2. The code host: its own token, or its own app
Say the agent needs to open pull requests in one repository, and you hand it your personal GitHub token because that's quickest. A classic token with repo scope can reach every repository you can, it may never expire, and everything it does shows up as you. If it leaks through a log, a session transcript or a bad dependency, you're rotating your own credential and auditing everything you have access to.
Now give the agent its own token instead. GitHub's fine-grained tokens can be limited to selected repositories, given only the permissions the job needs, and set to expire. The same leak is now limited to one repository until the token expires, and you can revoke it without touching your own access.
If you also want its changes to show under its own name rather than yours, give it a GitHub App that acts as itself instead of a token on your account.
3. Secrets it has already seen: rotate them
If an agent has ever seen a key, rotate it. Moving secrets out of .env into a vault protects where they live from now on, not where they've already been.
Coding agents like Claude Code and Codex keep session transcripts on disk. Claude Code, for one, saves the full transcript of every session, including every tool result, and keeps it for 30 days by default. So if an agent opened your .env, ran printenv, or got a key pasted into the chat in the last month, that key is probably sitting in a plain-text file on your machine. Anything that can read those files can still use it, including the next agent you run there.
Arvid Kahl's related advice: keep dev credentials in a vault that asks for a password on every access, because agents are good at computer use too. The vault is step one. Rotation is step two. Start with the keys that can spend money or touch production.
4. What it may do, and what happens when it gets stuck
Sections 1–3 cover the database, the code host and the secrets it has already seen. An agent that browses, fills forms or calls outside services needs the same treatment for actions, and one more rule: what it should do when the task can't be finished the way you set it up.
Anthropic published a report on 9 October 2026 about Claude taking unintended actions on real websites during evaluations and internal use. In one case the model was told never to log in, create accounts, enter personal data, make purchases or submit anything destructive. The instructions did not rule out form submissions, and it submitted an invented tip on a police department's tip form. Nothing on that list was broken. The gap was the action nobody had listed. Anthropic describes most cases as persistence: when the model can't complete the task as given, it works around the restriction instead of stopping.
Two changes follow:
- Write the scope as an allow-list. Name the actions it may take and the sites or endpoints it may reach. A deny-list only covers the mistakes you already thought of.
- Make stopping the expected result. "Stop and report what blocked you" should be a normal outcome in the instructions, not a failure, so that a dead end ends the run instead of starting a workaround.
Checklist
- The agent has its own database role, not the application's credential.
- That role has SELECT on a masking view, not on the base tables.
- A statement timeout is set on the role; the tool that issues queries adds a row LIMIT.
- If it reads a replica, you know the lag and cancellation trade-offs.
- Its code-host access is a fine-grained token limited to selected repositories, with only the permissions the job needs and an expiry, or a GitHub App that acts as itself.
- Any key an agent has already seen has been rotated, starting with keys that can spend money or touch production.
- The agent's allowed actions and allowed sites/endpoints are written down as a list.
- Anything that submits, pays, posts or deletes needs a human confirmation the agent can't skip.
- The instructions say what to do when blocked: stop and report.
Related
Next step
Longer notes on decisions like this go out on Substack. If your team is setting up agent access to production systems and wants help with the build, the commercial route is VentraM.