Ask an SAP security colleague how a user gets access and you will get a version of the same answer everywhere: someone has a job, the job maps to a role, the role contains the authorization objects that job needs, and the role gets assigned. Decades of practice, an entire product line in GRC Access Control, and every SoD ruleset ever written rest on that chain.
Now ask how a Joule agent got its access.
The answer is usually different in a way that takes a moment to register. The agent did not have a job. It had a set of tasks it needed to perform, and someone provisioned the authorizations required to perform them. That sounds like the same thing. It is not, and the difference is where the governance gap lives.
Humans are provisioned by job role. Agents are provisioned by capability. Your entire SoD model assumes the first.
This piece covers why SAP’s authorization model does not fit agent identities, the four specific places the gap opens in practice, why the SoD ruleset is a model of human behavior that does not transfer cleanly, and what to test given that GRC will not flag most of it.
How the Model Actually Works
A short recap, because the mechanics matter for the argument.
SAP checks access through authorization objects, F_BKPF_BUK for company code in financial postings, M_BEST_BSA for purchase order document types, and several thousand others. Each object contains fields, most commonly ACTVT for the activity being attempted (01 create, 02 change, 03 display) alongside organizational fields such as company code or plant.
Roles are built in PFCG, drawing proposal values from SU24, and generate the profiles a user actually carries. A user attempts a transaction, the kernel checks whether their profile satisfies the relevant objects, and SU53 or an authorization trace tells you which check failed when it does.
Segregation of duties sits above this. GRC Access Control’s Access Risk Analysis compares a user’s combined authorizations against a ruleset defining which function pairings constitute a risk, create a vendor and post a payment to that vendor being the canonical example. Where a conflict cannot be eliminated, a mitigating control is applied: a named person periodically reviews activity, and the review is evidenced.
Every part of that assumes a person.
Why Agents Don’t Fit
The provisioning difference is not administrative detail. It changes the shape of what gets granted.
When you provision a human, you start from a job description. An accounts payable clerk needs to enter invoices, park documents, and view vendor master data. They do not need to create vendors, because that sits with vendor master maintenance, and separating those two is the point. The job boundary does the security work before anyone opens PFCG.
When you provision an agent, there is no job description. There is a task list: read incoming invoices, match them to purchase orders, code them, and post. So you grant what those tasks require. If the matching step occasionally needs to look at vendor master data, that gets added. If exception handling means the agent sometimes updates a payment term, that gets added too.
Nothing in that process is negligent. Each grant is defensible on its own. But the cumulative result is an authorization set assembled around what the agent *does* rather than around what any single person is *permitted to be*, and those produce different shapes.
Each individual grant is defensible. The combination is one no human in your organisation would be allowed to hold.
This is why the gap is easy to miss in review. Nobody made a bad decision. The control that would normally have prevented the combination, the job boundary, was never in the room.
Four Places the Gap Opens
1. User type puts agents outside the analysis population
Agents operate through system, service or communication user types rather than dialog users. Many GRC Access Risk Analysis configurations scope their runs to dialog users, sometimes deliberately, to suppress noise from technical accounts, and sometimes because that is how the ruleset was configured years ago and nobody revisited it.
The consequence is straightforward: an agent can hold a textbook SoD conflict and simply not appear in the report. It is not that ARA cleared it. ARA never looked.
2. Recertification treats technical accounts differently
Periodic user access reviews are where over-provisioning normally gets caught. In practice, technical and service accounts are frequently excluded from those campaigns, or included and rubber-stamped, because the reviewer has no basis for judging whether a service account needs a given authorization.
A human who accumulates access through role changes gets pruned eventually. An agent accumulates access with each new task it is asked to handle, and nothing prunes it.
3. Mitigating controls assume a reviewer who exists
Where SoD cannot be eliminated, GRC practice applies a mitigating control, typically periodic review of the conflicting activity by a named individual, with evidence retained. It works because someone is accountable and the volume is reviewable.
For an agent processing thousands of transactions, periodic sampled review is not a proportionate control. Sampling fifty of forty thousand agent-posted documents provides very limited assurance, and the reviewer usually has no way to distinguish a correct agent decision from an incorrect one by inspection.
4. The agent’s authorizations may exceed any human role
This is the cumulative effect of the provisioning model. Because the agent was granted by capability, its profile can span functions that in the human org chart belong to two or three different roles, in AP, in vendor master maintenance, in purchasing. No individual would be assigned that combination. The agent holds it because nobody was assembling a job.
The SAP SoD testing Ruleset Is a Model of Human Behavior
There is a deeper issue underneath the mechanics, and it is worth stating because it affects how you should think about remediation rather than just detection.
Segregation of duties exists because of a specific theory of fraud: give one person the ability to both create an obligation and settle it, and you have created motive, opportunity and the means of concealment in a single pair of hands. The control interrupts that chain. It is a control on *human intent*.
An agent has no intent. It will not create a fictitious vendor to enrich itself. In that narrow sense, the classic fraud rationale does not apply.
But the control was never only about intent. It was about *concentration of capability*, and concentration is exactly what agent provisioning produces. An agent that can create a vendor and pay it has the same capability a fraudulent clerk would have, available to anyone who can influence the agent’s inputs, or activated by nothing more than the agent drifting into a wrong pattern and applying it consistently at machine speed.
The agent has no motive. It has the capability, at volume, without the hesitation a person might have. That is not obviously the safer arrangement.
So the control still matters, but the risk framing needs adjusting. The question is no longer “could this person defraud us” but “what is the blast radius if this agent is wrong or is manipulated”, and blast radius scales with both concentration of authorization and volume of transactions, both of which are higher for agents than for the humans they replaced.
What to Test SAP SoD
Given that GRC will not surface most of this automatically, testing has to carry the load. Five assertion areas, in rough order of value.
| Assert | What It Catches | How |
| Agents are in the ARA population | The whole class of conflicts nobody is looking at | Confirm the ruleset scope includes system, service and communication user types, not only dialog |
| Actual authorization use vs. grant | Over-provisioning, objects granted but never exercised | Authorization trace over a representative period, compared against the assigned profile |
| Threshold enforcement in practice | Agents acting above documented value or approval limits | Negative testing, present transactions above the limit and confirm refusal or escalation |
| Organisational boundary respect | Agents acting in company codes, plants or purchasing orgs outside intended scope | Assert on org fields in posted documents against the intended operating scope |
| Conflicting function pairs in practice | The agent actually exercising both halves of an SoD pair | Analyse posted activity for both functions by the same agent identity within a period |
The first row is the cheapest and highest-value check on this list, and it takes about an hour. Confirm whether your ARA ruleset scope includes non-dialog user types. If it does not, everything below it is moot until it does, and you may find agent conflicts that have existed quietly for months.
The last row deserves a note on why it differs from standard ARA. GRC analyses what a user *could* do based on assigned authorizations. For agents, what they *actually did* is more informative, an agent may hold a conflicting pair and only ever exercise one half, or may hold apparently benign access and combine it in an unanticipated sequence. Activity-based analysis catches what entitlement-based analysis misses.
Testing as the Mitigating Control
Here is where this resolves into something practical rather than just a warning.
GRC already has a well-established answer for conflicts that cannot be eliminated: apply a mitigating control, evidence it, and review periodically. The framework is sound. What fails for agents is the specific control usually chosen, human periodic review, because it does not scale to agent volume and the reviewer cannot judge correctness by inspection.
Continuous validation of agent outcomes is a better fit for the same slot. It is a mitigating control in exactly the GRC sense: it does not remove the conflicting capability, it detects misuse of it. And it improves on the human version in two respects, it covers every transaction rather than a sample, and it produces evidence continuously rather than at review points. Check out SOX testing checklist for AI Agents in ERP.
The GRC framework already accommodates this. What needs replacing is the mitigating control, not the framework.
Framing it that way also makes the conversation with internal audit considerably easier, because you are not proposing something outside their model. You are populating an existing slot with a control that fits the risk profile better than the default.
Where Sofy Fits
Sofy’s SAP Test Agents validate business outcomes at the data layer, which is what makes the activity-based analysis above practical rather than a manual exercise.
Against the assertions in the table: organizational boundary compliance is checked by asserting on org fields in posted documents against intended scope; threshold enforcement is validated through negative testing, presenting transactions above documented limits and confirming refusal or escalation rather than execution; and conflicting-function activity is surfaced by analyzing what an agent identity actually did within a period rather than what it was entitled to do.
Each validation produces a timestamped, immutable record, which is what turns this from a testing activity into evidenced control operation, the thing an auditor needs when asking how you know an agent stayed inside its boundary.
It sits alongside GRC Access Control rather than replacing it. GRC governs entitlement; this covers what was done with it.
What This Doesn’t Solve
Two things worth stating, because this is a controls topic and over claiming would be worse than useless.
Testing detects misuse of authorization; it does not reduce the authorization itself. If an agent holds a genuinely excessive profile, the right remediation is to reduce it, informed by trace analysis showing what is actually exercised. Detection is a compensating control for what cannot be eliminated, not a substitute for least privilege where least privilege is achievable.
And the decision about how much authorization an agent should hold is a risk decision, not a testing output. Testing will tell you what an agent is doing with what it has. It will not tell you how much it should have been given, and the honest answer for most organizations is less than the technology permits, at least until there is real operating history to reason from.
Frequently Asked Questions
Does SAP GRC detect segregation of duties conflicts for AI agents?
Frequently not, and the reason is scoping rather than capability. Agents operate through system, service or communication user types, and many Access Risk Analysis configurations scope their runs to dialog users, sometimes to suppress technical account noise, sometimes because the ruleset was configured before agents existed. An agent can hold a textbook conflict and never appear in the report. Checking whether your ARA scope includes non-dialog user types takes about an hour and is the highest-value check available.
Why do AI agents end up with excessive SAP authorizations?
Because of how they are provisioned. Humans are provisioned from a job description, and the job boundary does security work before anyone opens PFCG. Agents are provisioned from a task list, so authorizations are granted for what the agent does rather than for what a person is permitted to be. Each grant is individually defensible; the accumulated profile can span functions that belong to two or three separate human roles.
Does segregation of duties still apply if an agent has no fraudulent intent?
Yes, though the rationale shifts. SoD was designed around human intent, interrupting the chain of motive, opportunity and concealment. An agent has no motive but does concentrate capability, and does so at volume without hesitation. The relevant question becomes blast radius rather than fraud risk: what happens if this agent is wrong, or is influenced through its inputs, and applies that consistently across thousands of transactions.
What should SAP SoD testing check for agents specifically?
Five areas: that agents are within the ARA analysis population at all; actual authorization usage compared against what was granted, via trace analysis; threshold enforcement validated through negative testing rather than configuration review; organizational boundary compliance asserted on posted document fields; and conflicting-function pairs analyzed on the basis of what the agent actually did rather than what it was entitled to do.
Can continuous testing serve as a GRC mitigating control?
It fits the slot well. GRC practice for unavoidable conflicts is to apply a mitigating control that detects misuse and is evidenced, usually periodic human review. For agents, periodic sampled review does not scale and the reviewer often cannot judge correctness by inspection. Continuous outcome validation covers every transaction rather than a sample and produces evidence continuously, which fits the same framework better than the default control does.
The Bottom Line
SAP’s authorization model is one of the more carefully constructed access frameworks in enterprise software, and none of this is a criticism of it. It was built for a world where access belongs to people who hold positions, and it does that job well.
Agents do not hold positions. They hold capabilities, assembled task by task, and the job boundary that quietly enforced separation for decades was never present when their access was designed. GRC will not usually flag the result, because agents frequently sit outside the population it analyses.
The practical response is not to rebuild the framework. It is to bring agents inside the analysis population, reduce what is demonstrably unused, and replace the default mitigating control with one that actually scales, continuous validation of what agents did, evidenced per transaction, rather than a quarterly sample nobody can meaningfully assess.em rather than a sampling one. And validate against the close calendar your controllers are actually working to, not the periods SAP happens to leave open.
Validate What Agents Actually Did, Not Just What They Could Do
See Sofy assert on organizational boundaries, threshold compliance and conflicting-function activity in your own SAP environment, with evidence for each check.