For AI | Agentic use cases
Autonomous cloud optimization agents
Autonomous agents need broad visibility without broad control
Autonomous agents can run on a schedule or trigger with no person actively directing each step. They may need broad visibility across cloud environments to inspect utilization, identify problems and recommend changes, but that does not mean they should have broad permission to modify what they find.
The critical control point is the move from observation to action. If the same cloud role covers both, a bad recommendation or incomplete understanding of the environment can turn directly into a production change, even when the agent is doing exactly what it was designed to do.
Let the agent observe broadly without letting every observation become an autonomous write.
Example: VM Size Optimizer
Consider a headless optimization agent that runs nightly across approved cloud projects. It reads utilization data, identifies oversized or unused VMs and recommends changes that could reduce infrastructure costs.
Because no individual user initiates each task, the authorization decision centers on the agent or workload identity, the job it has been approved to perform and the exact resource and action it is requesting.
Example actions and policies
| Action | Example policy |
|---|---|
| Read CPU, memory and utilization data | Allow the agent to read monitoring and compute data across approved cloud projects |
| Identify an oversized VM | Allow the agent to analyze usage and recommend an appropriate target size |
| Resize a development VM | Allow automatically if the VM is within the agent’s approved scope and the requested size stays within defined safety limits |
| Resize a production VM | Require human approval, then grant write access only to the specific VM and approved resize operation |
| Resize the VM differently than approved | Deny. The requested target size must match the approved recommendation |
| Downsize below a defined capacity threshold | Deny even if the agent recommends it |
| Stop or delete a VM | Deny unless the agent has a separate policy explicitly allowing that destructive action |
| Perform another change after the approved resize | Deny once the temporary access has been used or expired |
These are examples of policies organizations can apply. The exact thresholds, approval requirements and permitted actions will depend on the environment.
Example policy
Agent: VM Size Optimizer
Request: Resize vm-prod-42 from n2-standard-16 to n2-standard-8
Environment: Production
Recommendation: The requested target size matches the agent’s approved recommendation
Allow only when:
- The agent is the approved optimization agent
- The VM is in an approved project
- The requested size matches the recommendation reviewed by the SRE
- The change does not cross minimum CPU, memory or availability thresholds
- Human approval is attached to the request
If approved, grant write access only to vm-prod-42 for that resize, then expire it.
What the policy evaluates
For a headless agent, there may be no human associated with the individual task. Policy therefore evaluates the agent, the workload running it, the approved purpose and the context of the requested action.
A policy may consider:
- Agent identity: Is this the approved optimization agent?
- Workload: Is it running from the expected cloud account, Kubernetes workload or execution environment?
- Purpose: Is the request part of its approved optimization job?
- Action: Is it reading utilization data, resizing an instance, stopping it or deleting it?
- Resource: Which specific VM is involved?
- Environment: Is the resource in development, test or production?
- Safety conditions: Would the requested change violate minimum CPU, memory or availability requirements?
- Approval: Does this type of action require an SRE or resource owner to approve it?
- Duration: How long should the write permission exist?
How enforcement with P0 works
The nightly optimization agent starts on its own schedule using an approved agent or workload identity. It can read monitoring and compute data across approved projects, including CPU, memory and utilization metrics, then use that information to identify oversized or unused VMs and recommend a target size.
That read phase can stay autonomous because the agent is observing the environment, not changing it. The authorization model changes when the agent wants to act on a recommendation. A request to resize a specific production VM is evaluated as a production write, so policy can require an SRE to review the recommendation and approve the exact change before write access is granted.
Once approved, P0 grants temporary write access only to the specific VM and only for the approved resize operation. The agent can then make the change without receiving broader production privilege or reusable access to other resources.
As soon as the action completes, or the short approval window expires, the temporary privilege is revoked. The full chain is recorded from the original agent request through policy evaluation, approval, scoped access and the completed action.