Agents in operations: permissions by task.

An agent does not need to manage an entire infrastructure to be useful. A narrow task can already help: organise errors, compare an alert with the latest deployment or prepare a configuration change.

Start with the task. What information does it need, which actions are necessary and what result should be available afterwards?

One possible operating model

Suppose a service reports an increased error rate. The work could be split into three distinct roles:

Role	Allowed access	Result
Diagnosis	Read selected logs, metrics and deployment metadata	An evidence-based hypothesis
Proposed change	Write to a working branch and run tests	A reviewable pull request
Execution	Trigger an approved action for a specific service	A recorded operation followed by verification

This is an architectural example. It does not require three different models; separate identities and enforced permissions are what matter. General shell access would unnecessarily expand a narrowly defined task.

Granular means more than read or write

Kubernetes permissions can be scoped by resource, action and namespace. Its RBAC guidance recommends minimal permissions and avoiding broad wildcards. It also documents indirect privilege escalation: permission to create workloads can provide access to other resources.

For this example, the diagnostic agent needs neither every secret nor access to every service. Logs can contain sensitive information too. Selecting the available data is therefore part of defining the task.

From proposal to change

Approval should refer to a specific action. What will change, and where? How will the result be checked? What recovery is possible?

These transitions can be designed deliberately. AI gains a clear place in operations, while the team retains the decision about which tasks it delegates.