An AI ops agent's real permissions design is two Istio policies and one ClusterRole

The copyable part here is two policy objects, not the model. According to the author's write-up, one Istio AuthorizationPolicy grants the agent read-only access to Prometheus, Jaeger and Kiali in istio-system, and a second, separate DENY policy blocks the same identity from reaching any application workload, naming lsd-frontend, lsd-backend and payment APIs ^[4][5]. The identity being checked is not a token someone can lift and replay from a laptop: it is a SPIFFE identity bound to a ServiceAccount in the agent's own namespace, verified on every hop under mTLS in STRICT mode ^[3][4].

That is the whole trick, and it is why the restraint is worth more than a promise. The model's own output includes a scope boundary declaring that it cannot execute kubectl, inspect pods, modify Istio configuration or change production workloads ^[14]. Useful as a message to the on-call engineer reading the card. It is documentation of the boundary, not the boundary. Envoy is the boundary.

Then there is the button. The dashboard offers an auto-remediate action that runs a scoped workflow using a ClusterRole limited to chaos-mesh resources, which in this environment means deleting the Chaos Mesh fault object that caused the incident ^[15]. So the agent does hold write power; it is enumerated by resource kind rather than withheld ^[19]. Teams copying this design are copying a list, and the question that decides whether the pattern holds in a year is who reviews additions to that list at three in the morning.

The validation run is more informative than most demos. A NetworkChaos fault was injected against lsd-backend in the lsd-payments namespace ^[9], and within one 30-second polling cycle the agent reported a 56.5% error rate with no matching frontend degradation ^[10]. The diagnosis isolated the fault domain to lsd-backend and ruled out mesh-wide or namespace-wide networking ^[11], read a NaN p99 latency as a broken metrics pipeline rather than a slow application ^[12], and returned a six-step proposal covering pod health, Envoy sidecar logs, DestinationRule outlier detection tuning and Jaeger trace verification ^[13]. Read-only telemetry access was sufficient to produce all of that, which is the actual finding: the diagnostic value did not require the write scope.

Two gaps follow from the same loop. The agent evaluates error rate and p99 latency every 30 seconds, but the model is only invoked when error rate crosses its threshold ^[6][7], so a service that degrades into slowness without shedding requests does not generate a diagnosis on its own ^[20]. And the telemetry snapshot goes to the Anthropic API ^[7], which puts it outside the mesh whose mTLS the design leans on ^[22]. The deny policy governs what the agent can reach inside the cluster. Nothing described governs what leaves it.

The author frames the goal as shortening the path from detection to diagnosis rather than replacing engineers ^[16], and on the evidence that is the honest claim. A diagnosis is cheap to trust while nobody can act on it unilaterally. The design will be tested the first time somebody wants a verb added to that ClusterRole.