SAP Agents Are Arriving. The Tool That Governs Their Access Comes Later.
SAP says agents cannot exceed the rights of the person who asked. The dates, four questions the wording leaves open, and what to fix before you switch one on.
Imagine it is Friday, 4:55 p.m. An accounts payable clerk asks her assistant to "clear the blocked invoices before the weekend".
The assistant has her login. And her login can release payment blocks, because three years ago she covered for a colleague on leave and nobody removed the access afterwards.
The assistant is fast, polite and tireless. By 5:10 it has released a lot of invoices.
Was every one of them safe to release? The assistant did nothing it was not allowed to do. That is exactly the problem.
This is the question behind a promise SAP made at SAP Connect on 6 October. Let's read it carefully, because it is a strong promise, and the details matter.
The short version: SAP says agents cannot exceed the authorizations of the person who asked. True. But those authorizations are only as tight as your roles, and the dedicated tool for governing agent access is planned for 2027.
The promise, in SAP's words
SAP's innovation guide says its new governance assistants "extend existing identity and GRC controls to AI directly, so agents cannot exceed defined limits or act beyond the authorizations provided by the employee who initiated the request."
The press release adds that Joule Assistants execute work "using established data, authorizations and audit trails", and that customers control the level of autonomy. SAP also points to an agent inventory (SAP AI Agent Hub in SAP LeanIX) and says its governance architecture is independently certified to ISO/IEC 42001.
That is a sensible design. Agents are not given new superpowers. They borrow the user's.
The dates
- October 2026: SAP says general availability for the new Autonomous Suite assistants and agents "starts in October", product by product.
- Q4 2026 (planned): the Governance Assistant. It connects your existing GRC solutions and surfaces risk and control signals across systems. SAP says it adds a layer and does not replace your GRC investments.
- Q1 2027 (planned): the Access Governance and Security Assistant. It extends identity governance to cover autonomous agents alongside traditional users, applying consistent access controls to every actor.
Read the order again. Agents begin to arrive in October. The assistant built to govern agent access is planned for the first quarter of 2027.
These are SAP's plans, and plans move. But the order is worth noticing.
"Within the user's rights" is a ceiling, not a fence
Here is how I think about it. There are three ceilings on what an agent can do.
- The authorization ceiling: what the user's roles allow.
- The autonomy ceiling: what you configured the agent to do on its own.
- The policy ceiling: what your GRC and separation-of-duties rules forbid.
SAP's promise is about the first ceiling. It is only as low as your roles are tight.
Ask a GRC team how many people carry more access than their job needs. Many will tell you it is among the most common findings in access reviews. People change jobs, cover for colleagues, run projects. Access accumulates.
A person with too much access is a risk you already carry. But a person uses it a few steps at a time, with pauses, with a gut feeling that says "this looks wrong". An agent uses the same access at machine speed, across many steps, with no gut feeling beyond the rules you gave it.
Same rights. Bigger blast radius.
Four questions the wording leaves open
These are questions, not accusations. I could not find answers to them in SAP's published pages, so they are worth asking in your next call.
1. Who is "the employee who initiated the request" when nobody did?
SAP talks about continuous monitoring. In its Moody's partnership, for example, Joule Agents will "flag supplier risk signals and surface alternatives". If an agent starts work because of an event, not a person's request, whose authorizations apply?
2. Do separation-of-duties checks see the agent's whole session?
Classic SoD asks whether a user holds conflicting roles. An agent can chain many steps in minutes. If your rules look at roles but not at what happened in one session, they may miss a combination that is technically permitted. SAP says the Governance Assistant correlates behavior across systems. Test that with your own rules.
3. Is the agent an identity?
The Q1 2027 assistant "extends identity governance to cover autonomous agents". That wording suggests agents become governed identities of their own. Until it lands, how are agents identified in your access reviews?
4. Can an auditor replay it?
SAP says audit trails exist. Ask what exactly is recorded: the request, the plan, every call, every result. An audit trail that shows "the agent released 400 invoices" is much weaker than one that shows why, step by step.
What to do in the gap
Between October and Q1 2027, you are the guard. A practical order of work:
- Trim roles using real usage data. Remove access nobody uses. Start with finance, procurement and master data, where mistakes cost real money.
- Re-run SoD analysis on the roles agents are likely to inherit. Fix the conflicts you already know about. An agent will find them faster than an auditor.
- Define autonomy tiers on purpose. A simple ladder: answer, then draft, then act with approval, then act alone. Most processes should start at the second step.
- Keep a person on money and master data. Payments, vendor bank details, credit limits. A human approves, every time, and the approval is logged.
- Write down who can read the agent logs, and for how long they are kept.
- Prepare the stop button. How do you pause one agent, or all of them, in minutes? Who is allowed to press it? How do you roll back?
- Keep a register of agents. Name, owner, purpose, data it touches, autonomy tier.
The autonomy ladder, with examples
- Answer. "Show me blocked invoices older than 30 days." Nothing changes in the system.
- Draft. The agent prepares a release list for a person to review.
- Act with approval. The agent releases only after a named approver confirms each batch.
- Act alone. Only for low-value, reversible, well-tested tasks.
A rule of thumb: money, master data and access changes never go above "act with approval".
What a good agent audit record contains
If an auditor, or a very upset CFO, asks "what happened?", you should be able to answer from the record alone. That means capturing:
- who asked, when, and the exact request;
- the plan the agent made;
- every system call: which object, which values, which system;
- the result of each call;
- every approval, with who gave it;
- the final outcome, and which model and version produced the plan.
Ask SAP which of these its audit trails capture. Fill in the gaps with your own logging.
A 30-60-90 plan
- Days 1 to 30: list the roles that touch money and master data. List the agents you plan to use. Set autonomy tiers.
- Days 31 to 60: trim roles. Re-run SoD analysis. Agree what must be logged and for how long.
- Days 61 to 90: pilot with draft-only agents. Review the logs weekly. Run a stop-button drill.
- Q1 2027: compare SAP's Access Governance and Security Assistant with what you built. Keep what still adds value.
The take
SAP is building the right guard. It is also sending the workers first.
That is not a scandal. It is how software usually ships. But it means the real safety of the next six months depends on boring things you control: clean roles, approvals and logs.
Do not wait for a tool to tell you who should be allowed to do what. Decide that yourself. The tool will be much more useful when you do.