Finance leaders are under constant pressure to cut costs, and automation is the fastest lever available. IT teams are asked to hand AI agents more autonomy every quarter, and in many workflows that autonomy now stretches across the full transaction lifecycle: an agent reads customer or financial data, produces a recommendation, approves it, executes the action through an API, and writes the log entry that documents what happened.
No serious organization would hand a single employee that combination of powers without a control wrapped around every step. Yet that is precisely the architecture some companies are building today, one agent deployment at a time, often without anyone deciding to do so on purpose. This piece walks through why that pattern is a genuine segregation of duties problem, what Sarbanes-Oxley actually requires when an agent touches a financially relevant process, and what a control owner can do about it in practice.
Why AI agents are quietly rebuilding a segregation of duties failure
Segregation of duties, or SoD, is one of the oldest ideas in internal control. It exists because no single actor should be able to complete a transaction's entire lifecycle alone. The classic control chain breaks a transaction into four functions: initiation, authorization, execution or custody, and recording. The rule is simple: the same actor should never occupy more than one of those seats for the same transaction.
This is not an informal convention. The COSO Internal Control Integrated Framework codifies it under Principle 10, which requires organizations to select and develop control activities, including the segregation of incompatible duties, that reduce risk to an acceptable level. ISO/IEC 27001 makes the same point from an information security angle: Annex A control 5.3, segregation of duties, requires conflicting duties and conflicting areas of responsibility to be separated to reduce opportunities for unauthorized or unintentional modification or misuse of an organization's assets. NIST SP 800-53 codifies an equivalent requirement under control family AC-5, separation of duties, for federal and regulated information systems.
None of these frameworks say "person." They say actor, function, or duty. An agent that reads customer or financial data, generates a recommendation, approves that recommendation, calls the execution API, and writes its own log entry has assembled every incompatible function into a single identity. That is exactly the pattern SoD design exists to prevent, and the fact that it emerged from a cost-reduction automation initiative rather than a deliberate access decision does not change how an auditor or examiner will classify it.
The "human in the loop" conversation often gets raised as the fix, and it deserves a direct answer: it does not scale. Once agents are executing hundreds or thousands of routine actions a day, a human reviewing every single one stops being a real control and becomes a rubber stamp. The sustainable answer is not adding more manual checkpoints. It is engineering independence directly into the system, the same way separate identities, transaction limits, and independent approval have always worked for human roles, so that oversight does not depend on a person being available to click approve.
What SOX actually demands when an agent touches financial data
Sarbanes-Oxley does not regulate artificial intelligence. It regulates internal control over financial reporting, and it is indifferent to what performs a control step as long as that step touches a process capable of producing a material misstatement. Two provisions matter most here.
Section 404 requires management to assess and report on the effectiveness of internal control over financial reporting, and PCAOB Auditing Standard 2201 governs how the integrated audit tests those controls, including automated and IT-dependent ones. AS 2201 introduces the concept of precision: a control is only useful if it operates at a level of precision that would adequately prevent or detect a misstatement on a timely basis. That precision concept is the thread that runs through nearly every issue discussed in this article, because a control that exists on paper but cannot actually catch an error at the right moment does not satisfy this standard, regardless of how many approval steps are documented in a process narrative.
Section 302 is the other half, and it is personal. The CEO and CFO certify that disclosure controls and internal control over financial reporting are effective. If an agent has silently collapsed initiation, approval, execution, and recording into a single identity inside a financially relevant workflow, and nobody flagged it as a deficiency, that certification now rests on an assumption nobody actually verified.
This is where IT general controls, or ITGCs, become the practical battleground. Access provisioning, deprovisioning, change management, and privileged access review are exactly where this issue gets caught, or missed, because an agent's service account is an access-control artifact long before it becomes an AI governance topic. If your ITGC testing scope still assumes every privileged credential belongs to a human employee, agent identities are walking straight through the gap.
The reassuring part is that materiality still governs everything. A routine, low-dollar vendor payment does not need the same separation rigor as a wire transfer above a delegation-of-authority threshold. COSO's risk-based approach, echoed in ISO 31000's principle that risk management should be proportionate to the significance of the risk, means control intensity should scale with the size and reversibility of what the agent is authorized to do. Applying maximum rigor uniformly to every agent workflow is not just wasteful, it also tends to produce control fatigue that quietly erodes the rigor applied to the transactions that actually matter.
How much authority can one agent hold before autonomy becomes a control gap
The threshold is not a headcount, a step count, or a number of tools connected to an agent's toolkit. It is crossed the moment a single identity, human or agentic, can complete an end-to-end high-risk transaction without an independently sourced, independently authorized check standing between recommendation and execution. That is true whether the agent takes five steps or fifty, and it is true whether the transaction is a customer refund, a vendor payment, or a change to a general ledger account.
This is not a theoretical worry among practitioners. The OWASP Top 10 for LLM Applications names this pattern excessive agency, defined as a failure of an LLM-based application to independently verify and approve high-impact actions before taking them. OWASP breaks the root cause into three components worth memorizing: excessive functionality, where an agent has access to tools beyond what its task requires; excessive permissions, where those tools carry broader privileges than the task needs; and excessive autonomy, where high-impact actions proceed without any human or independent checkpoint in the loop. Across recent revisions of that list, this category has consistently moved up in ranking, which is a reasonable proxy for how quickly practitioners are running into exactly the accumulation problem described above.
OWASP has since gone further with a dedicated risk taxonomy for agentic applications under its GenAI security initiative, naming identity and privilege abuse as its own category, covering agents that misuse inherited credentials or operate with permissions broader than their intended scope. The honest takeaway is that the standards bodies are moving faster on naming and categorizing this risk than most enterprise identity and access management architectures are moving to contain it. If your governance program has not yet mapped its agent inventory against these categories, that is a reasonable next audit step rather than a nice-to-have.
A practical rule for control owners: before approving any new agent deployment into a financially relevant process, ask whether that single agent identity could, on its own, complete the full chain from data access to execution to logging. If the answer is yes, the deployment needs an independent checkpoint before it goes live, not after an auditor finds it.
Why UI-based controls collapse once agents call APIs directly
This is the part of the problem most GRC teams underweight, and it deserves direct attention. Native ERP and treasury system role-based access control, along with the SoD matrices that GRC platforms enforce on top of it, live at the transaction-code and screen-menu layer. That is also where the overwhelming majority of SOX ITGC testing has historically pointed its evidence-gathering, because that is where human users interacted with the system.
An agent calling an API endpoint or querying a database directly never passes through that enforcement point. A control that was designed and tested at the UI layer simply does not apply to the path the agent actually takes to complete its work. From an audit perspective, this is not a new risk category requiring a new framework. It is a control design gap, precisely the condition PCAOB guidance asks auditors to identify when evaluating whether a control is suitably designed to address the risk it is meant to mitigate. A control that no longer matches how the process actually operates is not an effective control, no matter how well it worked when everything ran through a login screen.
The fix is architectural rather than procedural. The policy enforcement point needs to move to wherever the agent actually acts: a policy engine sitting at the API gateway or tool broker that every agent call passes through, combined with database-level row and column security so that data access is constrained regardless of which door the agent uses to get in. Deterministic policy checks at that layer, validating every proposed action against business rules, approval status, transaction limits, and SoD constraints before execution is allowed, prevent an agent from effectively self-approving its own action. This single architectural decision, enforcing SoD in the control plane rather than the presentation layer, does more to close this gap than any amount of additional documentation.
Teams running a SOX walkthrough this cycle should specifically ask process owners how each agent-executed transaction reaches the system of record. If the answer involves an API call or a direct database write, the existing UI-based control needs a documented compensating control at the API or database layer, tested with the same rigor as the original control it is replacing.
How over-provisioned APIs turn one task into unlimited access
This is a structural problem that predates AI agents but gets exposed by them. Most enterprise systems were built assuming a human clicking through screens, where authorization objects can be scoped down to a specific transaction type or field. The API layer usually was not built with that same granularity, because until recently nobody needed a machine identity that could call only one narrow slice of business logic. The practical consequence is uncomfortable: giving an agent even one legitimate capability often means issuing a credential that can do considerably more than that single task requires.
This is the same pattern described under OWASP's identity and privilege abuse category: agents inheriting broad, high-privilege credentials and then passing that authority along a delegation chain to other agents or subprocesses, which compounds exposure rather than containing it. A read permission granted for one reporting task can, in a poorly scoped API, also carry write access to adjacent tables the agent was never meant to touch.
Under SOX, the relevant control already exists on paper in most organizations: the periodic user and entitlement access review, a standard ITGC. The gap is scope. That review needs to be explicitly extended to service accounts and agent identities rather than limited to human logins, and it needs to confirm that the granted scope actually matches the task rather than simply confirming that a review took place. Auditors are increasingly asking for the former, and a control narrative that only demonstrates "a review happened" without evidence of scope validation will not hold up under scrutiny.
Where a vendor's native API will not offer that granularity, the workable pattern is a proxy or gateway placed in front of the core system that mints narrow, time-boxed, task-specific tokens rather than handing the agent the vendor's coarse default scope. This is more engineering work upfront, but it is considerably cheaper than remediating a material weakness after the fact, and it aligns directly with the least-privilege principle embedded in both ISO/IEC 27001 and NIST's access control guidance.
Why an approval agent needs source data, not a summary
Separating identities on paper does not automatically create independence in practice, and this is the sharpest gap in most current agent deployments. Auditors already have a term for the underlying concept: precision of a review control, drawn from the same PCAOB guidance on whether an entity-level control operates at a level of precision sufficient to catch a misstatement. A review is only as strong as the reviewer's actual ability to detect an error.
If an approving agent's only input is the proposing agent's narrative summary, the organization has separated the labels without separating the duty. COSO's own caveat on segregation of duties applies with equal force to two agents as it does to two employees: SoD provides risk mitigation and reporting confidence only to the extent that collusion among the relevant parties is avoided. Two agent identities that share the same base model, the same orchestrator, the same memory store, or the same engineer's prompt template are not independent in any sense an auditor would recognize, even if the access logs show two distinct service accounts making the calls.
Real independence means the approving step retrieves its own primary source data rather than trusting a hand-off summary. A payment approval agent should pull the invoice, the purchase order, and the relevant general ledger line directly, rather than accepting the proposing agent's characterization of what those documents say. This single design choice is the difference between a control that exists and a control that works.
A useful test for validating whether this independence actually holds: feed the proposing agent a plausible but incorrect justification and observe whether the approving agent catches it. This is functionally a walkthrough test, the same technique auditors have long used to confirm a control operates as designed rather than merely exists in a process narrative, and it belongs in ongoing control monitoring rather than a one-time launch check. OWASP's agentic risk taxonomy has named this exact failure mode human-agent trust exploitation, describing situations where an agent's persuasive or misleading output influences another agent, or a human, into an unsafe approval. When a practitioner discussion and a formal industry taxonomy converge independently on the same diagnostic test, that is a strong signal the concern is well-founded rather than speculative.
How to build segregation of duties into the agent lifecycle
Translating all of this into a working control design starts with treating the five functions an agent might perform, data access, analysis and recommendation, approval, execution, and recording, as five separable responsibilities that belong on distinct identities with distinct, independently enforced permissions. The table below maps each function to the control pattern that keeps it independent.
| Function | Control pattern |
|---|---|
| Data access | Read-only service identity, scoped by row and column-level security, with time-boxed tokens and no write privileges |
| Analysis and recommendation | Separate analyst identity that outputs a structured recommendation with supporting evidence and cannot call execution endpoints |
| Approval | Distinct approval service or human workflow that independently retrieves primary source data and is bound to the exact transaction identifiers, amounts, and counterparties |
| Execution | Executor identity with write access limited to specific endpoints, which re-validates the approval token and policy limits before calling any payment, transfer, or posting API |
| Recording | Immutable logging service, operated independently of the agents themselves, that captures the full chain from data accessed through approval metadata to execution outcome |
The anti-pattern to eliminate first is the single agent identity holding read, approve, and execute privileges end to end. That is the electronic equivalent of one employee holding the check-signing stamp, the approval authority, and the ledger key simultaneously, and no control framework in existence would accept that arrangement for a human role.
Beyond the technical mapping, this also means rethinking where agent oversight sits within an organization's lines of defense model. The team building and operating the agent functions as the first line, responsible for day-to-day design and monitoring. Risk and compliance, setting policy limits and reviewing entitlement scope, functions as the second line. Internal audit, running independence tests like the adversarial justification check described above, functions as the third line, and that testing needs to happen on a recurring cadence, not just at initial deployment.
A few additional practices round out a durable design. Every agent identity should carry mutual TLS authentication and short-lived, automatically revoked tokens rather than long-lived static credentials. Authorization logic, including transaction limits and approval rules, belongs in a policy engine rather than embedded in application code, so it can be audited and updated independently of the agent's underlying model. Monitoring should establish a behavioral baseline for each agent and alert on anomalies such as unusual tool usage, repeated attempts to bypass an approval gate, or sudden spikes in high-risk actions. None of these controls are exotic. They are the same access management and monitoring disciplines that have governed privileged human accounts for years, applied now to a new category of identity that happens to run on a model instead of a payroll number.
Why Does Sarbanes Oxley Care About Autonomous AI Agents
The Sarbanes Oxley Act of 2002 was enacted to protect investors by improving the accuracy and reliability of corporate disclosures. It does not regulate specific technologies, nor does it mention artificial intelligence. Instead, it regulates internal control over financial reporting. The law is entirely indifferent to the mechanism used to execute a control, provided that the mechanism effectively prevents or detects a material misstatement in the financial statements. When an artificial intelligence agent interacts with financially relevant processes, it becomes a critical component of the internal control structure. If that agent can initiate, approve, execute, and record a transaction without independent oversight, it creates a significant vulnerability in the internal control over financial reporting.
Section 404 of the Sarbanes Oxley Act requires management to assess and report on the effectiveness of internal control over financial reporting. This assessment must include all controls that are relevant to the financial reporting process, including automated controls and information technology general controls. When an agent is granted broad permissions across an enterprise resource planning system, it directly impacts the IT general controls related to access provisioning and logical security. If the agent is granted excessive privileges, or if its permissions are not regularly reviewed and reconciled, the organization may have a deficiency in its IT general controls. Depending on the materiality of the transactions the agent can process, this deficiency could escalate to a significant deficiency or a material weakness, requiring disclosure to investors and regulators.
Section 302 requires the chief executive officer and chief financial officer to personally certify the effectiveness of disclosure controls and internal control over financial reporting. This personal liability places a tremendous burden on the executive team to ensure that all automated processes are properly controlled. If an autonomous agent silently collapses incompatible functions within a critical financial workflow, and the control environment fails to identify this as a deficiency, the executive certification is resting on an unverified assumption. The Public Company Accounting Oversight Board auditing standards, specifically AS 2201, govern how external auditors test these controls. The standards emphasize the importance of evaluating the design and operating effectiveness of automated controls. An automated control that lacks proper segregation of duties is, by definition, poorly designed.
The concept of precision in review controls is particularly relevant when evaluating artificial intelligence agents. A review control is only effective if the reviewer has the ability to detect an error or irregularity. If an approval process relies on an agent reviewing a summary generated by another agent, the precision of that control is highly questionable. The approving agent is relying on the output of the proposing agent, which means it is not independently verifying the underlying data. The Public Company Accounting Oversight Board guidance requires that review controls operate at a level of precision sufficient to catch a misstatement on a timely basis. To satisfy this requirement, the approval step must involve independent retrieval and verification of the primary source data, rather than relying on a handoff summary. Organizations must design their agentic workflows to ensure that the precision of automated review controls meets the rigorous expectations of external auditors.
How Can We Enforce Segregation Of Duties At The API Layer
The traditional approach to enforcing segregation of duties relies heavily on the user interface of enterprise applications. Role based access control matrices are configured within the application to ensure that a user with the permission to create a vendor cannot also approve an invoice for that vendor. These controls are enforced at the screen level, preventing the user from even accessing the transaction codes required to perform incompatible functions. However, autonomous artificial intelligence agents rarely interact with systems through the user interface. They communicate directly with the application programming interfaces or query the underlying databases. When an agent bypasses the user interface, it also bypasses the screen level segregation of duties controls. This creates a massive blind spot in the control environment.
To address this architectural gap, organizations must move the policy enforcement point from the user interface to the application programming interface gateway or the database layer. The segregation of duties rules must be encoded into a centralized policy engine that intercepts every request made by an agent. When an agent attempts to execute a transaction, the request is first routed to the policy decision point. The policy engine evaluates the request against the segregation of duties matrix, checking the identity of the agent, the target resource, and the current state of the transaction. If the request violates a segregation of duties rule, the policy enforcement point blocks the execution and returns an error. This ensures that the control is enforced regardless of how the agent attempts to access the system.
Implementing this architecture requires a fundamental shift in how identity and access management is handled for non human entities. Each distinct function within an agentic workflow must be assigned a unique service identity. The agent that analyzes the data and generates the recommendation must have a different identity than the agent that approves the recommendation. The identity that executes the transaction must be separate from the identity that records it in the general ledger. These identities must be managed within the enterprise identity provider, and their permissions must be strictly scoped to the specific application programming interface endpoints required for their function. This prevents an agent from escalating its privileges or accessing endpoints outside its designated scope.
At the database level, organizations must implement row level and column level security to further restrict agent access. Even if an agent has permission to call a specific application programming interface endpoint, it should only be able to read or modify the specific records relevant to its task. Row level security ensures that an agent processing payments for a specific region cannot access records from another region. Column level security ensures that an agent analyzing transaction volumes does not have access to sensitive customer personally identifiable information. By combining application programming interface gateway policy enforcement with granular database security, organizations can create a robust control environment that enforces segregation of duties at the exact point where the agent interacts with the data, effectively closing the loophole created by direct system access.
What Is The Precision Of Review Controls For AI Approvals
The effectiveness of any approval control depends entirely on the precision of the information provided to the approver. In a traditional manual environment, an approver reviews the supporting documentation, verifies the calculations, and confirms the business justification before authorizing a transaction. If the approver simply clicks approve without reviewing the details, the control is operating ineffectively. When we introduce artificial intelligence agents into the approval process, we face a unique challenge regarding the precision of the review. If an approving agent is only provided with a narrative summary generated by the proposing agent, the precision of the control is severely compromised. The approving agent is not independently verifying the underlying data; it is merely evaluating the persuasion and logic of the proposing agent.
This dynamic creates a scenario where two distinct agent identities are technically performing the segregation of duties, but functionally, they are not independent. If both agents share the same underlying foundation model, the same contextual memory, or the same system prompts, they are subject to the same biases and hallucinations. An error in the initial data retrieval will propagate through the proposing agent and be accepted by the approving agent, because the approving agent lacks the independent context required to identify the error. From an audit perspective, this is akin to two employees colluding to bypass a control. The segregation of duties provides risk mitigation only to the extent that the parties are truly independent. To satisfy regulatory expectations, the approving agent must independently retrieve and verify the primary source data.
To achieve the necessary precision, the architecture of the agentic workflow must enforce independent data retrieval. The proposing agent should generate a recommendation and provide the specific identifiers for the underlying data, such as the purchase order number, the invoice identifier, and the vendor record. The approving agent must then use those identifiers to query the database directly, retrieving the raw data independently. It must then perform its own calculations and validations to confirm that the recommendation is accurate. This ensures that the approval is based on verified facts rather than a potentially flawed summary. The control environment must be designed to prevent the approving agent from simply trusting the output of the proposing agent.
Furthermore, organizations must implement adversarial testing to validate the precision of these automated review controls. Just as auditors perform walkthroughs to ensure that manual controls operate as designed, governance teams must regularly test the approving agent with flawed or misleading inputs. By providing the proposing agent with a convincing but incorrect justification, the governance team can observe whether the approving agent successfully identifies the discrepancy. If the approving agent rubber stamps the flawed recommendation, the control is operating ineffectively and must be redesigned. This continuous testing ensures that the precision of the review control remains high over time, adapting to changes in the underlying models and the evolving complexity of the business logic.
How Do We Prevent Identity And Privilege Abuse In Agentic Workflows
The Open Web Application Security Project has identified excessive agency as a critical risk in large language model applications. This risk category encompasses situations where an artificial intelligence agent is granted more functionality, permissions, or autonomy than is necessary to perform its designated task. In the context of enterprise resource planning and financial systems, this risk is exacerbated by the coarse grained nature of legacy application programming interfaces. These systems were designed for human users interacting with screens, where authorization objects could be scoped to specific transaction types. The application programming interfaces, however, often expose broad, high privilege scopes. Granting an agent access to a specific financial function often requires issuing a credential that can perform a wide range of unrelated actions.
This over provisioning of access creates a significant vulnerability. If the agent is compromised, or if it behaves unexpectedly due to a prompt injection attack, the attacker inherits the broad privileges of the agent. The agent can then move laterally across the system, accessing data and executing transactions far beyond its intended scope. This pattern of identity and privilege abuse is a primary concern for governance and risk professionals. To mitigate this risk, organizations must abandon the practice of issuing static, broad scope credentials to agents. Instead, they must implement a dynamic, context aware access management architecture that issues time boxed, task specific tokens.
The implementation of just in time access requires a token broker that sits between the agent orchestrator and the target systems. When an agent needs to perform a specific task, it requests a token from the broker. The broker evaluates the request against the agent identity, the specific task parameters, and the current risk context. If the request is approved, the broker mints a short lived token with a scope strictly limited to the exact application programming interface endpoints and data records required for that specific task. Once the task is completed, or the time limit expires, the token is automatically revoked. This ensures that the agent only possesses the minimum necessary privileges at any given moment, drastically reducing the blast radius of a potential compromise.
In addition to dynamic access management, organizations must extend their periodic user access review processes to include non human identities. Traditionally, access reviews focus on human employees, ensuring that their permissions align with their current job responsibilities. In an agentic environment, the service accounts and agent identities must be subjected to the same rigorous review. The owners of the agents must regularly certify that the permissions granted to the agent are still required for its function and that no excessive privileges have been accumulated over time. This review must go beyond simply confirming that an access review took place; it must verify that the granted scope actually matches the operational requirements of the agent. By combining just in time access with rigorous periodic reviews, organizations can effectively prevent identity and privilege abuse in their agentic workflows.
Securing financial artificial intelligence agent architectures requires a comprehensive set of practical controls that span identity management, data protection, and continuous monitoring. The foundation of this control environment is the establishment of immutable, tamper evident audit trails. Every action taken by an agent, including the prompts it receives, the data it accesses, the tools it invokes, the decisions it makes, and the outcomes it produces, must be logged. These logs must be written to a centralized, secure repository that the agents themselves cannot modify or delete. Cryptographic hashing should be used to chain the log entries, ensuring that any attempt to alter the historical record is immediately detectable. This immutable telemetry is essential for reconstructing the full context of a transaction during an audit or an incident investigation.
Another critical control is the strict separation of memory and context between distinct agent identities. In many agentic frameworks, agents share a common memory pool or context window to facilitate collaboration. From a segregation of duties perspective, this shared context effectively collapses the independence of the agents. If the approving agent has access to the same internal reasoning and memory as the proposing agent, it is not performing an independent review. The architecture must enforce strict boundaries, ensuring that each agent identity operates with its own isolated context. Communication between agents should occur only through structured, standardized messages that contain the necessary data for the next step, without exposing the underlying reasoning or intermediate calculations.
For high risk and irreversible transactions, a human in the loop control is mandatory. While autonomous agents can handle routine, low value transactions, material payments, changes to critical master data, and other high impact actions require explicit human approval. This approval should not be a simple click in a workflow tool. The human reviewer must be presented with a clear, comprehensive view of the transaction, including the original source data, the agent recommendation, and the agent reasoning. The interface must allow the human to easily verify the details and, if necessary, reject the transaction or request additional information. Step up authentication, such as multi factor authentication, should be required for the human to authorize the action, ensuring that the approval is deliberate and verified.
Finally, organizations must implement continuous control monitoring and anomaly detection specifically designed for agent behavior. Traditional monitoring tools focus on human user behavior, looking for unusual login times or access to sensitive files. Agent behavior requires a different analytical approach. The monitoring system must establish a baseline of normal agent activity, including the typical volume of transactions, the specific endpoints accessed, and the execution times. Any deviation from this baseline, such as a sudden spike in high value transactions, an attempt to access an unauthorized endpoint, or a repeated failure in the approval workflow, should trigger an immediate alert. By combining immutable logging, isolated contexts, human oversight for material actions, and continuous behavioral monitoring, organizations can build a resilient control environment that safely supports the deployment of autonomous agents in critical financial processes.
A practical control guide for SAP Joule and segregation of duties
SAP Joule does not run a separate SoD engine built specifically for agents. Instead, it treats every Joule agent as an authenticated, non-human identity that inherits and operates within the same authorization and GRC controls already governing human users, with additional governance layers for agent identity, scenario registration, and policy enforcement layered on top. For a control owner, the first practical step is confirming this assumption holds in your own landscape: pull the identity directory and verify that every Joule agent shows up as a distinct, named entity rather than sharing a generic technical user, because shared service accounts are the single fastest way to lose SoD visibility in an agentic deployment.
Two execution patterns matter, and each carries different SoD implications. In the first, a user invokes Joule directly, and Joule propagates that user's authorization context, using SAP Identity Authentication Service and a Global User ID, when it calls back into S/4HANA or another SAP system. The back end enforces its normal authorization objects and SoD rules exactly as if the user had clicked through the GUI, which means existing GRC Access Control rules apply automatically and a user with conflicting roles cannot use Joule as a shortcut around them. The practical tip here is to resist the temptation to grant Joule any broader scope than the invoking user already holds. If your GRC rule set has gaps in the human role design, principal propagation will faithfully carry those same gaps into every agent-executed transaction.
The second pattern, autonomous or scheduled agents acting without a specific user prompt, deserves more scrutiny. These agents should be registered as distinct service identities with their own narrowly scoped authorization profiles, for example read-only access to specific tables or write access limited to a single document type or queue. A practical control here is to require every autonomous agent's authorization profile to be reviewed and signed off by the same access governance team that reviews human role assignments, on the same review cadence, rather than treating agent onboarding as a separate IT provisioning task exempt from GRC oversight.
Cross-system action chains are where most teams get caught off guard. An agent that reads from one module, writes to another, and triggers a workflow in a third can assemble a functional SoD conflict even when no single system shows a violation in isolation. The tip worth building into your design review checklist: evaluate SoD not just per transaction code, but across the full sequence of systems an agent touches in a single scenario, and extend your GRC rule book to include these cross-system combinations explicitly rather than assuming existing single-system rules will catch them.
Architecturally, SoD in Joule is enforced through a combination of the agent gateway and scenario catalog, which exposes agents as registered scenarios with defined capabilities, and the underlying back-end authorization objects and GRC rules that fire when the agent actually touches data. SoD is not happening inside the language model itself. A practical implication: if you are validating a new Joule scenario before production release, test it at the point where it calls back into S/4HANA or another target system, not by inspecting the prompt or scenario definition alone, since that is where the enforceable control actually lives.
Auditability closes the loop, and this is where many early deployments fall short. Every agent-triggered action, from data accessed through recommendation, approval, and execution, needs an immutable log entry so an auditor can reconstruct the full chain months later. A useful practice adopted by more mature SAP shops is extending existing Process Control test scripts to explicitly cover Joule agent execution, so agentic workflows generate the same continuous control evidence a human-driven process would. Pair this with periodic negative testing, deliberately asking an agent to act outside its authorized scope and confirming it refuses or escalates, which functions as a live SoD test even though the agent is not a traditional GRC user.
Mapping this back to the five-function chain, access, recommend, approve, execute, and record, the concrete design goal is to keep each function on a separate identity with its own authorization profile, never collapsing approval and execution into the same agent regardless of how convenient that seems during a pilot. Before scaling any Joule agent from pilot to production, confirm three things: the agent has its own identity in the directory rather than a shared credential, its authorization profile has been reviewed by the same team that reviews human SoD conflicts, and its actions generate log evidence sufficient to satisfy your existing SOX ITGC testing procedures. Getting these three checks right before go-live is considerably cheaper than remediating a finding after an auditor discovers them first.
Final perspective
The uncomfortable truth in this discussion is that nobody set out to build a control failure. Cost pressure pushed automation forward, automation pushed agent autonomy forward, and segregation of duties eroded as a side effect rather than a decision. That does not change how a Section 302 certification, a PCAOB audit, or an ISO 27001 certification audit will treat the outcome. A control deficiency created by accident is still a control deficiency, and an agent capable of completing an entire financially relevant transaction alone is exactly the concentration of function these frameworks were built to prevent.
The fix is not adding more human approval clicks, because that approach does not survive contact with the volume agents are designed to handle. The fix is engineering independence into the system itself: distinct identities for distinct functions, policy enforcement that lives at the API and database layer rather than the UI, entitlement reviews that actually validate scope rather than confirm a checkbox, approval steps that pull their own source data, and adversarial testing that runs continuously rather than once at launch. This is a harder design problem than it looks, but it is the same problem segregation of duties has always solved. The employee has just changed.
References
- COSO, Internal Control Integrated Framework, Principle 10 on control activities. https://www.coso.org/guidance-on-ic
- PCAOB Auditing Standard 2201, An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements. https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201
- Sarbanes-Oxley Act of 2002, Sections 302 and 404. https://www.sec.gov/about/laws/soa2002.pdf
- ISO/IEC 27001, Information security, cybersecurity and privacy protection, Annex A control 5.3, Segregation of duties. https://www.iso.org/isoiec-27001-information-security.html
- ISO/IEC 42001, Artificial intelligence management system. https://www.iso.org/standard/81230.html
- ISO 31000, Risk management guidelines. https://www.iso.org/iso-31000-risk-management.html
- NIST Special Publication 800-53, Security and Privacy Controls for Information Systems and Organizations, control family AC-5, Separation of Duties. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- NIST AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework
- OWASP Top 10 for Large Language Model Applications. https://owasp.org/www-project-top-10-for-large-language-model-applications/
- OWASP GenAI Security Project, agentic application risk taxonomy. https://genai.owasp.org/
- OWASP AI Agent Security Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
- FINOS AI Governance Framework, agent authority and least privilege mitigation guidance. https://air-governance-framework.finos.org/mitigations/mi-18_agent-authority-least-privilege-framework.html