SAP AI Agent · Security · SU53 · Roles Configurable
Design scenario · how the agent is configured to work
Why it matters
A user sends an SU53 screenshot, security tries to work out which role should grant it, and the quick fix is often a broader role than the user needs.
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 an SU53 screenshot, a ticket or an authorization trace.
Searches existing roles that grant exactly what's missing.
Checks the proposal against your policy before the owner sees it.
Assigns the role or applies the role change after approval.
Worked example
A buyer who now covers plant 1100 can't change purchase orders there. Here is what the agent finds before anyone opens role maintenance.
The same role for plant 1100 grants exactly the missing check. No role change is needed.
| Check | Result | Why |
|---|---|---|
| Matching roles | 2 found | Z_MM_PO_CHANGE_1100 and Z_MM_BUYER_ALL |
| Proposed | Z_MM_PO_CHANGE_1100 | Narrowest role that grants the check |
| Not proposed | Z_MM_BUYER_ALL | Grants every plant; broader than needed |
| SoD | No conflict | With the user's current roles |
| Validity | Open-ended | Manager to confirm if the cover is temporary |
The role is assigned only after the role owner approves. The broader role was considered and not proposed because it grants more than the user needs.
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 M. Patel (Role owner, purchasing) to approve role Z_MM_PO_CHANGE_1100 for A. Chen, asked Mon 2 Nov at 11:46.
A reminder goes out at 15:46 today. The user can't change POs for plant 1100 until then.
| Step | Owner | Status |
|---|---|---|
| Failed check analysed | Agent | Done |
| Business need | Purchasing manager | Confirmed |
| Role assignment | M. Patel · Role owner | Waiting |
| Update ticket and user | Agent | Scheduled |
Assign role Z_MM_PO_CHANGE_1100 to A. Chen? It grants purchase order changes for plant 1100 only, with no SoD conflict against her current roles.
Illustration of how this agent's cases appear on the Artificio platform · names and values are fictional
Capabilities
Every request gets the narrowest fix that policy allows, with a recorded decision.
Ownership
You name role owners and approvers. 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 assigning a pre-approved role from the same family for another plant, when the manager confirms, 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.
| Authorization checks | SU53 data and authorization traces |
|---|---|
| Users | Current roles and validity |
| Roles | Role menus and authorization values |
| Policy | Your SoD ruleset and role design rules |
| Role assignments | BAPI_USER_ACTGROUPS_ASSIGN, after approval |
|---|---|
| Role changes | Drafted for security; applied through your change process |
| Tickets | Diagnosis and outcome written back |
| Responses | Every SAP response recorded on the case |
ScopeThe exact interfaces, objects and fields in scope are confirmed for your SAP release and deployment during technical discovery. S/4HANA Cloud Public Edition is reviewed case by case, and some landscapes may need additional configuration.
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 roles in scope, role owners, SoD ruleset and approvals.
Run real tickets in shadow mode: the agent proposes, security decides.
Review the four measures, then add modules and pre-approved role families.
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 authorization ticket process with our team, and see how a similar agent works on the Artificio platform.
Request DemoScope a pilot on one module's authorization tickets in your SAP QA or sandbox system, with the four measures agreed up front.
Discuss an SAP pilot
