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.
Group tools by what they do
The post sorts operations into four tiers:
- T0, inspect and read: list, get, log and metric queries, config fetches. Allowed in prod for approved agent identities, with full logging.
- T1, diagnose and test: profiling, dry runs, diff checks, policy simulation. Allowed with limits on rate, scope and data.
- T2, ticket or draft change: open an incident, draft a PR or a remediation plan. Allowed, with attribution and a reviewer assigned.
- T3, restart, modify, deploy, delete, change permissions: needs step-up, explicit approval, or a deny, depending on environment and policy.
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.
The check on each call
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.
The audit trail
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?
Top comments (2)
Where would you put a tool that only clicks and types in a GUI? A click has no verb, so the same call is a read or a delete depending on what is under the cursor, and T0-T3 can't be decided from the parameters alone.
We hit this building Auten (computer-use MCP, I'm on the team): our Claude Code plugin ships a skill telling the agent to stop and ask before anything that buys, deletes, sends or changes a permission, judged from the screen. That's an instruction to the model, not a policy engine, so I'm curious how your tiers would handle it.
Read access is cheap to widen, write access is not. Keep the approval on the write path and let reads run, and the review stays small.