SAP AI Agent · Basis · Security · Users Configurable
Design scenario · how the agent is configured to work
Why it matters
New starters wait days for SAP access, movers keep roles they no longer need, and leavers stay active long after they've gone.
How it works
The same four steps as every Artificio agent. The agent does the research and the paperwork; your teams make the decisions.
From a request form, a ticket or an HR joiner, mover or leaver event.
Builds the role set and checks it against your access policy.
Routes the request to the manager and each role owner.
Creates, changes, locks or removes the user once approved.
Worked example
A manager requests access for a new buyer starting next week. Here is what the agent proposes before anyone opens user maintenance.
Creating vendors together with creating purchase orders is a segregation-of-duties conflict under your policy.
| Role | Proposed | Why |
|---|---|---|
| Z_MM_PO_CREATE_1000 | Assign | Job role: buyer, plant 1000 |
| Z_MM_PO_DISPLAY | Assign | Job role |
| Z_MM_INFO_RECORD | Assign | Job role |
| Z_MM_REPORTS | Assign | Job role |
| Z_MD_VENDOR_CREATE | Not assigned | Conflicts with PO creation; vendor creation stays with master data |
| User validity | From 9 Nov | Start date from the request |
The user is created with the four job-role roles once the role owner decides on the extra request. No conflicting role is assigned without a recorded decision.
Design scenario · names and values are fictional and depend on your SAP configuration
Inside the platform
The case shows who it is waiting for, what happens next, what the agent checked and exactly what each person is approving.
Waiting for L. Kim (Role owner, master data) to decide on the request for vendor creation, asked Mon 2 Nov at 10:22.
A reminder goes out tomorrow at 10:22. The user is needed on 9 Nov.
| Step | Owner | Status |
|---|---|---|
| Job-role roles | A. Chen · Manager | Approved |
| Vendor creation · SoD conflict | L. Kim · Role owner | Waiting |
| Create user in client 100 | Agent | On hold |
| Notify new user | Agent | Scheduled |
M. Garcia asked for vendor creation in addition to buying. Together with PO creation this breaks your SoD policy. Reject, or approve with a mitigating control?
Illustration of how this agent's cases appear on the Artificio platform · names and values are fictional
Capabilities
Every request goes through the same policy checks and approvals, whoever asks.
Ownership
You name the approvers for each kind of request. Whoever answers first decides, and anything unassigned goes to the security lead.
Owners, rules and tolerances are configured to your organization and agreed for each deployment.
Controlled autonomy
The agent proves itself on your real work before it writes anything to SAP. The platform measures how often your people agree with it, so you decide when to give it more room, case type by case type.
The agent proposes every action but writes nothing to SAP. Your people decide, and each answer counts toward the agreement rate.
The required owners approve. The agent acts in SAP only when the last approval lands.
For case types you explicitly configure and approve, such as locking users on their last day from a confirmed leaver event, the agent acts on its own and reports back.
Governed agent runtime
What makes this agent different is its configuration: its instructions, the tools it may use and the policies it works under. Reviewers, approvals, versions and audit work the same way for every agent you add.
Decisions go to named owners or authorized teams, with reminders, and every email links back to the case.
Gathering data is kept separate from changing SAP. Action tools are controlled and can require human approval before they run.
Versions can't be edited, and each case keeps the version it started with, so a change never alters work in progress.
Recreations of Artificio platform screens
What we measure
Every pilot tracks the same four measures from day one, so the business case comes from your data, not ours.
For SAP teams
The agent reads and writes data through supported SAP interfaces, without modifying standard SAP objects and without replacing your existing governance.
| Users | Existing users, roles and validity |
|---|---|
| Roles | Role definitions and authorizations |
| HR events | Joiners, movers and leavers, where connected |
| Policy | Your SoD ruleset and critical access list |
| Users | BAPI_USER_CREATE1, BAPI_USER_CHANGE, BAPI_USER_LOCK |
|---|---|
| Roles | BAPI_USER_ACTGROUPS_ASSIGN |
| Notifications | Welcome and change notices to the user |
| Responses | Every SAP response recorded on the case |
ScopeUser management works differently in SAP ECC, S/4HANA on-premise and S/4HANA Cloud, where identity and access management has its own interfaces. The systems, clients and interfaces in scope are confirmed in technical discovery. Initial access follows your policy, such as single sign-on.
Pilot approach
A focused pilot in your QA or sandbox system proves the agent on your own data before anything reaches production.
Review SAP edition, interfaces, authorizations and representative data.
Agree the systems, job roles, SoD ruleset and approvers.
Run real requests in shadow mode: the agent prepares, security applies.
Review the four measures, then add systems, request types and approved automation.
Frequently asked questions
Security & compliance
ISO 27001:2013 certified, SOC 2 Type 2 compliant, GDPR and HIPAA ready. Every agent action is logged and auditable, and SAP credentials stay in the platform's integration accounts.
See it working
Talk through your user provisioning and access request process with our team, and see how a similar agent works on the Artificio platform.
Request DemoScope a pilot on one system and one request type in your SAP QA or sandbox system, with the four measures agreed up front.
Discuss an SAP pilot
