Observe, Operate, Administer: how to run autonomous agents in production

Why Enterprise Will Not Run Autonomous Agents Without Control

Ask any Head of Cloud at a mid-to-large enterprise the same question: “Would you let an AI agent modify your production IAM policy without asking?” The answer is always no. And rightly so.

The temptation in agentic DevOps is to either ask permission for everything (useless; nobody clicks approve ten thousand times a week) or ask permission for nothing (liability; irrecoverable mistakes arrive at three in the morning). Both of those models fail at enterprise scale. The working pattern in 2026 is capability tiers: every agent action belongs to one of three tiers, and each tier has a different approval posture.

The Three Tiers

Observe. Read-only work. Cost audits, security scans, drift detection, inventory, correlation across signals. No write access, no side effects, and a full audit trail. Runs autonomously because there is nothing to gate — agents cannot break what they cannot touch. Observe tier is where most enterprises start, and it is where the product earns trust.

Operate. Bounded action. Reversible, in-policy changes that the team has pre-approved as a class: stopping idle EC2 instances, deleting unattached EBS volumes, applying S3 lifecycle policies, generating remediation pull requests, orchestrating deployments with a defined rollback path. Auto-executed for reversible in-policy work. Approval-gated for anything irreversible or out-of-policy. The approval posture is tuned to action reversibility, not to seniority — a senior engineer approving an irreversible change is the right path; a junior engineer approving a reversible change is overhead.

Administer. Organization-level work. Org changes, billing, IAM roles, custom integrations, and the approval policy itself. Always requires explicit human approval with separation-of-duties enforced — the agent cannot request and approve in the same request, and the approver cannot be the requester. This is the tier where enterprises keep the controls of the controls.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

Mapping to SOC 2 and HIPAA

The tier model is not a marketing abstraction. It maps directly to the control objectives auditors look for:

• CC6 (Logical Access). Tiered access with explicit authorization for privileged operations. Administer tier plus separation-of-duties satisfies this out of the box.
• CC7 (System Operations). Change management, incident detection, approval workflows. Observe surfaces events; Operate runs approved changes; the audit trail records everything.
• CC8 (Change Management). Every material agent action is appended to an immutable log with requester, approver (where applicable), scope, blast radius, and outcome. Evidence collection stops being a quarterly sprint.
• HIPAA §164.312(b) (Audit Controls). The immutable log is the audit control. Agents cannot modify their own trail.
• HIPAA §164.308(a)(3) (Workforce Authorization). Tiered capabilities per agent, per cloud account, per team — mirrored to the customer’s RBAC.

What Gets Assigned to Which Tier

The tier model only works if the assignment is conservative by default and loosened on evidence. A rough starting cut:

• S3 lifecycle policy changes → Operate (reversible within retention window).
• Stopping idle EC2 instances → Operate (reversible: you can start them again).
• Deleting unattached EBS volumes older than 30 days → Operate if a snapshot exists; Administer if not.
• Closing a security group open to 0.0.0.0/0 → Administer if production; Operate if staging with explicit team policy.
• Adding an IAM role or policy → Administer. Always.
• Modifying approval policy itself → Administer, with the approver explicitly not the original policy author.
• Deploying a service with a rollback path → Operate.
• Deploying a database schema change → Administer (irreversible without point-in-time recovery drama).

The principle: reversibility and blast radius determine tier, not agent identity. The same agent can do Operate-tier and Administer-tier work — the permission gate is the action, not the actor.

Immutable Audit Trail

Every action in every tier is appended to an append-only log with a cryptographic chain (hash of previous entry in each new entry; tamper-evident). The log includes: actor (which agent), requester (human user if any), approver (for Operate-gated and Administer), action class, scope, parameters, blast radius estimate, outcome (success, failure, rolled back), and timing.

This is not optional. Even Observe-tier reads are logged. The audit log is the primary artifact auditors examine — the controls around agent authorization are only meaningful if the evidence that they worked is tamper-evident.

What to Refuse to Automate

Not every action belongs in the agent team. The explicit non-goals:

• Legal and HR decisions.
• Customer-facing communications during an incident (agents can draft; humans send).
• Board-level reporting.
• Anything where the correct answer requires context the agent does not have — and cannot get — from the system state.

Knowing what not to automate is part of running agents responsibly at enterprise scale. The capability tier model makes this explicit: if a work item cannot be cleanly assigned to a tier, it does not get automated at all.

The Result

Enterprises that would have blocked autonomous agents on general principle will run them inside this model because the governance is legible: every action belongs to a tier, every tier has a predictable approval posture, every action is logged, and the policy itself is under explicit change control. Agents that cannot be governed do not ship in enterprise. Agents that can, do.