Platform | For AI
Agentic use cases
AI agents are starting to do real work inside enterprise systems. Some assist developers. Some run autonomously. Some call other agents. Some make changes to infrastructure or permissions.
The access problem changes with the job. We have worked through these patterns with customers and design partners as they build and deploy agents in production and pre-production environments. We have anonymized some of the details, but the underlying use cases and access-control questions are real.
These pages are meant to show what that could look like in practice.
What you’ll find in each use case
Each use case starts with the job the agent is actually trying to do, then works backward into the access decisions that job creates. You’ll see:
- How the agent operates - whether it is user-initiated, headless or part of an agent-to-agent workflow
- What the agent is trying to do - the real task, not a generic technical capability
- Where access gets complicated - the point where identity, delegation, context or privilege changes the decision
- Example actions and policies - concrete examples of what should be allowed, denied or require approval
- What the policy needs to evaluate - originator, agent, task, action, resource, context, duration and other inputs
- How access can be enforced - including scoped, short-lived access and human approval where needed
- What happens without those controls - the practical risk created by broad or inherited permissions
- What should be recorded - the identity, policy decision, grant and resulting action across the full chain
These are examples, not fixed policy templates. Every organization will define its own thresholds, approval requirements and access model. The goal is to show the questions security teams need to answer as agents move from answering questions to taking action.
The recurring authorization question
Across all of these use cases, the decision is rarely as simple as: Can this agent access this system?
The more useful question is: Can this originator, using this agent, perform this action on this resource for this task under the current conditions?
For headless agents, there may be no human originator at all. In that case, the decision needs to consider the agent, workload, trigger, task and resource instead.
As agent workflows get more complex, those decisions also have to survive handoffs from one agent to another.
Autonomous cloud optimization agents
Example: VM Size Optimizer
A headless agent runs on a schedule, reads cloud utilization data and recommends ways to reduce infrastructure spend.
The important policy split is between observation and action. The agent may have standing permission to read broadly, while production changes require human approval and short-lived access to one specific VM.
You’ll see:
- Read vs. write policy examples
- Human-gated production changes
- Instance-scoped temporary access
- Safety thresholds and environment rules
- What happens when an autonomous agent has too much standing privilege
IAM service account expert
A user asks an agent to inspect service account permissions, troubleshoot access or make an IAM change.
The authorization decision depends on who is asking. A developer may be allowed to inspect permissions, while only an on-call engineer or other authorized user can make a change.
You’ll see:
- User + agent blended identity
- Different policies for read and write actions
- On-call, incident and ticket context
- Scoped IAM changes
- How an agent can accidentally become a privilege bypass if user context is lost
Agent-to-agent reporting workflows
A Reporting Agent calls a downstream data agent to retrieve information, then another agent or workflow uses the result to produce a report.
The challenge is preserving authorization through the entire chain. The downstream agent’s broad permissions should not automatically become available to the upstream agent or original requester.
You’ll see:
- Agent-to-agent delegation policy
- Original requester context carried across each hop
- Scoped access to datasets and output locations
- Controls on what data can be returned or written
- How to audit the full chain from requester to agent to data to output
Coding and SRE agents
Developers use coding agents such as Claude Code, Cursor and Codex to investigate and change systems. Separately, incident-response agents may launch automatically from PagerDuty or another trigger with nobody at a keyboard.
These two patterns require different identity models but the same core principle: the task should determine the access.
You’ll see:
- User-initiated vs. headless agent identity
- Developer + agent authorization
- Incident- and ticket-scoped access
- Short-lived production privileges
- Policies for reads, deployments, remediation and destructive actions
Common questions about agent access
Why do these use cases matter?
Agent security gets abstract fast. Identity, authorization, delegation, JIT access and human approval all matter, but they are much easier to understand when you apply them to a real task. A VM optimization agent may be allowed to read broadly but need approval before it resizes infrastructure. An IAM agent may be able to answer a developer’s question but not make the requested permission change. A coding agent should not automatically inherit every privilege its engineer has. These examples show where the access decision actually changes as agents move from observing to acting.
What should an agent authorization policy evaluate?
The exact policy will vary by use case, but the same inputs come up repeatedly: who or what originated the request, which agent is performing the action, whether that agent is allowed to act for the originator, what task or business purpose is behind the request, what action is being attempted, which resource is involved, the current context, how privileged the action is, whether approval is required and how long access should exist.
What changes when there is no human originator?
Headless agents need a different model. If an agent runs on a schedule or is triggered by an incident, there may be no person actively initiating the task. In that case, policy needs to evaluate the agent, the workload that launched it, the trigger, the approved job, the target resource and the action being requested rather than pretending a human is behind it.
What changes when one agent calls another?
Authorization has to survive the handoff. A downstream agent may have broader access than the original requester or upstream agent, but those permissions should not automatically become available to the entire workflow. The decision needs to preserve the original requester, the upstream agent, the downstream agent, the task and the requested resource as the action moves through the chain.
Why isn’t authenticating the agent enough?
Authentication tells you which agent is making the request. It does not tell you whether that agent should perform this particular action, on this resource, for this task, under the current conditions. That is the authorization decision these use cases are designed to make concrete.
What should be recorded after an agent acts?
The audit trail should preserve the full action chain: who or what initiated the request, which agent acted, which downstream agents or tools were involved, what resource was accessed, what policy was evaluated, whether approval was required, what temporary access was granted and what action ultimately occurred.
Are these hypothetical examples?
No. These patterns come from customer and design-partner engagements we have worked through. We anonymize some details and the exact tools and policies vary by environment, but the underlying access questions are based on real agent deployments and real security decisions teams are working through now.