The fol­low­ing Util­i­ty Voice was authored by Marc Rosson, Com­mu­ni­ty Con­nec­tor at Utility.Community. For more SAP util­i­ties insights, sign up to receive ASUG’s free The Top­ic: Util­i­ties newslet­ter, and to get involved and keep up with the lat­est, join ASUG’s Util­i­ties Com­mu­ni­ty. Con­nect with SAP teams across the util­i­ties com­mu­ni­ty as they explore AI adop­tion, clean core, data strat­e­gy, and more at SAP for Util­i­ties, Pre­sent­ed by ASUG in San Anto­nio, Octo­ber 6 – 9, 2026.

Last month in this space, I argued that SAP’s Autonomous Enter­prise vision is the right move for util­i­ties pre­cise­ly because it puts gov­er­nance, secu­ri­ty, and per­for­mance at the foun­da­tion rather than treat­ing them as after­thoughts. The response from our com­mu­ni­ty was encour­ag­ing and pre­dictable. The most com­mon fol­low-up ques­tion, in one form or anoth­er, was this:

“That all sounds good. But who actu­al­ly secures an enter­prise where soft­ware agents are doing the work?”

It is exact­ly the right ques­tion, and it belongs square­ly in the cat­e­go­ry I’ve been call­ing the ques­tions we aren’t ask­ing. We have decades of mus­cle mem­o­ry for secur­ing sys­tems that humans oper­ate: role-based access, seg­re­ga­tion of duties, change man­age­ment boards, audit logs tied to a user ID and a badge num­ber. Every one of those con­trols assumes a per­son on the oth­er end of the transaction.

An autonomous enter­prise breaks that assump­tion. When an agent clos­es a work order, adjusts a billing account, or rec­om­mends a switch­ing plan, our secu­ri­ty mod­el has to answer ques­tions it was nev­er designed for: Who autho­rized this agent to exist? What rules gov­ern what it should be doing? Who is watch­ing what it actu­al­ly does? Where does it sit in the orga­ni­za­tion? And if it mis­be­haves, how do we shut it down?

The good news is that SAP’s answer to these ques­tions is tak­ing shape, and it is more com­plete than most of our com­mu­ni­ty real­izes. It comes in three lay­ers: a hard­ened oper­a­tional foun­da­tion that exists today, a pub­lished secu­ri­ty oper­a­tions pat­tern that con­nects SAP detec­tion into your enter­prise SOC, and an emerg­ing agent gov­er­nance stack that address­es the ques­tions above directly.

Lay­er One: The Foun­da­tion Most of Us Already Have

Before we talk about secur­ing agents, we should be hon­est about some­thing: many of the secu­ri­ty capa­bil­i­ties util­i­ties will need for the autonomous era are already part of the RISE with SAP oper­at­ing mod­el, and many of us have nev­er looked close­ly at them.

RISE is built on a shared secu­ri­ty respon­si­bil­i­ty mod­el. SAP Enter­prise Cloud Ser­vices (ECS) takes end-to-end respon­si­bil­i­ty for the plat­form lay­er: hard­ened sys­tems and iso­lat­ed land­scapes, man­aged back­up and restore, HANA data­base man­age­ment, threat and patch man­age­ment, 24×7 secu­ri­ty mon­i­tor­ing, and inci­dent response through SAP’s glob­al secu­ri­ty oper­a­tions. The hyper­scaler (AWS, Azure, or Google Cloud) secures the phys­i­cal and vir­tu­al infra­struc­ture beneath it. The cus­tomer retains respon­si­bil­i­ty for what has always been ours: appli­ca­tion user iden­ti­ty and access, roles and autho­riza­tions, busi­ness process con­fig­u­ra­tion, data own­er­ship, and com­pli­ance with the reg­u­la­tions that gov­ern our industry.

That mod­el is gov­erned against a famil­iar frame for util­i­ty secu­ri­ty teams: the NIST Cyber­se­cu­ri­ty Frame­work, with its Iden­ti­fy, Pro­tect, Detect, Respond, and Recov­er func­tions, backed by the cer­ti­fi­ca­tion and attes­ta­tion port­fo­lio (ISO 27001 fam­i­ly, SOC 1, SOC 2, and oth­ers) that our com­pli­ance teams already know how to consume.

Two ECS ser­vices deserve par­tic­u­lar atten­tion from util­i­ties plan­ning for agen­tic AI, because they answer the vis­i­bil­i­ty ques­tion: how do we see what is hap­pen­ing inside a man­aged environment?

LogServ is ECS’s log col­lec­tion and reten­tion ser­vice. It cen­tral­izes logs from the sys­tems, appli­ca­tions, and ECS ser­vices in your land­scape, sup­ports near-real-time inte­gra­tion into your own SIEM, and offers con­fig­urable reten­tion by data source, from one month up to 10 years. For util­i­ties, that reten­tion range mat­ters: NERC CIP evi­dence require­ments, rate case dis­cov­ery, and inci­dent foren­sics all demand log his­to­ries far longer than default sys­tem reten­tion provides.

RAVEN extends that vis­i­bil­i­ty to the SAP appli­ca­tion lay­er itself, his­tor­i­cal­ly the blind spot in most util­i­ty SIEM deploy­ments. RAVEN deliv­ers SAP appli­ca­tion secu­ri­ty and threat report­ing, secu­ri­ty use cas­es as a ser­vice, and user behav­ior ana­lyt­ics, all feed­ing into the customer’s own SIEM. Your secu­ri­ty oper­a­tions cen­ter final­ly gets to see SAP appli­ca­tion threat activ­i­ty in the same pane of glass as the rest of the enterprise.

Why does this foun­da­tion mat­ter for the autonomous enter­prise? Because agents will run on these sys­tems. An agent’s actions will gen­er­ate appli­ca­tion logs, secu­ri­ty events, and behav­ioral pat­terns. If your orga­ni­za­tion has not already wired this teleme­try into your secu­ri­ty oper­a­tions, you are not ready to mon­i­tor humans in your SAP land­scape, let alone agents. That teleme­try work is home­work we can begin today.

Lay­er Two: The Secu­ri­ty Oper­a­tions Pat­tern Is Already Published

What much of our com­mu­ni­ty has missed is that SAP’s Archi­tec­ture Cen­ter has already pub­lished a ref­er­ence archi­tec­ture for exact­ly this inte­gra­tion: Log-Dri­ven Secu­ri­ty Oper­a­tions with SAP Enter­prise Threat Detec­tion and SIEM/SOAR Plat­forms. Con­tributed by SAP part­ner Fortinet, it doc­u­ments the end-to-end pat­tern, and it deserves a place on every util­i­ty secu­ri­ty architect’s read­ing list.

The flow will feel famil­iar to any­one who has built a secu­ri­ty oper­a­tions pro­gram. SAP sys­tems across the land­scape (RISE work­loads, BTP appli­ca­tions, SaaS solu­tions, and on-premis­es sys­tems) emit secu­ri­ty-rel­e­vant teleme­try: authen­ti­ca­tion activ­i­ty, autho­riza­tion changes, admin­is­tra­tive actions, and appli­ca­tion access traces. SAP Enter­prise Threat Detec­tion (ETD) applies SAP domain-aware pars­ing and detec­tion log­ic to iden­ti­fy sus­pi­cious activ­i­ty, the deep SAP con­text that gener­ic SIEM tool­ing has nev­er parsed well. Those find­ings flow into the enter­prise SIEM, where they are cor­re­lat­ed with iden­ti­ty, end­point, net­work, and cloud sig­nals to sur­face cross-domain attack sce­nar­ios that no sin­gle sys­tem can see alone. A SOAR plat­form then orches­trates the response: enrich­ment, evi­dence col­lec­tion, tick­et cre­ation, approval work­flows, and SAP-aware con­tain­ment actions such as ter­mi­nat­ing user ses­sions, lock­ing accounts, and chang­ing autho­riza­tions. Out­comes feed back into detec­tion log­ic, clos­ing the loop.

Two char­ac­ter­is­tics of this archi­tec­ture mat­ter enor­mous­ly for util­i­ties. First, it for­mal­izes a sep­a­ra­tion of oper­a­tional respon­si­bil­i­ties that mir­rors how most util­i­ties actu­al­ly staff these func­tions: SAP secu­ri­ty and Basis teams oper­ate ETD, while the enter­prise SOC oper­ates the SIEM and SOAR. Sec­ond, its response actions are gov­erned: auto­mat­ed play­books with approval steps, full doc­u­men­ta­tion of every action and deci­sion, and syn­chro­niza­tion with ITSM. That is auditabil­i­ty by design, which is the only kind our reg­u­la­tors will accept.

Now con­nect this to the agent ques­tion. That closed loop of detect, cor­re­late, respond, con­tain, doc­u­ment, and improve is the oper­a­tional pat­tern in which agent secu­ri­ty will live. When an agent mis­be­haves, ​“respond” looks like the same SAP-aware actions the archi­tec­ture already doc­u­ments: ter­mi­nate the ses­sion, lock the iden­ti­ty, revoke the autho­riza­tion. The kill switch for an AI agent is an iden­ti­ty-and-access action, which means it already has a home in this archi­tec­ture. What’s miss­ing is not the pat­tern; it’s the agent-spe­cif­ic detec­tion con­tent and the guar­an­tee that agent actions are dis­tin­guish­able from human actions in every log stream. More on that below.

Lay­er Three: Gov­ern­ing the Agents Themselves

A hard­ened plat­form secures the build­ing, and the secu­ri­ty oper­a­tions pat­tern deter­mines who watch­es it and how they respond. Nei­ther one defines what the new dig­i­tal work­force inside is allowed to do. That is the job of the agent gov­er­nance stack SAP is now assem­bling, and it starts with a blue­print that, again, is already published.

The Blue­print: A Pub­lished Agent Architecture

SAP’s Archi­tec­ture Cen­ter ref­er­ence archi­tec­ture for Agen­tic AI & AI Agents lays out how agents are built, con­nect­ed, and trust­ed in the SAP ecosys­tem. Joule sits at the cen­ter as the orches­tra­tor. Cus­tom agents run on BTP through two paths: low-code agents built in Joule Stu­dio, which reg­is­ter auto­mat­i­cal­ly with Joule and run on a man­aged run­time, and pro-code agents built with the SAP Cloud SDK for AI using frame­works like Lang­Graph and Cre­wAI, con­nect­ed through the open Agent2Agent (A2A) pro­to­col. Tool and data con­nec­tiv­i­ty flows through an MCP Gate­way in SAP Inte­gra­tion Suite. And thread­ing through every con­nec­tion in the dia­gram is one com­po­nent util­i­ty secu­ri­ty archi­tects should study close­ly: SAP Cloud Iden­ti­ty Ser­vices man­ages authen­ti­ca­tion, autho­riza­tion, and iden­ti­ty fed­er­a­tion across all of it. Trust in this archi­tec­ture is bro­kered at every con­nec­tion, nev­er assumed.

The archi­tec­ture also embeds guardrails at the mod­el lay­er through the Gen­er­a­tive AI Hub: ground­ing, data mask­ing, and input/​output fil­ter­ing, which is where con­trols like ​“cus­tomer data nev­er leaves defined bound­aries” get tech­ni­cal­ly enforced rather than mere­ly documented.

For secu­ri­ty teams, the prac­ti­cal sig­nif­i­cance is this: when your CISO asks how an agent gets into your land­scape, what it can touch, and who vouch­es for its iden­ti­ty, the answer now starts from a pub­lished, down­load­able solu­tion dia­gram rather than a white­board sketch, which gives archi­tec­ture review an actu­al arti­fact to work from. That is how every oth­er crit­i­cal sys­tem in a util­i­ty gets gov­erned, and agents should be no different.

One more point with direct bear­ing on last month’s lock-in dis­cus­sion: the archi­tec­ture explic­it­ly embraces open stan­dards, with A2A as the pre­ferred pro­to­col for mul­ti-agent col­lab­o­ra­tion and MCP for tool con­nec­tiv­i­ty, and is designed so that third-par­ty plat­forms like Google Ver­tex AI, Microsoft Copi­lot Stu­dio, and AWS Bedrock can del­e­gate tasks to Joule agents and vice ver­sa, leav­ing the inte­gra­tion lay­er open. As I argued in May, the pro­pri­etary val­ue accu­mu­lates in the mem­o­ry and con­text lay­er, which is pre­cise­ly why that lay­er needs the strongest governance.

Design: Process Atoms

SAP’s process atom con­cept decom­pos­es busi­ness process­es into small, well-defined, reusable units of work, each with explic­it inputs, out­puts, and bound­aries. For secu­ri­ty pur­pos­es, this is more impor­tant than it sounds. You can­not scope an agent’s author­i­ty against a 47-step end-to-end process; you can scope it against an atom. Process atoms give us the unit of least priv­i­lege for the agen­tic era, the equiv­a­lent of grant­i­ng a trans­ac­tion code rather than SAP_ALL.

Rules: Com­pa­ny Memory

Com­pa­ny Mem­o­ry is where the organization’s rules about what should hap­pen live: the poli­cies, con­straints, and insti­tu­tion­al knowl­edge that gov­ern process exe­cu­tion. For util­i­ties, this is where our reg­u­la­to­ry oblig­a­tions get encod­ed, such as the rule that a dis­con­nect for non-pay­ment can­not pro­ceed dur­ing a med­ical-cer­tifi­cate hold, that a switch­ing order requires spe­cif­ic approvals, and that cer­tain cus­tomer data nev­er leaves defined bound­aries. In a human enter­prise, these rules live in pro­ce­dure man­u­als and trib­al knowl­edge. In an autonomous enter­prise, they must live some­where agents can read them and gov­er­nance func­tions can audit them. Com­pa­ny Mem­o­ry is that home, which also makes it one of the most secu­ri­ty-crit­i­cal assets in the entire archi­tec­ture: who­ev­er can write to your rules can steer your agents.

Run­time: Process AI on Signavio

Rules are only as good as their enforce­ment. SAP Signavio’s Process AI watch­es what is actu­al­ly hap­pen­ing dur­ing exe­cu­tion and com­pares it against what should be hap­pen­ing, con­for­mance check­ing for a work­force that oper­ates at machine speed. Sig­navio now sup­ports agents as a doc­u­ment­ed role and swim­lane in BPMN process mod­els. That sounds like a mod­el­ing foot­note; it is actu­al­ly a com­pli­ance break­through. When your inter­nal audi­tor or your reg­u­la­tor asks, ​“Where in this process does an AI agent act, and what are the con­trols around it?” you can now answer with a process dia­gram instead of a shrug.

Account­abil­i­ty: Agents in the Org Structure

Com­ing next quar­ter, SAP Suc­cess­Fac­tors will sup­port orga­ni­za­tion­al capa­bil­i­ties for agents, mean­ing agents will appear in the orga­ni­za­tion­al struc­ture, vis­i­ble along­side the human work­force, with clar­i­ty about where they oper­ate and who is respon­si­ble for them. Every util­i­ty secu­ri­ty frame­work ulti­mate­ly rests on account­abil­i­ty: every actor reports to some­one. Plac­ing agents in the org chart answers a ques­tion reg­u­la­tors will absolute­ly ask: who owns this agent? If an agent dis­patch­es a crew incor­rect­ly or mis-adjusts a rate, the account­abil­i­ty chain should be as trace­able as it would be for an employee.

Ver­i­fi­ca­tion: LeanIX AI Agent Hub and the Ver­i­fi­ca­tion Seal

Also com­ing next quar­ter is the piece I find most sig­nif­i­cant: the LeanIX AI Agent Hub. It extends LeanIX’s enter­prise archi­tec­ture dis­cov­ery to AI agents, giv­ing archi­tects an inven­to­ry of what agents exist and which busi­ness capa­bil­i­ties they touch. But the dif­fer­en­tia­tor is the Ver­i­fi­ca­tion Seal: agents that pass ver­i­fi­ca­tion car­ry a seal that is then enforced in the Joule run­time. Unver­i­fied agents do not run.

This is the dif­fer­ence between gov­er­nance as doc­u­men­ta­tion and gov­er­nance as con­trol. Most AI gov­er­nance frame­works today pro­duce poli­cies, reg­is­ters, and review boards, paper con­trols that depend on humans remem­ber­ing to fol­low them. A ver­i­fi­ca­tion seal enforced at run­time is a tech­ni­cal con­trol: the plat­form itself refus­es to exe­cute agents that have not passed through the gov­er­nance gate. For util­i­ty CISOs, this is the archi­tec­tur­al pat­tern we have been wait­ing for, the agen­tic equiv­a­lent of appli­ca­tion allow-list­ing on a crit­i­cal cyber asset.

The Hon­est Caveats

Embrac­ing this direc­tion does not mean accept­ing it uncrit­i­cal­ly, and three caveats deserve daylight.

First, sev­er­al of these capa­bil­i­ties are roadmap, not prod­uct. The agen­tic ref­er­ence archi­tec­ture itself car­ries a dis­claimer worth quot­ing in spir­it: the Agent Gate­way is not yet gen­er­al­ly avail­able, and the pub­lished archi­tec­ture cur­rent­ly sup­ports out­bound com­mu­ni­ca­tion only, with bidi­rec­tion­al capa­bil­i­ties expect­ed soon. The Suc­cess­Fac­tors agent orga­ni­za­tion­al capa­bil­i­ties and the LeanIX AI Agent Hub are slat­ed for next quar­ter. Our com­mu­ni­ty has learned to dis­tin­guish between announced, deliv­ered, and adopt­ed. Plan against the archi­tec­ture; com­mit against shipped functionality.

Sec­ond, the shared respon­si­bil­i­ty line has not moved. RISE’s secu­ri­ty frame­work explic­it­ly leaves appli­ca­tion-lay­er iden­ti­ty, autho­riza­tions, busi­ness process con­fig­u­ra­tion, and reg­u­la­to­ry com­pli­ance with the cus­tomer. Agents are appli­ca­tion-lay­er actors. SAP is giv­ing us bet­ter tools and bet­ter blue­prints, but agent gov­er­nance is our respon­si­bil­i­ty, not some­thing we out­source with a cloud subscription.

Third, watch the com­mer­cial fine print. Some ECS secu­ri­ty capa­bil­i­ties are includ­ed in the default RISE pack­age; oth­ers, includ­ing SAP Enter­prise Threat Detec­tion, the engine at the heart of the pub­lished secu­ri­ty oper­a­tions archi­tec­ture, car­ry sep­a­rate costs. As agent gov­er­nance tool­ing matures, we should push hard for the capa­bil­i­ties that make agents safe to be treat­ed the way SAP itself describes its ECS phi­los­o­phy: manda­to­ry secu­ri­ty fea­tures, no hid­den secu­ri­ty costs. Secu­ri­ty for the autonomous enter­prise can­not become an upsell.

What We Still Need to Influence

As with the broad­er Autonomous Enter­prise vision, our com­mu­ni­ty has both the stand­ing and the respon­si­bil­i­ty to shape this:

• Extend the pub­lished secu­ri­ty oper­a­tions pat­tern to agents. The ETD-to-SIEM/­SOAR ref­er­ence archi­tec­ture is exact­ly the right skele­ton. We need SAP to extend it with agent-spe­cif­ic detec­tion con­tent, agent activ­i­ty log sources, and the explic­it guar­an­tee that agent actions are dis­tin­guish­able from human actions at every hop, from appli­ca­tion log to SIEM event to SOAR case.
• Agent iden­ti­ty life­cy­cle guid­ance: SAP Cloud Iden­ti­ty Ser­vices already bro­kers trust across the agent archi­tec­ture. What we need now is pub­lished guid­ance for agents as first-class iden­ti­ties, cov­er­ing pro­vi­sion­ing, cre­den­tial rota­tion, cer­ti­fi­ca­tion, and depro­vi­sion­ing, and inte­gra­tion with our exist­ing IAM and PAM investments.
• SAP-aware response actions for agents: The SOAR pat­tern doc­u­ments con­tain­ment actions for human accounts: ses­sion ter­mi­na­tion, account lock­ing, and role changes. We need the agent equiv­a­lents doc­u­ment­ed and sup­port­ed in SOAR con­nec­tors: sus­pend an agent, quar­an­tine its out­puts, revoke its ver­i­fi­ca­tion seal.
• Ver­i­fi­ca­tion Seal trans­paren­cy: What does ver­i­fi­ca­tion actu­al­ly test? Who can grant it, revoke it, and audit it? A run­time-enforced seal is only as trust­wor­thy as the ver­i­fi­ca­tion process behind it. The cri­te­ria must be trans­par­ent and customer-auditable.
• NERC CIP align­ment guid­ance: We need SAP to pub­lish explic­it map­ping between the agent gov­er­nance stack and NERC CIP require­ments, par­tic­u­lar­ly around access man­age­ment, change con­trol, and evi­dence gen­er­a­tion, so that each util­i­ty is not rein­vent­ing that analy­sis alone.
• Oper­a­tional tech­nol­o­gy bound­aries: Our most sen­si­tive sys­tems (ADMS, SCA­DA, OMS) sit out­side SAP’s perime­ter, but inside many of the work­flows agents will touch. We need explic­it archi­tec­tur­al guid­ance on where agent author­i­ty stops at the OT boundary.

A Call to Our Community

Last month, I asked our com­mu­ni­ty a hard ques­tion: if not SAP’s gov­er­nance frame­work, then what? This month, I’ll ask its sequel: if your util­i­ty deployed an AI agent into pro­duc­tion tomor­row, could you tell your reg­u­la­tor who autho­rized it, what rules it fol­lows, who mon­i­tors it, where it sits in your orga­ni­za­tion, and how you would shut it down?

If the answer is no, that is not a rea­son to avoid the autonomous enter­prise. It is the project plan, and unlike a year ago, the com­po­nents now have pub­lished archi­tec­tures behind them. A hard­ened RISE foun­da­tion with LogServ and RAVEN for vis­i­bil­i­ty. A doc­u­ment­ed ETD-to-SIEM/­SOAR pat­tern that puts SAP detec­tions, agent teleme­try, and the agent kill switch inside your exist­ing SOC. A pub­lished agent archi­tec­ture with iden­ti­ty-bro­kered trust at every con­nec­tion. Process atoms for scop­ing, Com­pa­ny Mem­o­ry for rules, Sig­navio Process AI for run­time con­for­mance, orga­ni­za­tion­al account­abil­i­ty in Suc­cess­Fac­tors, and run­time-enforced ver­i­fi­ca­tion through LeanIX and Joule.

Our job is to assem­ble these into a gov­er­nance pos­ture our secu­ri­ty teams, audi­tors, and reg­u­la­tors can stand behind, and to push SAP, loud­ly and con­struc­tive­ly, where the gaps remain. Start with the two ref­er­ence archi­tec­tures on SAP’s Archi­tec­ture Cen­ter. Hand them to your secu­ri­ty archi­tect and your SOC lead this week. They are free, cur­rent, and the start­ing point for the reg­u­la­tor con­ver­sa­tion every one of us will even­tu­al­ly have.

Secu­ri­ty is the pre­con­di­tion for the autonomous enter­prise, not one of its fea­tures, and the util­i­ties that treat it that way will be the ones whose agents make it out of the lab.

For more SAP util­i­ties insights, sign up to receive ASUG’s free The Top­ic: Util­i­ties newslet­ter, and to get involved and keep up with the lat­est, join ASUG’s Util­i­ties Com­mu­ni­ty. Con­nect with SAP teams across the util­i­ties com­mu­ni­ty as they explore AI adop­tion, clean core, data strat­e­gy, and more at SAP for Util­i­ties, Pre­sent­ed by ASUG in San Anto­nio, Octo­ber 6 – 9, 2026.