AI Agent Security Must Sit Inside the Business Process: SAP Whitepaper

An AI agent that releases vendor payments can act on a wrong or fraudulent invoice in seconds, before anyone reviews it. Model monitoring, prompt filtering, and infrastructure guardrails can restrict which endpoint the agent reaches or flag a suspicious output.

In a whitepaper called “Securing AI in SAP Autonomous Suite“, SAP explains that those controls sit outside the business application, so they cannot judge whether a given payment fits company policy. The check belongs inside the application, where approval hierarchies, segregation of duties, and data classification already define a valid action.

Agents and human users face the same rules in SAP’s design, alongside agent identities, human approval, and business-process audit records. Customers configure the permissions and thresholds that the controls enforce.

Agent Risk Sits Inside the Business Process

Enterprise security was built for software that followed programmed workflows with predictable outcomes, so its central question was who could access a system. Agents choose and sequence actions at runtime within the authority delegated to them, so the question becomes what an automated process may decide to execute, and under whose authority.

SAP’s assessment is that access and perimeter controls were not designed to govern autonomous agent behavior inside a business process. Model monitoring, prompt filtering, and infrastructure guardrails protect the model and its connections but have no view of the rules that decide whether an action is acceptable: approval limits, segregation of duties, period controls, and data classifications. They can confirm that a caller may use a capability. They cannot confirm that a specific act on a specific record is permitted for the user the agent represents.

SAP described several scenarios in which agents create exposure. A compromised agent with broad API access gives an attacker every permission the agent held. An agent can carry out thousands of individually authorized actions within minutes, and their combined effect can exceed a risk threshold before conventional governance reacts. A supplier can hide an instruction in an invoice notes field, and an agent that treats the text as a command may attempt an unauthorized action.

The Application Decides What an Agent Can Do

SAP’s response depends on the business application doing the checking, so every agent request meets the same authorization, approval, and posting rules that a human user’s request meets. A vendor invoice handled by an agent shows where each check applies.

The agent reaches the application as a named identity that carries the authorization of the user it acts for, so an agent working for a finance user can do only what that user may do, and a procurement agent cannot reach HR compensation data. Gateways confirm the agent’s credentials and which tools and APIs it may use, and the application then applies the user’s own roles.

Valid access does not clear the invoice, because the application still tests it against posting rules. An invoice dated to a closed period, missing a mandatory cost center, or priced outside the permitted tolerance against its purchase order is stopped before it reaches the ledger. SAP says transaction controls like these have long helped prevent errors and fraud in its applications, and that they check a posting the same way whether a person or an agent initiates it.

The same checks apply when a model has been manipulated: a jailbroken model still cannot approve a transaction or reach restricted data that the application’s authorization framework withholds. Gabriele Fiata, head of market strategy for SAP Cloud ERP Operations and Support, writes that the principle is straightforward: “The model can propose; but the application decides.”

In his example, an invoice’s notes field tells an agent to ignore the approval limit. The application enforces the limit, and the three-way match that compares the invoice with its purchase order and goods receipt, outside the model’s control, so the hidden instruction cannot lift them.

High-impact or policy-sensitive actions route to a human decision-maker before execution, and accountability stays with the person who approves. An infrastructure log shows only that an API was called. The audit trail records what changed in the business record, under whose authority, and whether a human approved it.

What Customers Configure and Where SAP’s Controls Reach

Customers decide what SAP’s controls enforce, and how directly those controls apply depends on where an agent runs.

SAP describes a shared-responsibility model in which it supplies the structural controls and each customer defines which permissions agents receive, which approval thresholds apply, and how governance policies fit its landscape. SAP’s general cloud security model already places application configuration, user access, and data access with the customer.

Existing role design is the starting point, because agents inherit delegated permissions, including any overprovisioning in those roles. SAP therefore advises cleaning up authorization baselines before deploying agents.

Inside the perimeter of SAP solutions, runtime controls operate through the agent gateway, which SAP says is generally available. Agents built in Joule Studio, SAP’s tool for creating agents, and the tools and APIs they call through SAP Integration Suite pass a verification workflow before receiving production access, and runtime verification blocks agents that are not verified in SAP AI Agent Hub.

Agents hosted on platforms from Microsoft, Google, Amazon Web Services, and ServiceNow get strategic governance instead: SAP AI Agent Hub discovers and registers them, assigns each an owner, and classifies its risk.

What This Means for SAPinsiders

Agent risk moves into the business process. Once software chooses its own actions at runtime, security has to operate where a decision becomes a posting, an approval, or a record change. Monitoring around models and infrastructure records the activity, and the business record shows its consequences.

Enforcement belongs where business rules already live. Posting rules, approval hierarchies, and segregation of duties already define a valid transaction in finance, HR, and supply chain. Applying them to agents turns a model’s output into a proposal that the application accepts or refuses.

Existing permissions limit what agents can do. Because agents act with the authority of the users and roles behind them, authorization design decides how far an agent can reach. Any excess access in those roles passes to the agents acting on those users’ behalf.