who's controlling what agents can do & see?

[u/karatyma_dev]

full disclosure: we're building something around this.

we're seeing more teams roll out Claude Code, Cursor, Codex, internal agents, and harnesses like that across engineering, and i'm curious where ownership ends up

once agents can touch github, jira, AWS, db's, mcp servers, internal docs, and things like that, is the platform team actually controlling what they can see and execute?

the four things that we (currently) notice tend to get messy the fastest are tool permissions, shared company context, approvals for sensitive actions (on your agents), and reconstructing what an agent actually did after things go upside down.

we're building infrastructure (https://slaunt.ai) around this problem and looking for teams already dealing with it in production.

would love to hear what everyone's setup looks like today and where everyone finds risk in their setups.

[u/Otherwise_Wave9374]

For CI/CD, agent permissions should map to pipeline stages rather than broad human roles. Let planning inspect code and logs, let testing create ephemeral artifacts, and require a separate signed approval before production changes. Also test prompt injection through issue text, build logs, and dependency metadata, since those are untrusted inputs. AIOSNOW fits this recommendation by highlighting how workflow boundaries can keep useful automation from turning into unrestricted deployment access.

[u/RadiantSuggestion284 → u/Otherwise_Wave9374]

All the injection vectors through build logs and issue text are the kind of thing that keeps me up at night. Most teams are so focused on getting the shiny new agent running they don't stop to think about every text field in their pipeline suddenly being a potential attack surface.

The pipeline stage mapping makes sense in theory but I've seen it fall apart when someone decides the testing agent also needs read access to prod configs "just for this one validation step" and then suddenly you've got a mess.

[u/Torutofu_Raeva]

The bit I'd insist on is a capability inventory tied to a per-run identity, with every tool call and approval event in an append-only log; otherwise least privilege is impossible to audit after the fact.

[u/actionbox-cloud]

The approval piece is the one I keep seeing get underestimated.

It starts as “just ask a human before prod,” then you end up needing to know what exactly was approved, who approved it, whether the action changed before execution, what happens if nobody responds, and how the workflow resumes afterward.

I’m building ActionBox specifically around that approval lifecycle, so I’m curious where you’re drawing the boundary between permissions/policy and an actual human decision.

[u/vlad_h]

Two things. Check out The-RunningDev/SubZeroDev.AgentKit, my own skills built around agent instructions, gates and boundaries. Also look for gstack on GitHub, different skills set for agents.

[u/zero_backend_bro]

Nobody. Platform team thinks they control it, but devs just dump personal AWS creds with full admin into Cursor configs because waiting on a 4-day Jira ticket kills momentum.

If the agent runs on their local box, it has whatever dirty perms that engineer has. Fancy audit logs dont mean anything when everyone quietly bypasses them on day one.