The first RPA bot in most SAP landscapes was set up by the finance team with a spare dialog user and a password in a spreadsheet. The first AI assistant usually arrives the same way: a developer, an RFC user, a proof of concept that went well. Neither is a security incident. Both become one the day the bot does something it was never meant to do and nobody can say who owns it, what it was supposed to run, or whether this is normal. This article is about the governance loop that stops that from happening, and how Agent Lens runs it.
Step 1: declare what should exist
Governance starts with a register, the same way asset management does. In Agent Lens you declare each RPA bot, AI user and integration user with four things:
- An owner. A person or team who answers for it.
- A purpose. One sentence: "posts supplier invoices from the AP mailbox".
- What it is expected to run. The transactions, reports and function modules that belong to its job.
- Where it should log on from. The host or hosts it is allowed to come from.
Any user type can be registered, because an RPA bot is often a dialog user and an AI integration is often a communication user. You can register one by one, accept a suggestion from Agent Lens, or import a list from CSV or Excel when you already keep one.
Step 2: baseline each one
Once an agent is registered, Agent Lens baselines it from three read-only sources in SAP:
| Question | Where Agent Lens reads it | What it compares against |
|---|---|---|
| What did it run? | Workload statistics (ST03N): transactions, reports, function modules | The declared job |
| Where did it log on from? | Live terminal sessions and the Security Audit Log, including failed logons | The expected hosts |
| What can it do? | Roles, profiles, sensitive transactions, any-transaction access | Its own last baseline |
The third row is the one most teams miss. A bot's authorizations change when someone adds a role "to make the error go away". Agent Lens notices new roles, new critical access, SAP_ALL, or a new entry point the account has never used before, even when the bot's behaviour has not changed yet.
Step 3: watch for drift
Drift opens a finding. The patterns Agent Lens looks for are the ones that precede real incidents:
- An unexpected host, which usually means a credential has been copied somewhere it should not be.
- Unusual hours for an account that normally runs on a schedule.
- A spike in activity.
- Dialog logons by a machine user, meaning a person is using the bot's credentials interactively.
- New critical access, whether or not it has been used.
Findings can go to email, Microsoft Teams or your SIEM. Each one lands in front of a person with the evidence attached, and the decision ("accept change" or "investigate") is recorded with a reason. Nothing is changed in SAP by Agent Lens itself; the action, if any, is yours.
Step 4: recertify on a cycle
People get a user access review every year or two. Bots should too, and more often, because their owners change jobs and their purposes drift. Each registered agent in Agent Lens is recertified on a cycle you set (180 days by default). The owner confirms that the agent still exists, still does what it is registered for, and still needs the access it holds. Every confirmation is logged, which gives the auditor a control they can actually test.
Step 5: find the ones nobody declared
A register is only as good as its coverage, so Agent Lens also looks for users that behave like agents but were never declared: a bot-style name, a dialog user doing mostly RFC work, an account with hard evidence of integration use. Each one is surfaced as a suggestion with the evidence that triggered it. Then a person decides. Agent Lens never promotes an identity to "AI agent" on its own, and a "Not an agent" decision stays put no matter what a later run calculates.
The loop in one line
Read SAP, read-only. Classify by evidence. Resolve access. Check activity. A person reviews, with a reason. Findings and recertification. Then again next cycle. The SyntaAI Agent can also read Agent Lens results for you in plain English, for example "which integration users on PRD hold SAP_ALL?" or "what did our RPA bots run this week?", and it analyses and recommends while your administrators decide.
What this looks like in practice
An illustrative finding on a registered bot, as it appears in Syntasec:
SE16N from an invoice bot is exactly the kind of thing that is harmless nine times out of ten and the start of a data extraction the tenth time. The point of the loop is that someone looks, and that the looking is recorded.
Register your bots before the auditor asks you to
Agent Lens runs in your own SAP BTP subaccount against S/4HANA or ECC, read-only. Book a walkthrough and we will run it against one of your systems.
Frequently asked questions
What should be registered for an RPA bot or AI user in SAP?
An owner, a purpose, what it is expected to run (transactions, reports, function modules) and where it should log on from. Any user type can be registered, because an RPA bot is often a dialog user. Agent Lens lets you register one by one, from a suggestion, or by CSV or Excel import.
What does Agent Lens compare a registered agent against?
Three things, read-only from SAP: what it ran, from the workload statistics; where it logged on from, from live terminal sessions and the Security Audit Log including failed logons; and what it can do, meaning new roles, new critical access, SAP_ALL or a new entry point it never used before.
What counts as drift?
An unexpected host, unusual hours, a spike in activity, dialog logons by a machine user, or new critical access. Each opens a finding that can go to email, Microsoft Teams or your SIEM, and a person decides whether to accept the change or investigate, with a reason.
How often are registered agents recertified?
On a cycle you set, 180 days by default. The owner confirms that the agent still exists, still does what it is registered for, and still needs the access it holds, and every confirmation is logged.
Does Agent Lens find bots that were never registered?
Yes. It surfaces users that look like undeclared agents, such as a bot-style name, a dialog user doing mostly RFC work, or an account with hard evidence of integration use, each as a suggestion with the evidence. A person then decides; Agent Lens never promotes an identity to AI agent on its own.