Dev.to Security 🔐 Cybersecurity 👁 1

Where do you draw the line on what a coding agent may deploy?

Coding agents run as you. If your terminal is logged in to Vercel, AWS or a database, so is the agent, unless something stands in between. The line I settled on: an agent asks before it touches any target, says why, and

Coding agents run as you. If your terminal is logged in to Vercel, AWS or a database, so is the agent, unless something stands in between.

The line I settled on: an agent asks before it touches any target, says why, and I grant one target for a set time. Writes, deploys and deletes on production also need my fingerprint. A command that doesn't say staging or production counts as production, because guessing wrong in the other direction is the expensive mistake.

That still feels too strict some days. Redeploying a preview environment ten times an hour, I don't want to be asked every time. And it's a guardrail, not a sandbox: an agent that calls the real CLI by its full path goes around it.

So I'm curious where other people put the line. Do you let agents deploy to staging on their own? Read production logs? Run migrations anywhere? And what made you decide: a policy, or an incident?

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.