cd /news/ai-agents/give-your-ai-ops-agent-read-access-t… · home › topics › ai-agents › article
[ARTICLE · art-160797] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=· neutral

Give your AI ops agent read access to prod, and make every write ask first

A Permit engineer outlined a tiered authorization model for AI operations agents that separates read access to production from write actions, requiring step-up approval before an agent can restart services or edit RBAC. The model evaluates each tool call against the agent's identity, the delegating user, stated intent and target environment to return allow, step-up or deny, and caps delegated authority so a low-trust assistant acting for an SRE stays at the lowest tier. The post also specifies audit evidence — tool call parameters, hypothesis confidence changes, policy decisions and approver identities — needed to reconstruct an agent's actions after an incident.

read2 min views1 publishedOct 30, 2026

I work at Permit, and this comes from a post on our blog about governing AI ops agents, so keep the bias in mind. Nothing below depends on our product.

Incident agents are getting good at pulling logs, metrics and Kubernetes events together and suggesting a root cause. The post deals with what happens when the same agent can also restart a service or edit RBAC. Investigating production and changing it are separate permissions, and they should be granted separately.

The post sorts operations into four tiers:

Tiers attach to individual operations. One Microsoft Graph or Azure MCP server can expose a harmless read and a role assignment side by side, so trusting a whole server at one level doesn't work.

Every tool call gets evaluated on four inputs: the agent's identity, the person who delegated the task, the stated intent, and the target environment. The answer is allow, step-up, or deny.

Two rules from the post I'd copy. Delegation shouldn't raise the ceiling, so a low-trust assistant working for an SRE stays at T1 in production even though the SRE could do T3 work directly. And an approval button in chat is just UI. The step-up is the policy confirming the approver has the right role, authenticated recently (the example uses 15 minutes), and has a change ticket.

A chat transcript won't be enough after an incident. The post lists the evidence the agent used (sources, query windows), every tool call with its parameters, the hypothesis tree with confidence changes, each policy decision with its reason, who approved what under which incident or change ID, and the outcome with rollback notes. Without parameters you can't tell "listed pods in namespace X" from "deleted a deployment in namespace X".

Full post, with a sample policy and per-tool examples for Azure, Entra ID, GitHub, CI/CD and Kubernetes: https://www.permit.io/blog/read-only-trust-level-ai-ops-agents?utm_source=devto&utm_medium=social&utm_campaign=read-only-trust-level-ai-ops-agents&utm_content=authbyexample-article

If you run an ops agent against production, where did you draw the line between what it does alone and what needs a person?

── more in #ai-agents 4 stories · sorted by recency
── more on @permit 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/give-your-ai-ops-age…] indexed:0 read:2min 2026-10-30 · —