How should an AI agent authenticate to SAP? | Agentic ERP Quickstart
One value in cdk/config.yaml selects who signs users in, who validates tokens at the runtime, which processing modes run, and which credential reaches SAP. Here is how to pick the profile that fits your environment.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 3How should an AI agent authenticate to SAP? | Agentic ERP Quickstart This article
How should an AI agent authenticate to SAP? Five options | Agentic ERP Quickstart
Two questions decide how your agent should authenticate to SAP, and almost everyone configures a day's worth of identity plumbing before asking them. Does SAP need to see the individual person who asked, or is a shared service account acceptable? And do you need work to run when nobody is signed in? Answer those two and the choice narrows to one of five deployable paths, of which two have a live-SAP verification record behind them. Answer them afterward and you will be unpicking token exchanges you did not need.
Series: Building governed ERP agents on AWS · Series guide →
This post: How to pick the identity path that fits your environment, before you spend a day configuring the wrong one.
Prereq: A deployed stack from the deploy walkthrough .
What you get from this post
A decision, not a procedure. By the end you will know which of five deployable profiles matches your environment, and you will be able to answer the two questions that decide it: does SAP need to see the individual person, and do you need unattended processing?
You also get:
- A one-page comparison of every profile you can deploy today, including which two have a live-SAP verification record and what each one actually proves.
- The four decisions a profile bundles, so an error at one hop makes sense when it surfaces at another.
- The two separate paths to SAP in this deployment, and why one of them ignores your profile choice entirely.
- The three settings people confuse with this one, including the one that is not a SAP write switch.
Time: about 7 minutes to read. The setup work lives in Posts 3, 4, and 5.
New to this series? Start here
The Agentic ERP Automation Quickstart is an open source reference implementation that deploys an AI agent for work your team does by hand from a written procedure, on Amazon Bedrock AgentCore. Accounts payable is the worked example, where a case looks like an invoice that does not match its purchase order. A new process type is a skill directory and your own SOPs. Four pieces matter for this post:
- The frontend and runtime. People sign in to a web application, and the agent runs behind it.
- The scheduled OData poller. A Lambda function that reads SAP on a timer to find exceptions. OData is the REST-style API protocol SAP exposes for business data.
- The AWS for SAP MCP Server. A separate AWS-provided runtime that gives the agent its SAP tools. MCP is the Model Context Protocol, the standard the agent uses to call tools. You deploy this stack yourself, and the Quickstart does not deploy it for you.
- AgentCore Gateway. The component that connects the agent to that external MCP runtime and can apply policy at the boundary.
Why one setting instead of four
Four identity decisions have to agree before the agent can reach SAP:
- Who signs the user in.
- Who validates the token when a request arrives at the runtime.
- Whether work runs attended, unattended, or both.
- Which credential arrives at SAP.
When one of them disagrees with the others, you rarely get an error where the mistake is. You get an opaque 401 two or three hops away. The
auth_profile key in cdk/config.yaml avoids that by collapsing all four into one named combination that is known to fit together:1
auth_profile: cognito-basic # the defaultSelecting a profile does not remove external prerequisites. You still need the SAP system, any external identity provider, and the separately deployed AWS for SAP MCP Server.
Pick your profile
1
2
3
4
5
6
7
8
9
Does SAP need to see the signed-in person, rather than one shared account?
├── No → Do you also need unattended backlog processing?
│ ├── No → cognito-basic (the default), or cognito-m2m if your
│ │ SAP team requires OAuth client credentials
│ └── Yes → cognito-m2m-batch
└── Yes → Is your identity provider Microsoft Entra?
├── Yes → entra-obo
└── No → There is no deployable path today. You can sign in with
Okta using okta-basic, but SAP still sees a technical user.If you are evaluating the sample and have no strong requirement yet, stay on
cognito-basic. It needs no external identity provider and it is the fastest route to real SAP data.Profiles you can deploy today
| Profile | Login | Credential reaching SAP | Status |
|---|---|---|---|
cognito-basic | Amazon Cognito | Basic technical user | Verified end to end against live SAP. No per-user SAP identity. This is the default. |
cognito-m2m | Amazon Cognito | SAP-issued OAuth 2.0 client credentials | Deploys today. No live-SAP verification record, so validate it in your own environment. |
cognito-m2m-batch | Amazon Cognito | SAP-issued OAuth 2.0 client credentials | Same as above, plus an unattended backlog sweeper. Preview maturity, because the batch capability is preview. |
entra-obo | Microsoft Entra | A token exchanged for the signed-in person | Verified end to end on the tested S/4HANA 2023 system running SAP_BASIS 7.58. Runs attended only. |
okta-basic | Okta | Basic technical user | Deploys today, and proves Okta sign-in works. It does not carry the person's identity to SAP. Experimental maturity, because the Okta frontend is experimental. |
A profile is only as mature as its least mature part, which is why adding batch or Okta lowers the rating even when everything else is generally available.
What "verified" means here. Two profiles have a recorded live-SAP run, and they prove different things.
cognito-basic proves the technical-user path to SAP works. entra-obo proves the signed-in person's identity reaches SAP. Neither result carries over to a different SAP release, a different identity provider tenant, or a different deployment. Every other profile deploys through the same tested code path but has no live-SAP record of its own, so plan to validate it yourself.Preview profiles. Three more combinations exist in the repository (
cognito-userfed-ias, entra-userfed, and okta-userfed). Each has at least one part that cannot yet stand up end to end, so they are roadmap rather than procedure. Do not plan a deployment around them.The four decisions behind a profile
Each profile is a named set of values across four axes. You do not set these individually in normal use, but knowing them makes error messages readable.
| Axis | What it decides | Values |
|---|---|---|
| Frontend | Which provider signs the user in to the web application | cognito, direct-entra, direct-okta |
| Inbound | Which provider's tokens the runtime will accept | cognito, entra, okta |
| Mode | Which kinds of processing are allowed | autonomous, live, batch |
| Outbound | Which credential the SAP-facing connection uses | basic, m2m-sap, obo, user-federation |
Most profile differences come down to a single axis.
cognito-basic and cognito-m2m differ only on outbound, which is why switching between them changes nothing about how people sign in.Two separate paths reach SAP
This is the detail that surprises people most, so it is worth learning before you choose.
| Component | How it reaches SAP | What governs it |
|---|---|---|
| The OData poller (scheduled) | Calls SAP directly with Basic credentials from AWS Secrets Manager | Always Basic, on every profile. It never reads auth_profile. |
| The agent (user-initiated or autonomous) | Calls the external AWS for SAP MCP Server | The outbound axis of your profile |
The poller is the only component in this repository that calls SAP directly. Everything the agent does goes through the separately deployed MCP Server, which has its own write-enable flags and its own authorization configuration.
Two consequences follow. First, choosing a profile with OAuth or per-user identity does not move the poller off Basic. Second, configuring the poller's credentials does not give the agent SAP tools. Those are two independent pieces of work.
What this setting does not control
| Setting | What it actually does |
|---|---|
auth_profile | Deploy-time identity topology across all four axes |
autonomy.trigger_mode | Whether unattended work starts automatically or waits for a person. It is not a SAP write switch. |
| External MCP write flags | Deploy-time control over which SAP write tools the external MCP Server exposes at all |
| Gateway Cedar policies | Controls on the Gateway path, and only when the relevant target and the policy engine are deployed with enforcement set to ENFORCE. They do not cover the direct-to-MCP path used by entra-obo. |
If a SAP write must be impossible, restrict it in SAP. The layers above reduce exposure. SAP authorizations are the only ones SAP enforces itself.
Set up your chosen profile
cognito-basic: a technical SAP user . The default. A technical SAP user, no external identity provider needed. Start here if you just want SAP data flowing.cognito-m2m: SAP client credentials . SAP-issued OAuth 2.0 client credentials, for teams whose SAP operators will not issue an integration password.entra-obo: per-user SAP identity . Per-user identity propagation to SAP through Microsoft Entra.
Reference material:
AUTH_PROFILE_SELECTION.md and auth-profiles.yaml , which is the source of truth for every claim in this post.Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 3How should an AI agent authenticate to SAP? | Agentic ERP Quickstart This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article