Agent Lens

Every SAP system carries dozens to hundreds of users nobody logs on as: batch users, RFC and interface users, workflow and ALE users, and now RPA bots and AI assistants calling in over RFC or APIs. They often hold broad access, rarely get reviewed, and almost never have an owner on record. Agent Lens gives each one an identity, the evidence behind it, and a review trail.

What it finds

Agent Lens inventories every system (B), communication (C) and service (S) user of an SAP system and works out what each one most likely is from how it is actually used — not from its name alone:

• Background jobs — the user each job step runs as.
• RFC destinations — stored logon users, including destinations that point back to the same system.
• Workflow and ALE — workflow destinations and IDoc partner profiles.
• Name and user-group rules — yours to edit, and always weaker evidence than real usage.

Each identity is classified as a background-job, workflow, ALE/IDoc, RFC integration, system service, monitoring or API-client user — or left unclassified when the evidence isn't there. 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.

What each identity can do

For every identity, Agent Lens resolves the access it really holds: its valid roles (composite roles expanded), profiles such as SAP_ALL and SAP_NEW, the sensitive transactions it can start, any-transaction access, debug and replace, RFC, table and user-administration capabilities, and org levels exactly as written in the role. If something couldn't be read, it says “not read” — never zero.

Registered agents: declared, baselined, watched

You declare your RPA bots, AI users and integration users — any user type, because an RPA bot is often a dialog user — with an owner, a purpose, and what they are expected to run and where from. Register them one by one, from a suggestion, or by CSV/Excel import. Agent Lens then baselines each one and checks it against:

• What it ran — transactions, reports and function modules from the SAP workload statistics (ST03N).
• Where it logged on from — live terminal sessions and the Security Audit Log, including failed logons.
• What it can do — new roles, new critical access, SAP_ALL, a new entry point it never used before.

Drift opens a finding — unexpected host, unusual hours, a spike in activity, dialog logons by a machine user, new critical access — that can go to email, Microsoft Teams or your SIEM. Each registered agent is recertified on a cycle you set (180 days by default). Users that look like undeclared agents — a bot-style name, a dialog user doing mostly RFC work, a hard-evidence integration identity — appear as Suggestions for a person to register or dismiss.

The loop

Honest about what it saw

Agent Lens states the basis of every number: the data date, the window it covers, and when access was matched against your list of sensitive transactions rather than expanded in full. A source that wasn't read, a day the SAP workload collector didn't aggregate, or an audit log that isn't recording logons is named in the run — it never reads as “nothing found.” Not determined is not clear.

Read-only, on SAP BTP

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, and it never changes anything in SAP: reviews, registrations and findings live in Syntasec, and every decision lands in an append-only log.

Ask about it in plain English

The SyntaAI Agent can read Agent Lens results for you — “which integration users on PRD hold SAP_ALL?” or “what did our RPA bots run this week?” — from Claude or your own assistant. It analyses and recommends; your administrators decide. See how Syntasec stays open to the AI engine your policies allow, the wider Syntasec platform, or all the agents.