The day a utility’s first SAP agent touches production will not be set by SAP’s roadmap.
The following Utility Voice was authored by Marc Rosson, Community Connector at Utility.Community.
The day a utility’s first SAP agent touches production will not be set by SAP’s roadmap. It will be set by a CISO, a NERC CIP compliance lead and an internal auditor. Each of them will ask a version of the same question: can you prove what this agent is, what it touched, and how you would stop it?
SAP TechEd 2026 in Berlin (October 27 to 29) carried the Autonomous Enterprise theme from Sapphire and Connect down to the foundation: the tools to build agents, the data to ground them, and the controls to govern them. A week later the ASUG TechEd tour made its only North American stop, in Fort Worth (November 2 to 4). Around forty announcements in the Innovation News Guide. None of them mentions utilities. That is not a complaint. TechEd is a platform event, and the platform is exactly what a utility’s security team has to sign off on before any of the dated utility agents from San Antonio can run.
So this article reads TechEd the way a utility security team would. Two weeks before Berlin, FERC staff published Lessons Learned from Commission-Led CIP Reliability Audits (October 13, 2026). It put AI tools inside CIP-004, CIP-005, CIP-007, CIP-011 and CIP-013 and said entities should inventory them like generic service accounts. That non-binding report is the bar I hold TechEd to here. My conclusion: the foundation now has dates. The locks are only partly dated, mostly framed for Europe, and silent on NERC CIP and on the private cloud and on-premise landscapes most US utilities still run.
Fort Worth TechEd said the same thing from the other side of the stage. Agentic security got little time in the keynotes, but in the community sessions it was one of the issues customers pressed hardest.
Layer One: The Foundation Got Dates
The build layer is shipping. Joule Studio, its developer CLI, n8n-based agent extensions and the Joule Studio runtime are all in what SAP calls phased general availability, and select customers can run custom agents free on the SAP-managed runtime through December 2026. The context layer is dated for the first quarter of 2027: customer data products from Business Data Cloud flow into SAP Knowledge Graph and into agent runtime, and the BDC Ontology Manager enters beta in November.
Put those dates beside the San Antonio roadmap and a sequence appears. Context arrives in Q1 2027. SAP’s packaged BPEM (demoed at the San Antonio keynote) and tariff agents arrive in Q2 2027. ECC mainstream maintenance ends December 31, 2027. The security question is no longer theoretical. It is next quarter’s question.
And the threat is not waiting for the roadmap. In early November, Onapsis CTO JP Perez-Etchegoyen showed an AI agent, given one generic prompt by someone claiming to know nothing about SAP, working its way into a lab system and rewriting a vendor’s bank details. None of the openings it used was a zero-day: a default credential, an unpatched 2025 vulnerability and a permissive gateway setting. Bottom line, even without Industry AI and Autonomous Enterprise for utilities, AI is making security much harder, and your security teams need resources in tools and training to continue to do the job they have done in the past.
Layer Two: What Secures It, and When
Here is what TechEd put on the table for security and governance, held against the Regulator Test from this series (who authorized it, what rules govern it, who is watching, where it sits, how you would shut it down) and the CIP requirements FERC staff named.
| TechEd item | Status | Regulator Test question | Nearest CIP requirement |
|---|---|---|---|
| Agent gateway: third-party agents invoke Joule Agents through one governed entry point with access control | “Generally available today” per SAP’s Chief AI Officer; phased GA per the guide; SAP’s reference architecture still lists full bidirectional support as not yet available | Rules; where it sits | CIP-005 (communications) |
| Runtime verification enforcement: agents not verified in SAP AI Agent Hub cannot be invoked | Announced in the keynote; no date given | Who authorized it | CIP-007 (inventory, enabled services) |
| Joule Work agentic thinking: audit trails, role-based permissions, human-in-the-loop checkpoints | Phased GA | Watching; rules | CIP-004 (authorize, verify) |
| Joule Studio runtime with NVIDIA OpenShell isolation and guardrails | Phased GA | Containment | CIP-007 (malicious code) |
| Pre-deployment sandbox; offline evaluations including prompt-injection resistance | Phased GA; evaluations late Q4 2026 | Rules, tested before production | CIP-007, CIP-010 |
| AI Governance Assistant in Agent Hub: EU AI Act risk classification, continuous assessment | November for Early Adopter Care customers; GA Q4 2026 | Who authorized it; where it sits | CIP-013 (vendor risk), indirectly |
| SAP Enterprise AI Gateway: identity-based authentication, policy, routing, usage and audit for MCP, API, A2A and LLM traffic | Q1 2027 | Watching; who authorized it | CIP-004, CIP-005, CIP-007 |
| Integration Suite AI detection of irregular payload sizes | Generally available | Watching | CIP-005 |
Three things stand out.
The control plane is a quarter out. The piece that looks most like what a CIP program needs, the Enterprise AI Gateway, is Q1 2027. SAP describes it as an overlay to the agent gateway, built on Integration Suite. SAPinsider reports it will be a premium offering, with no price yet. A utility planning a Q1 or Q2 pilot should budget for it now, not discover it in the license review.
“Phased” is not a date, and “GA” needs a footnote. Most of what is available now is in phased general availability: some customers have it, others get it later, on a schedule the guide does not publish. Even the agent gateway, announced from the stage as generally available, is described in SAP’s own Architecture Center (updated October 26) as not yet supporting full two-way traffic with third-party and self-hosted agents. Ask your account team which phase you are in, and what “available” covers, in writing.
The most useful new control has no date. Runtime verification enforcement, the rule that an agent not verified in Agent Hub cannot be invoked, is the closest thing yet to an allow-list a CIP auditor would recognize. Nothing I could find says when it ships or whether withdrawing verification stops an agent that is already running.
SAP’s product leaders also said from the stage that agents leave the same audit trail as SAP’s applications, and that they are ISO and SOC compliant. Those are claims about SAP’s agents in SAP’s cloud. A CIP audit asks a narrower question: can you show this agent’s action, on behalf of this user, in your SIEM, from your landscape?
Two practitioners argue the application trail is not enough. An October white paper from AlphaOak, an SAP asset-management partner that works with utilities, puts it plainly: “A technically logged transaction is not necessarily an auditable agent decision.” An application log records the posting; an agent audit has to reconstruct what triggered the agent, what it read, what a person approved, and which tool made the call. Onapsis makes the detection version of the same point: when an agent’s technical user makes a valid call, a generic log shows a successful request and raises no alert. Only SAP application context reveals that the procurement agent just changed a top vendor’s bank details, outside its normal pattern. The trail neither reconstructs the decision nor flags the abuse unless someone connects it, and that someone is the customer.
Layer Three: What TechEd Did Not Say
Read the guide, the press release and SAP’s own keynote summary end to end, and here is what is missing for a North American utility.
Agent identity. SAP’s Architecture Center now describes two agent models in Cloud Identity Services: agents acting inside a user’s context with agent-specific limits, and autonomous agents with their own dedicated technical identity, tokens and audit trail. Effective permission is the intersection of user and agent rights, enforced at every hop. That is the right design. What is missing is a general availability date for per-agent identity, which SAP had pointed to for Q3 2026, and any description of how agent identities are rotated, recertified and retired.
A kill switch. The fifth Regulator Test question, how would you shut it down, still has no documented answer. If agents have their own identity, revoking that identity is the obvious off switch, but no SAP material shows it working, or shows how fast. That matters because three independent sources now treat a stop control as table stakes: AlphaOak’s EAM paper lists “override and safe-stop capability” as mandatory for supervised agents, Onapsis’s governance model includes the ability to suspend an agent, and SAP’s own Fort Worth governance session (below) puts an escalation path at every layer.
Agent versus human in the logs. FERC staff flagged that AI tools can mimic user behavior, making legitimate and malicious activity harder to tell apart. The keynote named agent observability and SAP Signavio agent mining as the tools that close the loop. Neither had a general availability date at TechEd. Enterprise Threat Detection, LogServ and Cloud ALM, where a utility’s security operations team would actually look, were not mentioned.
RISE private cloud and on-premise. The trace, identity and gateway patterns SAP describes are public-cloud patterns. Nothing at TechEd says they cover RISE private cloud or on-premise S/4HANA and ECC, which is where most US utilities will be through 2027. In Fort Worth, Jon Reed of diginomica heard the same tension from RISE private cloud customers: wanting granular control of their AI services runs into SAP’s own management of the infrastructure. And RISE does not move the work: under the shared-responsibility model, authorizations, threat detection, custom-code security and compliance monitoring stay with the customer.
North American regulation. The AI Governance Assistant is built for the EU AI Act and unnamed “other regulatory frameworks.” There is no NERC CIP mapping, no NIST AI RMF crosswalk, and nothing for state inventory rules like New York’s Case 26-M-0552, whose filings are due November 16. One customer in Fort Worth said they struggled to get security buy-in because their company is not subject to the EU AI Act. For a US utility that problem has an answer, and it is not in SAP’s material: the regulation is FERC’s October lesson, and the CIP requirements behind it already apply.
The OT boundary. TechEd’s Physical AI announcement is described as bridging IT and OT, with robots writing outcomes back into SAP as live transactions. That is a warehouse, not a substation. But SAP now names the IT-OT bridge as a product direction, and the only SAP statement on where agent authority stops at a utility’s operational boundary is still J. Michael Sullivan’s principle from October: decisions that could affect human life or carry significant consequences stay with people. That is a principle, not a control.
Context as attack surface. In Q1 2027, customer data products flow into Knowledge Graph and agent runtime. For a utility, some of that data is BES Cyber System Information: network models, asset configurations, GIS. Nothing at TechEd says whether grounding honors the access controls on the source data. Under CIP-011 that question decides whether an agent can be deployed at all.
Layer Four: What Good Looks Like Before Go-Live
Utilities that have shipped AI have already answered governance for AI in delivery and IT support. Article 11 showed OG&E, PG&E, Nexus Water, SRP and Avista doing it on their own slides. Agents acting on operations are the next gate, and the security sign-off is what opens it.
Half of that sign-off is not SAP’s to give. SAP can enforce boundaries. Only the utility can draw them. The best practical framework I heard came, fittingly, from SAP itself in Fort Worth. In “Guardrails for Genius,” Srinivas Nandiwada, a cybersecurity and compliance advisor at SAP, laid out a governance process that does not wait for the platform, as reported by diginomica: keep a live registry of agents in LeanIX; require a deployment manifest per agent, with any change in scope sent back for approval; write a system card for each agent describing its scope and risk exposure; and run your highest-risk agent through the process first. His line that “every data flow in and out of an agent is a privacy surface” is worth taping to a CIP-011 binder.
Two October papers from AlphaOak give the utility half a sharper shape. Dr. Achim Krüger’s authority envelope asks six questions of every AI-enabled process: what the agent may reach; what it may propose, prepare or execute; which asset classes, locations, risk levels and dollar thresholds are in scope; what forces escalation to a person; who can approve, override, suspend or reconfigure it; and how its actions are reversed and logged. His example will look familiar to any maintenance planner: an agent may draft work orders for low- and medium-criticality assets, but for high-criticality assets it only assembles the evidence, and a qualified person decides. Tony Buffington’s evidence chain adds the audit half: an agent’s effective authority is the overlap of the user’s permissions, the agent’s permissions, the tool’s scope and business policy, and every material action carries one correlation ID from trigger to SAP document.
Nandiwada’s manifest is the CIP-004 authorization record. His registry is the CIP-007 inventory. Krüger’s envelope is the CIP-005 business justification. The frameworks exist; nobody has yet stapled them to the CIP standards.
Put SAP’s controls and the utility’s design together, and here is the minimum package I would ask for before any SAP agent reaches a production system that matters to reliability, safety or the customer bill:
- A unique, least-privilege identity per agent, inventoried like a service account, with segregation-of-duties rules applied and evidence of how it is revoked.
- One correlation ID from trigger to SAP document, showing “agent X on behalf of user Y,” landing in your SIEM and distinguishable from human activity.
- A written authority envelope and deployment manifest for each agent, enforced as gateway policy for every tool and endpoint it can reach, with the business reason, especially anything that touches an ESP, EACMS or BCSI. Scope changes require re-approval.
- Prompt-injection test results for the agent, from the sandbox or offline evaluations.
- Written confirmation that items 1 to 3 work on your landscape: public cloud, RISE private cloud or on-premise.
- A CIP mapping for the SAP components in the path, and a licensing bill of materials so that turning on the audit trail is not a surprise.
SAP’s security team told me in October that more is coming in Q1 2027. That lines up with the Enterprise AI Gateway date. It also means a utility planning to be in production in the first half of 2027 should get these answers in writing this quarter.
Layer Five: What Moved on the Scorecard
On the public scorecard from Article 11, question 46 (n8n in Joule Studio) was updated on October 27. TechEd adds evidence to question 44 (agent inventory), since agents on the Joule Studio runtime are discoverable in Agent Hub, and a partial answer on ontologies through Ontology Manager’s November beta.
The security rows did not move. Agent identity, kill switch, agent-versus-human detection, the CIP mapping and the OT boundary all read the same after Berlin and Fort Worth as before them. For a security team, that is the finding.
Honest Caveats
This reading rests mainly on SAP’s own material: the Innovation News Guide, the press release, SAP’s keynote summary and its Architecture Center. I was not in Fort Worth. For its sessions I rely on diginomica’s review, and diginomica discloses that the event organizer paid most of its reporter’s travel and that SAP is one of its partners. Anything said only in sessions it did not cover is not reflected here. Planned dates move; n8n in Joule Studio was a Q3 2026 target before it became Q1 2027.
AlphaOak and Onapsis both sell SAP services or products, and their papers and decks end with a pitch. I use their frameworks because they are specific and testable, not as neutral research. Onapsis’s demos ran on deliberately weakened lab systems. None of these sources maps controls to NERC CIP; the CIP reading here is mine.
The FERC staff report is non-binding and creates no new requirement, and the CIP standards neither allow nor prohibit these tools. Nothing here is legal or compliance advice; your compliance team decides how your entity reads it.
One more risk sits outside agents entirely. The same coding assistants utilities are piloting write ABAP. In Onapsis’s test, most AI-written RFC modules shipped without an authority check. Agent governance without a transport gate for AI-written code covers only half the door.
It is also fair to say SAP is further along than most enterprise vendors on agent governance. An agent registry, a verification gate, identity-intersected permissions and runtime isolation are real controls, and SAP’s own advisors are teaching customers to govern before the platform finishes. The gap is not effort. It is that the controls are dated for a public-cloud, European-regulated customer first, and US utilities are neither.
What We Still Need to Influence
- A published NERC CIP mapping for agent gateway, Enterprise AI Gateway, Agent Hub and Cloud Identity Services.
- A written statement of which of these controls cover RISE private cloud and on-premise S/4HANA and ECC.
- Agent-specific suspend, revoke and de-provision, with time-stamped evidence.
- Agent activity as a log source in Enterprise Threat Detection and LogServ, flagged agent versus human.
- NIST AI RMF and US state frameworks named alongside the EU AI Act in the AI Governance Assistant, and a US region for sovereign AI.
- Customer-level dates for “phased” general availability, and a date for runtime verification enforcement.
Your Turn
Three pieces of homework before your next AI pilot leaves the sandbox.
First, list every agent and integration that touches SAP today, the technical user each runs as, and that user’s authorizations. If the list is hard to build, that is your first finding.
Second, take the six-item package above to your CISO and your CIP compliance lead. Mark which items they would accept today from SAP’s current material, and which they would not. Send SAP the ones they would not, and send them to me too.
Third, pick one SAP process where a person and an agent both act, and trace one transaction end to end with the records you have today, from what triggered it to the SAP document it produced. Where the trail breaks is your real security gap, whatever the roadmap says.
If enough of us ask the same six questions in the same words, and bring back the same broken trails, they stop being one utility’s problems and become the industry’s.
Without security tools and training for those currently accountable, nothing goes into production. While the C-Suite can push for AI and SAP works to deliver compelling use cases, those accountable for security need the support, tools, and training to enable the Autonomous Enterprise for Utilities. Let’s make sure SAP hears what “security” means for an AI-enabled utility and what they need to deliver to the security teams to enable it.