What an AI Agent Should—and Should Not—Be Allowed to Do in Production

Giving an AI agent access to production is not a question of whether the model is smart enough. It is a question of what happens when it is wrong, and who is responsible when it is.

Agents can read logs, query metrics, draft runbook steps, and propose fixes quickly. Those are real benefits. But an agent that can act also has a blast radius, and that should be designed as carefully as any other privileged system.

Treat the agent as a new kind of service account

Strip away the novelty and an agent is software holding credentials. Everything you already know about service accounts applies:

• It should have its own identity, not a shared human login.
• Its permissions should be scoped to specific tasks.
• Its actions should be logged and attributable.
• Its credentials should be short-lived and revocable.

The difference is that its behavior is less predictable than a script's. That argues for tighter boundaries, not looser ones.

Proposed versus executed

The most useful distinction is between an agent that proposes a change and one that executes it.

A proposed change is a pull request, a change ticket, a drafted command, or a plan. A human or a deterministic pipeline reviews and runs it. Executed changes happen directly.

Most production work should sit on the proposal side. It gives you review, testing, and a clean audit trail, and it costs relatively little speed for anything that isn't an active incident.

What agents can reasonably do

Read-heavy and reversible work is a good fit:

• Investigate. Query logs, metrics, and traces with read-only access to build a timeline.
• Summarize. Turn an alert storm into a short explanation of what changed and when.
• Draft. Write incident updates, change requests, and post-incident notes for human review.
• Propose remediation. Open a pull request or suggest a runbook step with supporting evidence.
• Run pre-approved, low-risk actions. Restart a stateless pod, clear a specific cache, or scale within defined limits, where the action is narrowly scoped and easy to undo.

That last category deserves care. "Pre-approved" should mean a specific action on specific resources with defined limits, not a broad permission like "manage Kubernetes."

What agents should not do

Some actions should stay out of autonomous reach:

• Delete data, databases, volumes, or backups
• Modify IAM policies, roles, or credentials
• Change network security rules or firewall policy
• Disable logging, monitoring, or security controls
• Approve their own changes or bypass required reviews
• Deploy to production outside the normal pipeline
• Execute arbitrary shell commands with broad privileges

These are the actions where a mistake is expensive, hard to reverse, or would hide what happened.

Policy belongs outside the model

Instructions in a system prompt are not access control. A model can be confused, misled, or manipulated by the content it reads. Logs, tickets, and web pages can all contain text designed to steer it.

Enforce boundaries where the model can't talk its way past them:

• IAM permissions on the agent's identity
• Allowlists of permitted tools and actions
• Policy-as-code checks on proposed changes
• Approval requirements enforced by the platform, not by the agent
• Rate limits on how many actions it can take in a window

If the only thing stopping an action is that the prompt says "don't," the action isn't really prevented.

Accountability doesn't transfer

When an agent-proposed change causes an outage, someone needs to own it. That should be the person who approved it, or the team that defined the policy allowing it to run automatically.

That isn't about blame. It is about making sure a human understands and accepts each class of risk. "The AI did it" is not an acceptable root cause, and organizations that allow it to become one will find their controls eroding quietly.

A sensible progression

1. Read-only. The agent investigates and reports. Measure how often its analysis is correct.
2. Propose. It drafts changes through PRs and tickets. Track acceptance rates and review findings.
3. Narrow execution. Allow a small set of reversible actions with tight limits and alerts on each use.
4. Review regularly. Expand or contract permissions based on evidence, not enthusiasm.

The bottom line

An AI agent can make production operations faster and less exhausting. It should do that the way any well-governed automation does: least privilege, enforced policy, reversible actions, full logging, and a named human who answers for the outcome.