.avif)
%201.svg)
HIPAA Compliance Checklist for 2025
Your SOX controls assume segregation of duties means different people in different roles.
- The person who requests a purchase order isn't the person who approves it.
- The engineer who writes the code isn't the one who deploys it.
That assumption holds because humans work inside org charts, and org charts separate people.
An AI agent isn't inside an org chart. One agent connected to your approval workflow, your provisioning system, and your payment processor can receive a request, approve it, and execute it in seconds, with no one else involved.
This piece covers exactly where that collapse happens, why it's harder to catch than a human breaking the same rule, and what segregation of duties looks like once AI agents are in the workflow.
TL;DR
- Segregation of duties assumes three separate roles: initiation, authorization, and execution. A single AI agent can hold all three at once.
- This is already happening in access provisioning, procurement, license reclaim, and data routing workflows, not as an edge case but as the default setup.
- Static policy rules don't restore segregation of duties. A rule written months ago can't authorize a transaction it never anticipated.
- Agent-driven SoD collapse is harder to detect than a human violation because it leaves one entity ID in the log instead of two.
- Fixing it means putting a human back in the authorization step, scoping what agents can do alone, and keeping an audit trail that separates who initiated an action from who authorized it.
1. What Segregation of Duties Actually Controls, and the Assumption AI Agents Break
Segregation of duties is a preventive control. It distributes a sensitive transaction across separate parties so no single actor can complete the whole thing alone.
The Three Roles Segregation of Duties Keeps Apart
- Initiation: identifying that something should happen and generating the request
- Authorization: independently evaluating whether it should happen and approving it
- Execution: carrying out the approved action
Any entity holding all three roles on the same transaction is a segregation of duties violation. That's true in accounting, in IT access management, in procurement, and now in AI-driven automation.
The Assumption That Breaks
Segregation of duties was designed around a specific kind of actor, and AI agents don't match it:
The result is that segregation of duties, a control built on human role boundaries, has nothing to enforce a boundary against when the actor is a single automated process.
2. Why This Is Already a Problem in Your Environment
This is already showing up in workflows most teams assume are under control, and it's the clearest form AI agent segregation of duties collapse takes today.
Four Places One Agent Ends Up Approving Its Own Requests
a) Access provisioning agents
Agent receives an access request, checks it against a permission policy, and provisions the access itself.
- What's missing: no second party reviews whether the request is contextually appropriate, only whether it technically matches the policy
- The gap in practice: a recently transferred employee requesting their old department's data can pass the policy check and still be the wrong outcome
b) Procurement and spend agents
Agent receives a purchase request under a delegated threshold, checks the budget, approves it, submits the PO, all as one actor.
- What's missing: the financial control requiring a requester and an approver to be different people never engages
- The gap in practice: requests can be structured just under the threshold and approved individually, a pattern a human reviewer would catch, and a rule-checking agent won't
c) License reclaim agents
Automation detects 30 days of inactivity, sends a notice, and treats non-response as implicit approval to remove the license
- What's missing: the "authorization" step is the absence of a human, not a decision by one
- The gap in practice: a user on leave or filtering their inbox loses access, with no one actually approving that outcome
d) Data routing and workflow agents
Agent pulls internal data from a source system and routes it outward, to another application, an external system, or a distribution list, based on a rule a business user configured
- What's missing: each routing decision is functionally an authorization decision, made hundreds of times a day, with zero human review
- The gap in practice: sensitive data can move to the wrong destination, and the routing rule never flags it, because the rule was never built to catch that.
"We Have Rules for This" Doesn't Solve It
The agent is only executing rules a human has already configured, so authorization is already baked into the policy. That defense doesn't hold up.
The rule vs. the transaction: segregation of duties never required a human to write the rule. It requires a human to authorize the transaction. Those are two different things.
- Why the gap survives policy: a policy configured months ago can't anticipate every context a specific request shows up in. Per-transaction human authorization exists to catch exactly the cases where a rule applies technically, but the outcome is wrong contextually.
- Where this shows up beyond access: static rules built for "this role gets this access" stop being reliable once the requester isn't a predictable human role. Spend fails the same way: a rule letting an agent draw against a budget can burn through it as fast as a misconfigured query drains a token allocation, because nothing is checking the transaction, only the rule
The bottom line: an agent running 500 license decisions a day against a configured policy is providing scale without any of the oversight that segregation of duties is supposed to guarantee
Why Nobody Notices Until the Audit
Human segregation of duties violations get caught because they leave a pattern: two different user IDs on one transaction, which most GRC tools are built to flag. AI agent SoD collapse looks nothing like that.
Most AI agents also get built bottom-up, outside formal procurement or security review.
A Gartner survey of 302 cybersecurity leaders found that 69% of organizations suspect or have evidence that employees are using prohibited public GenAI, largely without IT ever reviewing it first.
That means the agents most likely to collapse segregation of duties are frequently the ones IT and compliance don't know exist. A human SoD violation leaves two names in the log. An AI agent SoD collapse leaves one.
3. Three Ways to Put a Human Back in the Approval Step
The principle behind segregation of duties changes how the separation gets implemented.
a) Human-in-the-loop authorization
How it works: the agent handles initiation and, once approved, execution. A human handles authorization in between
For example, the agent detects an inactive account and prepares the deprovisioning action, but a person confirms it before it runs
b) Scoped autonomy
How it works: define narrow conditions under which an agent can act without a human step, limited to low-risk, low-impact, easily reversible actions. Everything outside that scope requires authorization
For example, an agent removing a license for an inactive user with no active projects and under $50 a month in spend can run autonomously. An agent with access to a sensitive role cannot
c) A separate audit trail
How it works: even where autonomous execution is permitted, the log records who or what initiated the action, whether a human authorized it or the agent acted unilaterally, and the basis for that decision
For example, when an auditor asks about a specific transaction, the answer includes an explicit authorization event, not just an execution event
4. How CloudEagle.ai Gives Compliance Teams Visibility Into Agent Connections
CloudEagle.ai doesn't enforce segregation of duties at the agent level. What it does is give security and compliance teams the visibility to find where the risk sits before an audit finds it for them.
a) Agent inventory that actually exists:
Most agents get built without a central record, so nobody knows what's running until an incident or an audit forces the question.
How CloudEagle.ai solves it:
- Discovers every AI agent and non-human identity connected to your environment
- Surfaces each one with its connected systems and permission scope
- Keeps the inventory live instead of a point-in-time snapshot
The starting point for any segregation of duties assessment needs is already there, not reconstructed under the deadline.
b) Connection mapping before the transaction runs:
An agent can sit on both sides of a sensitive workflow, initiating a request and also controlling its approval, with nobody noticing until it's too late.
How CloudEagle.ai solves it:
- Maps every system each agent is connected to
- Flags agents touching both sides of a SoD-sensitive boundary, like a request system and its approval step
- Surfaces these connections before a transaction runs, not after
Those agents get identified for review before they process a transaction, not after it's already happened.
c) Ownership that survives employee turnover:
An agent's creator can leave the company, and the agent keeps running with no one accountable for what it can access.
How CloudEagle.ai solves it:
- Assigns a human owner to every discovered agent
- Flags any agent left without an owner on record
- Keeps that owner accountable for certification and decommissioning decisions going forward
There's always someone accountable for certifying whether the agent's connections are still appropriate.
d) A review cadence that doesn't depend on memory:
Without a forcing function, agent access reviews happen inconsistently or not at all.
How CloudEagle.ai solves it:
- Certifies agent connections on the same recurring cadence as human access reviews
- Runs that cadence automatically instead of relying on someone to remember
- Surfaces ownerless or over-scoped agents as part of the same cycle
Ownerless or over-scoped agents surface automatically, on schedule, instead of during an incident.
This is the human accountability layer that segregation of duties assumes exists.
CloudEagle.ai doesn't decide whether an agent's permissions are appropriate, but it gives teams the inventory their SoD controls depend on and makes sure someone is assigned to make that call and has to answer for it on a recurring schedule.
Your Audit Log Shows One Entity. Your SoD Control Assumes Two
5. What SOX, SOC 2, and ISO 27001 Actually Require
None of the three major frameworks has AI agent-specific guidance yet, but auditors are already applying existing segregation of duties requirements to agent workflows, and most organizations don't have a ready answer.
None of these standards were written with AI agent segregation of duties in mind, which is exactly why auditors are stretching existing SoD controls to cover a gap the frameworks haven't caught up to yet.
6. FAQs
1. What happens when AI agents interact with each other?
One agent's output becomes another's input with no human review between them, which can chain a segregation of duties gap across multiple systems at once.
2. When segregation of duties can't be fully achieved in an online system, which functions should be separated first?
Separate authorization from execution first. That's the step most likely to be automated away entirely.
3. Which duty role lets a user interact with an AI agent in the application?
This depends on your access model, but the role should never combine the ability to configure an agent with the ability to approve its actions.
4. Can agentic AI plan and execute tasks autonomously?
Yes. That's exactly why segregation of duties needs a defined authorization step, not an assumption that planning and execution stay separate on their own.
See how CloudEagle.ai surfaces AI agent connections and ownership so your compliance team can assess segregation of duties risk before an auditor does: book a demo.
SoD Was Built for Humans. Your Agents Don't Follow the Rules.
.avif)
.avif)
.avif)
.png)
