Leadership1 publisher3 min readPublished
SecurityBridge's co-founder makes the SAP agent case on one survey and two prior incidents
Ivan Mans of SecurityBridge says the SAP security question is now what an agent already inside the system is allowed to do and whether anyone can prove it afterward. His incident record comes from developer tooling.
The Board Room · Leadership desk
What happened
- Ivan Mans, co-founder of the SAP security software firm SecurityBridge, wrote in Forbes that autonomous agents act inside trusted SAP workflows using credentials and privileges granted for legitimate purposes.
- SAP's own AI products, Joule and the embedded agents in S/4HANA and BTP, each add a privileged actor working directly against the financials, payroll, supply chain and master data of large enterprises.
- He wrote that model guardrails limit what an agent is told to do and not what a compromised agent can access, citing VentureBeat on research finding bypasses in a majority of attempts.
Compiled by The Board RoomSomething wrong?How this is made
Why it matters
- constraint An audit trail that scores each API call on its own merits will pass a chain that ends in access no human was granted, so per-step logging is not by itself evidence that an agent was contained.
- decision Enabling an S/4HANA or BTP agent forces a scoping call that the existing human role design does not answer: what this agent may read, and what it may change.
- cost The remedies extend runtime protection, API policy and composition analysis to a second class of caller, and the same application security team keeps running the human-session versions alongside them.
- exposure Agent configuration files are now a documented persistence and propagation route, so the code an SAP shop has to review includes artifacts no human author ever committed.
The pattern that makes agent-scoped authorization more than a preference is what Mans calls ambient escalation. An agent chaining API calls can assemble an effective level of access no single human was ever granted, and no individual step in the chain looks abnormal [10]. A control that judges each call on its own terms has nothing to flag. That is a defect in the authorization model, and Mans wrote that application security has to carry it and network security cannot [22].
The number holding up the argument is thinner than the mechanism. Mans cites an April 2026 Cloud Security Alliance study in which 53% of surveyed organizations said AI agents had exceeded their intended permissions [7]. The column gives no sample size, no description of the population, and no definition of what counts as exceeding a permission [24]. Read as reported, the same survey leaves 47% who did not say it [8]. A self-reported overrun also requires logging good enough to notice one, and that logging is the thing being argued for.
The two documented incidents both sit in the toolchain. The Hacker News reported in April 2026 that compromised SAP-related npm packages planted malicious configuration files that hijack AI coding agents [11], and the StepSecurity research it cited called this "one of the first supply chain attacks to target AI coding agent configurations as a persistence and propagation vector" [12]. In 2024, Wiz researchers disclosed flaws in SAP AI Core that let them execute arbitrary code, move laterally and reach customer data and cloud credentials [13]. Neither is an embedded S/4HANA agent posting something it should not have posted, and the column cites no such case [25].
Mans co-founded SecurityBridge, which builds SAP cybersecurity software [1], and his prescription is a list of application security controls. The part that stands without the vendor is the guardrail argument. Guardrails are necessary, Mans wrote, but "they constrain what an agent is told to do rather than what a compromised agent can access" [17]. He cited VentureBeat on research showing guardrails can be bypassed in a majority of attempts under the right conditions [19]. "any control an attacker can talk their way past isn't a control you can take to an auditor," he wrote [18].
He does not price the duplication. Runtime application self-protection has to monitor agent-initiated actions, not only human-driven sessions, and treat an autonomous caller as a first-class subject [14]. API security has to apply least privilege and behavioral baselining to a client that is now the fastest and least predictable one it sees [15]. Composition analysis has to reach code an agent generated or configured, closing the gap between what a human committed and what an agent produced [16]. The human-session version of each control stays in place.
This quarter the decision is narrow: which agents get switched on, and against what data. Next quarter the consequence is whether the log can show what the agent was permitted to do at the time. Mans located durable assurance in the surrounding application architecture, specifically what data an agent can reach and what it is permitted to change [20].
What to watch
- Whether the Cloud Security Alliance publishes the sample size, population and permission-overrun definition behind the 53% figure.
- A first disclosed case of an embedded SAP agent taking an unauthorized action in production, as distinct from a compromised coding-agent configuration.
- Whether SAP documents agent-scoped authorization objects and audit records for Joule and BTP agents, or leaves an agent inheriting the rights of the user it acts for.