A Federated Control Plane for Human and Non‑Human Identities in SOX/ITGC‑Governed ERP Environments
Executive summary
AI is now a first‑class operator in ERP and SaaS, but most control frameworks still assume only humans touch financial systems. AI agents, copilots, Robotic Process Automation (RPA), and integrations now act across Oracle, SAP, Workday, and business‑critical SaaS at machine speed, executing transactions, changing master data, and orchestrating workflows that used to be gated by human users. In many enterprises, non‑human identities already outnumber humans and operate with broader entitlements and weaker oversight, while the surrounding governance model is still built for human users and isolated applications.
Traditional, fragmented access governance often cannot reliably answer who—or what—has access to which systems and data across ERP and SaaS, or how that access has changed over time. Legacy IAM and IGA tools were primarily built for human identities and application‑level roles, not for AI agents driving fine‑grained ERP transactions and cross‑system workflows. This “ghost identity” gap is described in Access Governance for AI Agents: Managing Non‑Human Identities and Top 5 AI Access Risks for CISOs and How AI Governance Closes the Gaps.
Three fundamental breakdowns now magnify AI access risk in highly governed environments:
- AI agents and other non‑human identities accumulate entitlements across multiple provisioning events and rarely go through formal recertification, creating silent privilege creep and opaque risk.
- Cross‑system Segregation of Duties (SoD) conflicts (for example, SAP plus Coupa, or Oracle plus Salesforce) are invisible to single‑system analyzers and role‑only SoD models.
- Non‑human identities often lack a defined owner, a documented business purpose, and a scoped risk posture, leaving auditors without evidence and control owners without accountability.
To close these gaps, enterprises need a federated, policy‑based identity governance control plane that covers human and non‑human identities while preserving Oracle, SAP, and SaaS domain autonomy and local configurations. This is the federated model described in Federated Governance for AI Identities: Closing the 92% Visibility Gap.
For Oracle‑centric environments, this federated model is grounded in the reference architecture described in Inside the SafePaaS + Oracle ERP Architecture: Security Context and Data Flows, and in the AI governance patterns outlined in AI Governance: When AI Becomes an Identity
SafePaaS delivers this layer above Identity Access Management (IAM) and Single Sign‑On (SSO) and below ERP/SaaS, enforcing unified joiner–mover–leaver lifecycle management, preventive cross‑system SoD simulation, continuous monitoring, access certification, and audit‑ready evidence for every identity—human or AI.
1. Why AI access is different
AI agents challenge core assumptions behind traditional access‑governance models.
1.1 Governance gap
The first challenge is that governance models still assume users are humans anchored in HR. Traditional access governance assumes human users with HR‑driven joiner–mover–leaver events, manager‑based access approvals, and periodic (often annual) access reviews. Controls, workflows, and evidence models were designed around named individuals accountable for their actions and entitlements.
Non‑human identities violate these assumptions in ways that matter for SOX and operational risk. They are typically created outside HR processes, often via DevOps, integration teams, or application admins. They accumulate privileges in minutes through iterative testing and troubleshooting, not over months of role design, and can execute thousands of actions in the time it takes to process a single ticket‑based review.
Without a unified, policy‑driven control plane that treats AI agents and other non‑human identities (NHIs) as first‑class citizens, organizations cannot demonstrate least privilege, SoD compliance, or alignment with business purpose and risk appetite. This is the central thesis of AI Governance: When AI Becomes an Identity, and it is made concrete for ERP finance flows in How to Govern AI Access to ERP and Financial Systems
.
1.2 Non‑human identity taxonomy
The second challenge is that “AI access” spans several distinct categories of non‑human identity types. In SOX‑governed Oracle, SAP, Workday, and SaaS landscapes, non‑human identities typically fall into several categories:
- AI agents and copilots (for example, Oracle AI Agents, SAP Joule, Microsoft Copilot) that chain actions across systems, draft or execute transactions, and accumulate toxic privilege combinations at machine speed, often scoped to a project, business function, or use case.
- RPA bots that are frequently over‑provisioned to avoid runtime failures, with broad access to financial and operational processes, but rarely subject to the same rigor of recertification as human users.
- Integration service accounts that connect ERP to SaaS, banks, data platforms, and custom apps, typically with persistent, high‑privilege access tied to interfaces rather than individuals.
- API keys and OAuth clients that represent long‑lived tokens associated with applications or services, widely distributed in code repositories and configuration files, and often lacking clear ownership and business‑purpose metadata.
- Scheduled jobs and batch accounts that run unattended background jobs with elevated rights for posting, reconciliations, and data loads, and are highly prone to silent privilege creep as processes evolve.
Each category requires explicit policy definitions, lifecycle controls, and evidence models if enterprises are to keep AI‑driven activity within intended risk boundaries.
1.3 Why legacy tools fail
The third challenge is that legacy IAM and IGA tools were never built for ERP‑deep, AI‑driven access patterns. They were designed to answer “who can log in to which application?” and “who owns which role?”, not “which identity—human or AI—can execute which high‑risk transactions across Oracle, SAP, Workday, and SaaS?”
This gap manifests in several ways:
- IAM/IGA tools track users and roles, not ERP transaction codes, Oracle function‑security hierarchies, SAP authorization objects, or Workday domain and business‑process security, which are mapped directly to SoD risk.
- Ticket‑based provisioning moves at human speed while AI agents accumulate entitlements and transact at machine speed, outpacing manual risk checks and approvals.
- Single‑system SoD analyzers cannot detect cross‑system violations where an AI identity originates on one platform and approves, posts, or settles in another.
- Most tools lack concepts for business purpose, risk tier, and data‑access scope for non‑human identities, making it impossible to prove that AI stayed within its intended scope in a way auditors will accept.
SafePaaS positions itself explicitly as a federated identity governance control plane above IAM/IGA, as outlined in Identity Governance vs Identity Access Management: Key Differences. For AI‑specific access risk, this distinction is extended in AI Has Given You Two New Problems – And Identity Governance Is the Only Place They Meet, which frames AI agents as a visibility and control gap that only an identity‑centric plane can close.
1.4 Governance principle
A leading practice is to treat AI agents as governed identities, not just application features—with accountable owners, documented business purposes, scoped entitlements and data access, and a measurable risk posture.
Translating this into controls means designing governance that looks and feels familiar to audit:
- A named individual or team is accountable for each AI identity’s lifecycle, policy alignment, and certifications.
- There is explicit documentation of what the AI is authorized to do, which systems and datasets it may touch, and which controls it must respect.
- Entitlements are designed and tested for least privilege, with SoD evaluated across all connected applications.
- Risk scoring and monitoring thresholds reflect the identity’s reach into financial reporting and regulated data.
SafePaaS operationalizes this principle as policy‑based, federated identity governance that applies the same rigor to AI and non‑human identities as to high‑risk human roles, as described in Identity Governance for Business‑Critical Apps.
2. Target environment and audit profile
This approach is built for complex, SOX‑governed ERP and SaaS estates.
2.1 Typical ERP and SaaS landscape
Organizations that feel AI identity risk first tend to share a common footprint:
- Regulatory context: SOX or SOX‑equivalent frameworks, often with global operations and complex consolidations.
- ERP core: Oracle E‑Business Suite, Oracle ERP Cloud, SAP ECC, SAP S/4HANA, and/or Workday Financials and HCM—often in combination after M&A or regional deployments.
- Business‑critical SaaS: ServiceNow, Salesforce, Coupa, Ariba, Kyriba, Concur, and others tightly integrated with the ERP core to enable end‑to‑end financial and operational flows.
- Identity fabric: Hybrid/multi‑cloud IAM with Entra ID/Azure AD, Okta, and legacy directories; one or more HR systems of record; and residual spreadsheet‑driven access reviews where IGA does not reach.
SafePaaS’s ERP and SaaS specialization is outlined in its Complete Access Governance Platform, in the Oracle‑focused overview Audit‑Proof Your Oracle ERP Cloud – Access Governance Strategies, and in the architecture guide Inside the SafePaaS + Oracle ERP Architecture: Security Context and Data Flows.
2.2 Audit posture
These enterprises operate under mature but human‑centric testing regimes. They face:
- Recurring SOX ITGC testing across logical access, change management, and computer operations.
- IT Application Control (ITAC) testing in key financial cycles such as P2P, O2C, R2R, H2R, and Treasury.
- Increasing expectations for continuous, system‑generated evidence of control effectiveness, rather than ad‑hoc screenshots and spreadsheets.
AI adoption is already ahead of most control designs. AI is being embedded into financial and procurement processes, often without explicit extensions of ITGC and ITAC design to non‑human identities. This creates a gap between how systems now operate and how controls were originally documented and tested, exposing organizations to avoidable findings and re‑work—an issue SafePaaS addresses in How CISOs Are Replacing Legacy IGA with Policy‑Based Access Governance. For SOX‑focused teams, these themes are expanded in ITGC SOX: The Basics and 6 Critical Best Practices for 2026, which explicitly calls out AI and non‑human identities as part of the ITGC landscape.
2.3 ITGC vs. ITAC – why both matter
Effective AI access governance must span both foundational IT controls and embedded application controls:
- ITGC: access management, change management, computer operations.
- ITAC: application‑embedded controls such as three‑way match, approval workflows, posting controls, and period‑end restrictions.
AI agents and other non‑human identities can undermine both layers if not explicitly governed. They can:
- Interact with or circumvent ITACs by originating and approving the same transaction.
- Bypass expected approval chains if granted inappropriate entitlements.
SafePaaS governs identities executing across both layers and maps SoD rules to the financial cycles in which ITAC operates, so AI‑related access risk is visible in the same context auditors use to assess financial‑statement impact.
3. Reference architecture for AI access governance
AI identity governance is most effective when deployed as a unified control plane, not as another siloed system.
3.1 SafePaaS as the AI governance control plane
SafePaaS provides a single, policy‑based platform that sits above existing IAM/SSO and below ERP and SaaS applications, acting as a federated identity and access‑governance control plane. This design centralizes policies and analytics without disrupting domain‑specific role models or configurations, and aligns with the federated model described in SafePaaS’s federated identity‑governance announcements.
For Oracle teams, this three‑layer control model is described in concrete terms in Inside the SafePaaS + Oracle ERP Architecture: Security Context and Data Flows, and is the foundation underlying the patterns in the AI Governance content hub.
The control plane is built on four main elements:
- Identity sources – HR systems (for example, Workday HCM, SuccessFactors), directories (AD/Entra), existing IGA platforms, and manual onboarding for non‑human and external identities.
- SafePaaS policy engine – an ERP‑aware SoD rule library for Oracle, SAP, Workday, and SaaS; risk classification; policy simulation; preventive enforcement; continuous monitoring; certification campaigns; exception workflows; and an audit‑evidence store.
- ERP/SaaS connectors – integrations with Oracle E‑Business Suite and ERP Cloud, SAP ECC and S/4HANA, Workday, ServiceNow, Salesforce, Coupa, Ariba, Kyriba, Concur, and others to ingest entitlements, transactions, and configuration.
- Provisioning targets – roles, responsibilities, security groups, API credentials, OAuth clients, and background job accounts governed through policy‑driven workflows rather than ad‑hoc steps.
3.2 Where AI agents and other non‑human identities fit in the lifecycle
AI identities should follow the same disciplined lifecycle as high‑risk human users. SafePaaS extends the identity lifecycle to explicitly include AI and non‑human identities alongside humans:
- Intake: registers each AI use case with an owner, business purpose, target systems, data scope, and risk tier, creating a unified catalog of agents, bots, service accounts, and integrations.
- Policy evaluation: simulates proposed entitlements against the SoD rule library and access policies before provisioning, preventing toxic combinations rather than only detecting them after the fact.
- Approvals and enforcement: risk‑aware workflows route requests based on risk tier—low‑risk changes to system owners; higher‑risk or SoD‑conflicting requests to control owners, security, or the CISO’s delegate.
- Provisioning: creates scoped roles and technical accounts in ERP/SaaS and registers credentials/API keys in vaults, with SafePaaS maintaining the authoritative mapping between AI identity, underlying accounts, and entitlements.
- Monitoring: continuously scans SoD, sensitive access, and high‑risk transaction activity for AI identities; detects anomalies and privilege creep; surfaces alerts and dashboards for control owners.
- Certification and decommissioning: includes AI identities in the same access‑certification campaigns as human users, and revokes roles, accounts, keys, and tokens across systems from a single workflow.
This lifecycle mirrors the phased approach defined in AI Governance: When AI Becomes an Identity and directly addresses the exposures highlighted in Top 5 AI Access Risks for CISOs and How AI Governance Closes the Gaps.
3.3 SoD rule library and governance
Segregation of Duties needs to be as cross‑system and AI‑aware as the processes it protects. SafePaaS maintains a multi‑ERP and SaaS SoD rule library that spans P2P, O2C, R2R, H2R, Treasury, and cross‑application combinations aligned to real‑world business flows, as well as cross‑application testing guidance in Cross‑Application Testing – Segregation of Duties. These same cross‑application SoD patterns underpin AI‑aware conflict design in federated governance, as discussed in Federated Governance for AI Identities: Closing the 92% Visibility Gap.
Key aspects:
- System‑specific depth: Oracle function security, data roles, and seeded roles; SAP transaction codes, authorization objects, and field‑level restrictions; Workday domain and business‑process security; SaaS‑specific entitlements.
- Governance: rule version‑control with change history aligned to ERP patch cycles, regulatory changes, and audit findings, so SoD analysis reflects current reality.
- Ownership: each rule maps to a control owner and documented business rationale, and customers can extend the library with custom and cross‑system rules tailored to their risk appetite.
4. Joiner–Mover–Leaver lifecycle patterns for AI agents and other non‑human identities
Joiner–mover–leaver controls must explicitly cover non‑human identities.
4.1 Joiner – onboarding AI identities
Onboarding is the best chance to enforce least‑privilege access for AI. During AI identity onboarding, SafePaaS collects and enforces a consistent set of intake attributes:
- Owner: the accountable person or team who receives certifications and owns exceptions.
- Business purpose: a clear description of what the AI is authorized to do and where its scope stops.
- System and data scope: target systems, company codes, ledgers, cost centers, modules, and data‑classification policies where applicable.
- Risk and entitlements:
- A risk tier (low/medium/high/critical) that drives approval routing, monitoring thresholds, and certification cadence.
- A technical‑account map recording the underlying service accounts, API clients, OAuth tokens, and jobs associated with the AI identity.
- An entitlement baseline defining proposed roles and privileges, evaluated with SoD simulation across all connected systems before approval and provisioning.
4.2 Mover – scope changes and re‑evaluation
Treat every AI scope change as a governance event:
- Any new company codes, modules, datasets, or SaaS integrations trigger a full SoD simulation on the cumulative entitlement set, not just the delta, to catch latent conflicts.
- Unused roles identified via inactivity analytics are flagged for cleanup and deprovisioning, reducing over‑privilege and attack surface.
- Major system upgrades (for example, SAP ECC→S/4HANA, Oracle EBS→ERP Cloud, Workday re‑implementations) trigger re‑inventory and validation of AI entitlements against updated rule libraries.
4.3 Leaver – decommissioning AI identities
Decommissioning must be deliberate to avoid orphaned, powerful AI access:
- Triggers: project closure or use‑case retirement, owner departure, or extended inactivity.
- Centralized revocation: automatic revocation of roles, technical accounts, and credentials across all connected systems from a single workflow.
- Auditability: every revocation event is timestamped, attributed, and fully auditable for SOX and internal audit testing.
These JML patterns are also the fastest way to close Shadow‑AI exposures described in AI Has Given You Two New Problems – And Identity Governance Is the Only Place They Meet, where non‑human identities proliferate outside standard lifecycle controls. That ties this “governed NHIs” narrative back into the Shadow‑AI / visibility‑gap cluster.
5–7. Oracle, SAP, Workday, and SaaS control examples
Sections 5, 6, and 7 in your draft (Oracle, SAP, Workday/SaaS examples) are already strong and concrete. To align with the rest of the cluster, weave in:
- Cross‑references to How to Govern AI Access to ERP and Financial Systems whenever you describe GL/AP/PO/credit‑control examples.
- References to Governing Machine Identities and AI Agents with AI Governance: A New Revenue Control when you tie AI controls to cash leakage, audit cost, and close‑cycle impact.
- Links to relevant SaaS content (for example, PeopleSoft, TRIRIGA, or other SaaS‑specific articles) where you mention those platforms.
The patterns themselves (AI can draft but not post; propose but not approve; recommend but not execute) already align with SafePaaS’s blog guidance and do not need structural changes.
For a deeper dive into how this pattern is implemented in Oracle ERP Cloud and E‑Business Suite, see Inside the SafePaaS + Oracle ERP Architecture: Security Context and Data Flows
.
8. Continuous monitoring, detection, and audit evidence
Continuous, AI‑aware monitoring is what turns static controls into living governance. SafePaaS unifies continuous access‑risk analytics with activity‑level monitoring for AI agents and other NHIs, so policy violations surface and get resolved immediately.
8.1 Monitoring and detection
Monitoring must explicitly recognize AI agents and other non‑human identities as clearly as it recognizes human ones:
- Configurable SoD and access‑risk analyses across Oracle, SAP, Workday, and SaaS, with AI identities first‑class in the inventory.
- Privilege‑creep detection on any new role assignment that creates or worsens a SoD violation, with workflow‑driven remediation.
- High‑risk transaction monitoring for AI—FI postings, vendor changes, payment releases—matched against approved business purpose and risk tier.
- Anomaly detection on time, volume, and system scope for AI activity, surfacing deviations for review.
8.2 Audit evidence and metrics
AI access must be as auditable as human access. SafePaaS acts as a unified evidence store for AI identity governance, capturing:
- Certification‑campaign records
- SoD violation logs and exception documentation
- JML audit trails
- Alert logs and reviewer decisions
Key KRIs and KCIs for AI identities include:
- Percentage of AI/NHI identities with open SoD violations
- Percentage inactive for more than 90 days
- Percentage of AI access certifications completed on time
- Average time to remediate AI‑related SoD violations
- Percentage of AI leaver events with same‑day revocation
These metrics support board‑level and regulator‑facing AI‑risk reporting and show progress over time, complementing identity and audit content such as Identity Access Governance in Auditing and Reporting. They also map directly to the AI‑related ITGC expectations described in ITGC SOX: The Basics and 6 Critical Best Practices for 2026 and to the risk scenarios outlined in Top 5 AI Access Risks for CISOs and How AI Governance Closes the Gaps.
9. Implementation approach
A phased rollout lets you tighten AI access quickly without rebuilding everything. SafePaaS accelerates implementation with a phased approach that builds on existing identity and controls investments:
- Phase 1 (4–6 weeks): discover and classify AI identities, technical accounts, service accounts, API keys, and RPA agents across Oracle, SAP, Workday, and key SaaS; assign owners and risk tiers.
- Phase 2 (6–8 weeks): deploy and tailor the SoD rule library, define AI‑specific policies, configure JML workflows for human and non‑human identities, and run a baseline SoD assessment to prioritize remediation.
- Phase 3 (4–6 weeks): connect IAM/SSO and ITSM, automate provisioning and certifications, onboard auditors and control owners to dashboards and evidence exports, and launch the first unified certification campaign covering AI and human identities.
- Phase 4 (ongoing): tune monitoring thresholds and cross‑system SoD rules, refine AI‑specific KRIs/KCIs, expand coverage to additional SaaS applications, and run quarterly certifications aligned with the SOX testing calendar.
This phased path mirrors the roadmap in How to Govern AI Access to ERP and Financial Systems and provides the identity‑governance execution layer for the challenges outlined in AI Has Given You Two New Problems – And Identity Governance Is the Only Place They Meet
10. SafePaaS views and reports
Clear, role‑specific views make AI identity governance operational for everyday users:
- Operational teams:
- AI identity intake forms capturing owner, business purpose, system and data scope, risk tier, technical‑account map, and proposed entitlements.
- SoD simulation views showing pre‑provisioning impact analysis with violations flagged before grants, plus side‑by‑side comparisons of human and AI identities.
- SAP SoD detail views highlighting AI identities with T‑code conflicts at the authorization‑object level across P2P, O2C, and FI, including drill‑downs into roles and mitigating controls.
- Risk and audit teams:
- Cross‑system SoD dashboards presenting SAP–Coupa, SAP–Salesforce, and other cross‑application violations with remediation status and rule‑to‑process mapping.
- Oracle/SAP/Workday certification views showing AI identities included in campaigns with attestation decisions, comments, and exportable evidence.
- Monitoring panels highlighting AI privilege‑creep or high‑risk transaction alerts with full context and reviewer disposition.
- Exception workflows and emergency‑access logs providing detailed, auditable records of exceptions and elevated‑access sessions.
11. Why SafePaaS
SafePaaS is the identity‑centric control layer where AI governance actually happens, not just gets documented. It goes beyond “who can log in” to which identities—human or non‑human—can execute which high‑risk transactions, in which system, under which policy.
Key differentiators:
- A single, ERP‑aware rules and analytics engine spans Oracle, SAP, Workday, and SaaS, exposing cross‑application SoD and access risks legacy IAM and IGA never see.
- Non‑human identities follow a full lifecycle—discovery, intake, policy evaluation, JML, continuous monitoring—so AI agents, bots, service accounts, and API keys are governed with the same rigor as your riskiest human roles.
- Preventive SoD simulation, cross‑system SoD, and a unified evidence store turn certifications, exceptions, and AI activity into continuous, audit‑ready proof that every agent and service account stays within defined risk boundaries.
For a broader strategic context, see:
