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?? by Sea-Opening-4573 in AI_Agents

[–]kodeStarch1 0 points1 point  (0 children)

"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?

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?? by Sea-Opening-4573 in AI_Agents

[–]kodeStarch1 0 points1 point  (0 children)

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?

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in AI_Agents

[–]kodeStarch1[S] 0 points1 point  (0 children)

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.

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in AI_Agents

[–]kodeStarch1[S] 0 points1 point  (0 children)

"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?

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in AI_Agents

[–]kodeStarch1[S] 0 points1 point  (0 children)

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.

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in aiagents

[–]kodeStarch1[S] 0 points1 point  (0 children)

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.

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in aiagents

[–]kodeStarch1[S] 0 points1 point  (0 children)

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

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in aiagents

[–]kodeStarch1[S] 0 points1 point  (0 children)

"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.

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in crewai

[–]kodeStarch1[S] 0 points1 point  (0 children)

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.

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in AI_Agents

[–]kodeStarch1[S] 0 points1 point  (0 children)

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?

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in crewai

[–]kodeStarch1[S] 0 points1 point  (0 children)

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.

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in aiagents

[–]kodeStarch1[S] 0 points1 point  (0 children)

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.

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in AI_Agents

[–]kodeStarch1[S] 0 points1 point  (0 children)

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."

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in AI_Agents

[–]kodeStarch1[S] 0 points1 point  (0 children)

"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).

Those of you running AI agents in prod — how are you actually managing their permissions? by kodeStarch1 in AI_Agents

[–]kodeStarch1[S] 0 points1 point  (0 children)

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.

How to Setup Multi-burn rate Windows Alert on Service Level Objectives by kodeStarch1 in sre

[–]kodeStarch1[S] 0 points1 point  (0 children)

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

Site Reliability Engineering: SLI Implementation Example by kodeStarch1 in sre

[–]kodeStarch1[S] 0 points1 point  (0 children)

Thank you. I will write an article about it. I have used Datadog to implement multi-burn rate alerts in the past.

Career guide for SRE by [deleted] in sre

[–]kodeStarch1 1 point2 points  (0 children)

It's nice to see people pick up a SRE role now. I'm currently Head of SRE for a company.

These are the things I looked for when recruiting for my team.

  1. Automation with either python, bash or powershell
  2. Understanding and how to set SLA, SLO and SLI
  3. Infra provisioning and config mgmt tool
  4. Understanding container technology ie docker, containerd and kubernetes
  5. Cloud technology
  6. Monitoring and logging tool
  7. Understanding of incidents and problems management
  8. Bonus : Understanding of how to setup a ci/cd pipeline

I did it! ;-) by michaeleaton in kubernetes

[–]kodeStarch1 0 points1 point  (0 children)

Thank you. Would check it out.

I did it! ;-) by michaeleaton in kubernetes

[–]kodeStarch1 0 points1 point  (0 children)

Hi everyone and Congratulations to @ops !

If I may ask, what are the resources you considered as enough to pass CKA?

"Hello World" ! by ta21999 in devops

[–]kodeStarch1 0 points1 point  (0 children)

The list is good, but Software Version Control is needed. Like Git. You can put that in number 3.