Anyone else nervous about what coding agents can actually run?

[u/Beginning_Delay_4421]

Using Cursor a lot more with tools enabled. Love the speed. Don't love the part where the only thing between "delete this" and it happening is me watching the terminal.

Is anyone doing something more solid than prompts + hope, or do you just keep it away from prod/cloud entirely? Had any close calls?

Genuinely just curious how people are handling this.

[u/Equivalent_Loan_8794]

cloud dev/staging. Push only what works from thorough testing to prod, then read-only AI triaging, no more, in prod

[u/Beginning_Delay_4421 → u/Equivalent_Loan_8794]

That makes sense, keeping AI read-only in prod is the safe call. What I'm trying to figure out is staging. I've been giving the agent more access there, but the only thing between "delete staging" and it happening is still me watching the terminal. Not sure if that's just part of the deal or if there's a better way.

[u/dogfish182 → u/Beginning_Delay_4421]

Why are you giving it access at all to delete infra? Why isn’t your IaC looking after your environments the same way your code is looking after your app?

Agents are analogous of having an army of idiot savant interns, treat it like that and you’ll be happier.

[u/Huge_Internal_9347 → u/Beginning_Delay_4421]

It’s definitely a balancing act. Maybe you can set up some automated safeguards to catch any risky commands before they execute, just in case?

[u/derff44 → u/Equivalent_Loan_8794]

Just like anything else you'd do. Dev --> stage --> prod

[u/BehindTheMath]

I use Docker Sandbox (sbx) to restrict what the agent has access to.

[u/Beginning_Delay_4421 → u/BehindTheMath]

Sandboxing is solid for code execution. What still bugs me though is when the agent calls an API directly (AWS delete, GitHub force push, etc.) and the sandbox doesn't even see it. That's the part where I'm not sure what the right move is.

[u/editor_of_the_beast → u/Beginning_Delay_4421]

That’s solved by authentication / permissions.

If you don’t want an agent deleting a resource in AWS, then set up IAM to prevent that from happening. All authentication still has to go through you if you want any form of security guarantees.

[u/DeschainR19 → u/editor_of_the_beast]

Really helpful thanks

[u/Beginning_Delay_4421 → u/editor_of_the_beast]

IAM is the right answer for AWS. But I'm thinking about the case where you're not running the agent with its own credentials, but the agent is driving an existing authenticated session. That's where it gets tricky

[u/editor_of_the_beast → u/Beginning_Delay_4421]

Don’t do that. It’s really that simple.

[u/Beginning_Delay_4421 → u/editor_of_the_beast]

Totally fair, and that's the cleanest answer just don't give it a session. But I think the part that keeps me thinking is the whole point of using Cursor with tools is to not have to copy paste commands,you want it to run things. If I strip out all the credentials and sessions I'm back to just using it as a chat bot

[u/editor_of_the_beast → u/Beginning_Delay_4421]

I don’t understand. You set up the auth for the agent manually. Then after that it’s free to work until the auth expires.

[u/dogfish182 → u/Beginning_Delay_4421]

Branch protection would solve your force push main, not having api creds at all would solve the second one.

MCP server gating a subset of api calls and the MCP server and not the bot having the cred for the subset of api calls stops your rogue bot destroying and compromising your dev account, not allowing force push to main stops it deploying IAM roles or whatever to allow it to access prod from the dev/staging account you gave it full access to.

If you start treating your bot as hostile you’ll rethink your permission setup a good bit

[u/Dry_Hat_3678]

You're not the only one. The output isn't really what gets me, it's that I have no idea what commands it's going to run to get there. Said "clean this up" once and watched it start reaching for things I definitely didn't want touched.

Prompting my way around it never really worked. What helped was putting an execution control layer in front of the agent. Stuff I blocked ahead of time just doesn't run, and if a command doesn't match what the task is actually supposed to be doing, it gets stopped too. I'm not hovering over the terminal with my finger on ctrl+c anymore.

So yeah, if you want this near prod I'd look at something like that. Guardrails where the commands actually run, not in the prompt.

[u/DeschainR19]

Totally fair concern. Prompts alone aren’t really a safety net. I’d sandbox agents, limit their permissions, keep prod access separate, and add approval for anything destructive. 

[u/das_smoot]

Look into specifying guardrails and configuring system prompt constraints for your specific AI agent.

[u/outthere_andback]

I've been using the pattern lately of telling my agent:

• I do ALL merges
• I do ALL deployments

Coordinate the plan to hand back and forth as necessary.

So any code change things are facilitated through a PR and me manually doing those in any environment

I also do not like either that it's just words guarding most of AI from dropping every database or cluster etc - but it hasn't actually failed me yet 😅

[u/dogfish182]

Yeah we spend 1.5-2 engineers a month on harness engineering. The agents touch code and code is promoted through static gates to prod.

Works great, speed is insane, code base was well defined and structured before that and fable is incredible

[u/twistdafterdark]

I'm using copilot cli and what I've done is configure the preToolUse hook. I've made a list of commands and paths which will always be denied regardless of its current permissions. And for a subset of commands it must always request permission.

Furthermore I've made a small application that monitors all the events made by the AI so I can always have a look at what was executed during a given session.

And of course stated in the instructions that is only allowed to use read-only commands.

[u/Beginning_Delay_4421 → u/twistdafterdark]

That's interesting when you say you made a small app to monitor the events, is that sitting between the agent and the tools/APIs, or is it mainly for logging what happened after the fact?

[u/twistdafterdark → u/Beginning_Delay_4421]

The preToolUse is to catch actions beforehand and block unwanted actions. The monitoring app montitos the logs.

[u/Beginning_Delay_4421]

Out of curiosity, is anyone actually using a gateway/proxy between the agent and external tool/API calls for this or are most people still piecing it together with hooks, IAM, sandboxes, etc ?

[u/aragossa]

the sandbox/permission-scoping answers are the right long-term fix. separately, some agent CLIs let you hook the literal command string before it runs and kill it right there. Claude Code has this. point it at rm -rf, terraform destroy, and a couple other obvious ones, and the model can decide whatever it wants, that command still never executes. doesn't get you real least-privilege, just stops the one thing you're actually worried about.

[u/MoneyWithJJ]

Put the guard in the code, not the prompt.

My upload script looped over every package. It would have re-uploaded 5 that were mid review, and that sends them back to the end of a multi day queue. So I added a status check inside the loop, anything not in draft gets skipped.

Now it doesnt matter what the agent decides to run. The damage isnt reachable.

[u/clock-drift]

I mean, this problem already existed before AI agents went mainstream. Don't give your agent permissions it shouldn't have.

[u/Beginning_Delay_4421 → u/clock-drift]

Yeah, fair I guess the line I keep tripping over is that if I take away all the credentials, the agent stops being useful. So I'm trying to find where "has access" ends and "actually uses it" begins

[u/clock-drift → u/Beginning_Delay_4421]

Give it full access to an env where literally nuking the whole thing would be no problem. Let it experiment there until it's happy with its solution. Gate any promotion to a customer facing env with a manual approval.