The users nobody logs on as. Who are they, and what can they do?

Open SU01 on any production system and filter for user types other than Dialog. You will find dozens, often hundreds, of accounts nobody has ever logged on as. Batch users, RFC and interface users, workflow and ALE users, monitoring users, and lately the RPA bots and AI assistants calling in over RFC or APIs. They hold broad access, they are rarely reviewed, and almost none of them have an owner on record. Agent Lens exists to give each one an identity, the evidence behind that identity, and a review trail.

The gap in the user access review

A normal user access review is built for people. A manager gets a list of employees and their roles, confirms or removes, and signs off. Non-dialog users do not fit that shape. Nobody "owns" BATCH_FI in the way a manager owns a team member. The RFC user behind an interface was created by a consultant during the implementation, and the destination it serves was renamed twice since. So they are skipped, cycle after cycle, while the roles they carry stay exactly as they were on go-live day.

Three things make that risky now rather than merely untidy:

• They are the broadest accounts on the system. Interface users are given SAP_ALL "temporarily" during an integration project more often than anyone admits, and the temporary part rarely happens.
• Machines now act like people. An RPA bot is usually a dialog user, because it drives the GUI. An AI assistant may reach SAP through RFC, OData or an MCP server. Either way, a non-human identity is running transactions a human used to run.
• Nobody checks what they actually do. A service user that was created for one interface can quietly be reused by a second and a third. The authorizations grow; the review never happens.

Evidence first, labels second

The tempting shortcut is to classify by name. Anything starting with RFC_ is an interface user, anything with BOT in it is a bot. Agent Lens treats naming rules as the weakest evidence it has, and lets you edit them, because the real signal is in how the account is used. It reads, read-only, from the places where usage leaves a trace:

1. Background jobs

   The user each job step runs as. An account that executes nightly job steps is a background-job user whatever its name says.

2. RFC destinations

   Stored logon users in RFC destinations, including destinations that point back to the same system. If a destination logs on as the account, it is an RFC integration user.

3. Workflow and ALE

   Workflow destinations and IDoc partner profiles reveal the workflow and ALE/IDoc users.

4. Name and user-group rules

   Your own conventions, applied last and marked as rule-based so nobody mistakes them for observed behaviour.

From that evidence each identity is classified as a background-job, workflow, ALE/IDoc, RFC integration, system service, monitoring or API-client user. When the evidence is not there, it is left unclassified. Every classification carries its confidence (hard, medium, rule-based, or set by a person) and the evidence rows that produced it. There is no opaque score to argue with, only rows you can check in SM37, SM59 or WE20 yourself.

What Agent Lens will never do on its own

Agent Lens never calls an identity an AI agent by itself. A non-dialog user without evidence stays a non-dialog identity. "Confirm as AI agent" and "Not an agent" are decisions a person makes, each recorded with a mandatory reason, and a "Not an agent" decision is never overturned by a later calculation. This is the same principle that runs through every SyntaAI agent: the software finds, classifies and proposes, and a person approves. Agent Lens goes one step further and refuses to even label the sensitive cases without a human in the loop.

What each identity can actually do

Knowing that an account is an interface user is only half the picture. Agent Lens resolves the access it really holds:

• Valid roles, with composite roles expanded to the single roles inside them.
• Profiles such as SAP_ALL and SAP_NEW.
• The sensitive transactions it can start, and whether it has any-transaction access.
• Debug and replace, RFC, table and user-administration capabilities.
• Organizational levels exactly as written in the role, so you can see that an interface user is scoped to one company code, or to all of them.

Where something could not be read, Agent Lens says "not read" rather than showing a reassuring blank. Not determined is a state, not a pass.

Honest about what it saw

Every number in an Agent Lens run states its basis: the data date, the window it covers, and whether access was matched against your list of sensitive transactions or expanded in full. A source that was not read, a day the workload collector did not aggregate, or an audit log that is not recording logons is named in the run. It never reads as "nothing found". For an auditor this is the difference between a control that can be relied on and a dashboard that happens to look green.

Where it runs

Agent Lens is part of Syntasec on SAP BTP. It runs in your own BTP subaccount, reads SAP over RFC through your Cloud Connector, and signs your team in through your XSUAA role collections. Nothing is installed in S/4HANA or ECC, no transports, and it never changes anything in SAP. Reviews, registrations and findings live in Syntasec, and every decision lands in an append-only log. It works with S/4HANA and ECC alike, which matters because the systems with the oldest, least reviewed service users are usually the ECC ones.