How do you monitor an AI agent in SAP?

Machine speed breaks after-the-fact review

Most SAP teams review privileged, service and technical accounts the same way they always have: export a log, open it in a spreadsheet, and read. Monthly, perhaps. After an incident, perhaps. When the auditor asks.

AI changes the scale of that job. Agents and scripts now talk to SAP directly - OData calls, RFC reads, GUI automation - running under service accounts, often overnight, at hundreds of events per minute. Most of it is exactly what you would expect. A discovery script reads table structures; a monitored account runs its routine jobs.

The problem is the rest. The one read that touched a sensitive table. The one action outside the account's normal pattern. In a log of thousands of events, that single item is invisible to the human eye - and by the time a manual review finds it, the trail is weeks cold.

There is a second problem underneath it: attribution. When an agent runs under a person's account, an auditor's first question is not "read or write?" - it is "who is accountable for that session?" A personal user running a script blurs segregation of duties and pins any error on someone who never actually typed anything.

Banning it does not make it stop

There is a tempting answer to all of this: do not let AI or scripting near SAP at all. It does not work. People are already automating the parts of their job they dislike most - the manual export, the copy into Excel, the same five clicks a hundred times a day. Close the sanctioned path and they take the unsanctioned one: a personal user, a local script, a tool on a laptop that IT never sees.

So the choice was never AI in SAP - yes or no. It is monitored, or shadow. A blanket ban does not remove the risk; it removes your visibility of it, and pushes the activity onto exactly the personal accounts that blur attribution the most.

And it is getting easier, not harder. Turning on SAP GUI Scripting is a single profile parameter (sapgui/user_scripting = TRUE); a small COM bridge lets an assistant drive a live SAP session; and practitioners already publish agents that open a transaction, read an ALV grid, and produce an Excel analysis in a couple of minutes.

It is also going native. SAP's own Joule assistant now embeds in SAP GUI for Windows, with frontend actions that read the current screen and run GUI scripts directly - AI operating SAP transactions as a vendor-supported feature, not a workaround. The capability is arriving whether or not your controls are ready for it.

A working agent, in one plain-language request

This is not theoretical. A practitioner points an assistant at a running SAP session over COM and types something close to plain English: list the connections, open the error monitor, read the messages, build me an Excel with the likely fixes. Two minutes later there is a ranked spreadsheet - message class, count, severity, the transaction to go and fix each one - for a migration run with fourteen thousand posting errors that would have cost a consultant an afternoon. People are publishing these walkthroughs openly, with the setup steps attached.

Today most of these agents are deliberately careful: read-only, running under the person's own session and permissions, no postings. But read the honest engineering notes that come with them and the trajectory is clear. The primitives - navigate, read a field, parse a grid, discover a screen - already drive most reporting transactions. What is still missing (system-specific field IDs, grid pagination, multi-screen posting flows) are gaps in reliability, not in intent. The next version wants deeper screen discovery, and eventually write-back.

That is the point where the control question stops being optional - and, conveniently, where read-only today gives you a calm window to put the account, the policy and the evidence in place before write-back arrives.

Review the exceptions, not the log

The fix is not more review. It is less - aimed at what actually matters.

Instead of reading everything an account did and judging it after the fact, you define upfront what the account is allowed to do. The system then surfaces only the activity that falls outside that line. Review stops being line-by-line archaeology and becomes exception handling: five things to look at, not five thousand.

Monitored accounts and a living policy

smartGRC watches privileged, service and AI accounts against a policy - a white list and a black list of transactions, scoped to an account or a set of accounts. When something falls outside the policy, the process runs itself:

The workflow above translates directly to how smartGRC handles a live SAP session. The diagram below shows what happens on every transaction the AI agent runs - from the initial call, through the policy check, to the three ways an off-list action can be resolved. The dashed green loop back to the policy is the key detail: each decision the owner makes teaches the boundary, so tomorrow's review is smaller than today's.

Read left to right: the AI agent calls a transaction, smartGRC checks it against the policy in flight, and either lets it pass silently or raises an exception the moment it sees it. That exception lands on the owner - not next week, not in a monthly report. From there, three outcomes: whitelist (the transaction was legitimate and joins the rules for next time), justify (a one-off, explained and documented for the audit trail), or block (the account cannot run this again until someone signs off). Same interface, same evidence, whichever way the owner decides.

That fourth step is the one that compounds. The boundary you enforce is never a stale document - it is a rule set that gets more accurate every time it is used. And it runs in two modes that cover the whole picture:

What passes, what gets flagged

Take a service account used by an AI agent to explore and report on SAP data. The same account, the same "read-only" label - and three very different verdicts, decided by the policy, not by a reviewer's memory:

The whitelisted reads never reach a human. The exceptions land on the owner the same day - justify, or add as a rule. The black-list entries are stopped outright. The reviewer sees a handful of items, not the thousand that were fine.

Easy to miss, expensive to explain

Each of these looks unremarkable in a raw log, sitting between hundreds of harmless reads. That is exactly why they need to surface on their own.

A boundary the system enforces - with an owner, a real-time exception, and a full trail for the auditor - is. That is the difference between having an AI usage policy and being able to prove it holds.

---

Related reading