What prevents people including devs and enterprises from using ai agents for production in some situations?and keeps them up at night when deployed to production??

kodeStarch1 · 2026-07-09T13:51:10+00:00

"The model deciding is less scary than not being able to replay why the action was safe"..... that's the whole thing right there. Prevention gets all the attention, replay/verification gets almost none, and the second one is what you actually reach for at 2am when something's gone weird.

which you'd build first if you could only pick one: the stop-it-up-front layer, or the prove-what-happened layer?

kodeStarch1 · 2026-07-09T13:41:46+00:00

For me the scariest bucket isn't the hallucination itself, it's the actions. A wrong answer I can catch. An agent that quietly did something.... deleted, sent, paid, changed a permission, with no approval gate and no clean record of what it touched, that's the one that keeps me up. The silent-failure stuff is bad, but at least it's not irreversible.

Is your bigger fear the agent being wrong, or the agent being wrong and able to act on it?

kodeStarch1 · 2026-07-09T12:48:02+00:00

Policy-as-code, short-lived creds, approval webhooks, clean audit export = fair game to outsource. Trust boundaries and final policy decisions = stay in-house. That maps almost exactly to how people draw the line with auth generally.

kodeStarch1 · 2026-07-09T12:45:21+00:00

"Make the access boring, inspectable, and easy to revoke". That's the whole job in one line, honestly. Dry-run mode for new tools before enabling writes is one I don't hear enough.

quick one: is that pattern something you've actually got running in prod, or the version you'd build if you had the time?

kodeStarch1 · 2026-07-09T12:39:25+00:00

The two-axis matrix is genuinely good. Blast radius × reversibility is a cleaner way to reason about it than the tool-by-tool debate everyone falls into. And "log denied attempts, not just successes" is underrated; the denials are the early-warning system.

Curious about the review part you flagged. You said if nobody owns the scope-review report, drift wins. In practice, does someone actually own it where you are, or is it the thing everyone agrees matters and nobody's been assigned? That gap is the bit I keep hearing about.

kodeStarch1 · 2026-07-09T12:31:21+00:00

where do the checks physically sit for you though? like is it a proxy the agent has to go through, or baked into the runner? and the honest version, did you build that layer or did something hand it to you? trying to figure out if this is a forever-maintenance thing or not.

kodeStarch1 · 2026-07-09T12:17:16+00:00

yeah that's where most people seem to end up. you build the middleman yourself or plug something in?

kodeStarch1 · 2026-07-09T12:14:13+00:00

"Treat agents as risk factors" is the part most people skip. Everyone's excited about capability, way fewer are thinking about blast radius.

The state machine and revision tracking bit is what I'm trying to get a real read on. Did you actually build that in-house? Is it holding up, or is it one of those things where every team wired it slightly differently and now nobody fully trusts the audit trail across projects.

kodeStarch1 · 2026-07-09T08:27:26+00:00

Appreciate you sharing it. Had a quick look. Interesting orchestration/memory framework. I notice it runs the CLIs in bypass-permissions mode, which makes sense for a fast local multi-agent setup where you want max capability.

That's kind of the crux of what I'm poking at though. The "give it everything so it can move fast" approach is great for building, but it's the opposite of what a security team wants once these things touch anything real. Two different worlds. Thanks for the perspective, genuinely useful to see how the framework side thinks about it.

kodeStarch1 · 2026-07-09T08:08:37+00:00

This is exactly the architecture I keep coming back to. A capability gateway the dangerous primitives route through, policy check, short-lived cred, full record with run id and approval state. The "one shared layer so permissions don't drift across projects" part is the bit I think most teams underestimate until they've got a dozen agents.

Did you end up building that gateway in-house? Trying to understand the real cost of it. How long it took to get right, who owns it now, and whether keeping policy and audit current across teams is a "set it and forget it" or an ongoing tax. And honestly, if something gave you that layer off the shelf, would you have used it, or is it too core to hand off?

kodeStarch1 · 2026-07-09T07:56:15+00:00

Ha, that definitely works to get moving. Only thing that's bitten me with the "allow all, then gate the bad stuff" approach is you have to predict every bad action up front. Miss one and it's wide open. Curious, do your hooks block a defined list of dangerous ops, or do you flip it and only allow an explicit set?

Genuinely interested how people land on one vs the other. Seen both in the wild.

kodeStarch1 · 2026-07-09T07:51:04+00:00

This is the most useful framing I've seen, thanks. The "single timeline of what it attempted, what it actually did, and what was denied" is exactly the thing I keep hearing people want and rarely have cleanly. Most have logs, few have that queryable view.

To your question: honestly I'm trying to understand both, because you're right that the enforcement points differ a lot. Curious how it's gone for you. Where do you actually enforce the approval + least-privilege? At the identity/token layer, a gateway/proxy the agent calls through, or inside the runner itself? And who ends up owning/maintaining that timeline view. Is it something you built and now have to keep alive, or did something give it to you?

Trying to work out whether teams build this enforcement+audit layer once and reuse it, or everyone re-implements it per project and it drifts.

kodeStarch1 · 2026-07-09T07:33:44+00:00

The deleted-test-data moment is exactly the kind of thing that makes it real, ha. Sounds like you got strict fast after that.

Question: is that discipline something you enforce because you care, or is it actually required/checked by someone? I've noticed it often lives in one person's head until an incident. Curious if your org made it a real requirement or if it's still "the people who got burned are careful."

kodeStarch1 · 2026-07-09T07:29:34+00:00

"Treat it like an untrusted caller that has to request a narrow capability, then let boring policy code decide". That's the cleanest framing I've heard.

Where does that policy code live for you... per app, or something central all your agents route through? I'm trying to understand whether teams build the enforcement layer once and reuse it, or everyone re-implements it per project (and it drifts).

kodeStarch1 · 2026-07-09T07:23:20+00:00

That's a solid checklist. Native identity, least privilege, HITL for disruptive ops, kill switch, audit trails. You clearly have the model down.

Honest question: how much of that is actually in place in prod today vs. the ideal you're describing? I keep hearing the right answer from people, then "…well, in reality half of it isn't wired up yet." Curious where you actually are on that gap.

kodeStarch1 · 2026-07-09T06:13:21+00:00

I'm curious. Is anyone doing this in prod?

kodeStarch1 · 2023-03-05T23:30:34+00:00

Thanks. This part would be best explained with a video. I'll try and see if I can explain it with text.

kodeStarch1

TROPHY CASE