Connect an AI agent to SAP with a technical user account | Agentic ERP Quickstart
The default path: a technical SAP user in AWS Secrets Manager, synced with one command. What that verification record proves, and what it does not cover.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 4Connect an AI agent to SAP with a technical user account | Agentic ERP Quickstart This article
Connect an AI agent to SAP with a technical user account | Agentic ERP Quickstart
The default way to connect an agent to SAP is a technical user account, and it is the right default for one honest reason: it works without asking your identity team for anything. It also means SAP records every action the agent ever takes under a single name, which is a bill that comes due at audit time rather than at deployment time. This post wires that path end to end, keeps the password out of every log and command line on the way, and is precise about what the profile's verification record does and does not establish.
Series: Building governed ERP agents on AWS · Series guide →
This post: How to wire the default profile end to end, and what its verification record does and does not prove.
Prereq: A running deployment from the deploy walkthrough , an SAP administrator who can create a technical user, and an approved network route to your SAP OData endpoint.
What you get from this post
By the end, the scheduled poller reads real SAP data using a technical user's credentials, stored in AWS Secrets Manager and synced with one command. You also get:
- A clear picture of the two separate paths to SAP in this deployment, and why configuring one does not configure the other.
- The SAP-side checklist to hand your SAP administrator.
- A credential sync that never puts a password in a log, a file, or a command line, plus the one refresh behavior that can fool you into thinking it did not work.
- Two validation checks, and what each one proves on its own.
Time: about 30 minutes of configuration, plus SAP administrator time.
You will need: an AWS account with the Quickstart deployed, SAP administrator access, and network connectivity to your SAP OData endpoint.
You will need: an AWS account with the Quickstart deployed, SAP administrator access, and network connectivity to your SAP OData endpoint.
IMPORTANT
Syncing the poller's SAP credentials does not give the agent SAP tools. Those are two independent pieces of work, and the second one needs a separately deployed AWS for SAP MCP Server. If you only do the first, the poller will read SAP and the agent still will not.
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.
One setting in
cdk/config.yaml, called auth_profile, selects a matching set of identity choices across all of those pieces. This post covers cognito-basic, the default. The auth profile overview compares it against the alternatives.Why start here
This is the path most teams should begin with. It needs no external identity provider, and it is the profile with a recorded end-to-end verification run against live SAP. That combination makes it the fastest way to get real SAP data in front of a real agent.
The trade is attribution. Every request SAP sees comes from one technical account, not from the person in the browser. For an evaluation that is fine. For production it should be a decision someone makes on purpose, and writes down.
So when you design authorizations or read audit logs, treat every request on this path as belonging to the technical user, because that is what SAP records. If you need SAP to see the individual person, that is the
entra-obo path , along with the extra setup it requires.Understand the two SAP paths first
This deployment reaches SAP in two different ways, and they are configured separately:
- The scheduled OData poller is the only component here that calls SAP directly. It reads Basic credentials from Secrets Manager and polls for exceptions.
- The agent does its SAP discovery, reads, and writes through the separately deployed AWS for SAP MCP Server. That external runtime owns its own SAP authentication configuration, and it can use the same Basic technical-user credentials toward SAP.
Steps 1 through 3 below get the poller working. Step 4 covers the agent path, which is separate work.
Step 1: Set the profile and the SAP endpoint
The profile is a top-level key in
cdk/config.yaml. The SAP endpoint goes under sap:1
2
3
4
auth_profile: cognito-basic
sap:
base_url: https://your-sap-host:443If your SAP endpoint is private, set
backend.network_mode: VPC and supply the required VPC settings.WARNING
The CDK stack does not create VPC peering, a VPN, AWS Direct Connect, or SAP security group rules. Those stay with your network team. Confirm the deployed runtime can actually reach the endpoint before you start debugging credentials, because a blocked route and a bad password look similar from the application side.
Step 2: Prepare the SAP technical user
The SAP-side procedure depends on your environment, so work through it with your SAP administrator. Ask for four things:
- Create or reuse a non-dialog technical user.
- Grant only the OData services and business authorizations this deployment needs.
- Activate those services and their SICF nodes, which is the SAP transaction that controls whether an HTTP service is reachable.
- Validate one read-only OData request with that user's credentials, before any AWS configuration is involved.
The exact authorizations depend on which services and business scope you deploy. Do not copy authorization objects or values from an unrelated SAP system into a production role. Record the SAP release and the service list in the operator notes that go with the deployment.
Step 3: Sync the credentials
The infrastructure deploy creates an empty secret and its parameter reference. Once that exists, run:
1
python3 launch.py sync-sapThe launcher reads
sap.base_url from cdk/config.yaml, prompts for the username and password, and writes a new version of the secret. The password is read without echo. It is not written to disk, to logs, or to command arguments.After it stores the new credentials, the launcher refreshes the components that consume them. One behavior is worth knowing here:
NOTE
If that refresh is skipped or partly fails, a running process can keep using cached credentials until its next cold start. So a failed refresh is an operational item to chase, not proof that the new password is unused. Confirm the change took effect with a fresh call rather than assuming either way.
Two things to avoid. Do not use older helper scripts that pass a plaintext password as a process argument. Do not paste a retrieved secret value into a terminal transcript, a ticket, or a public troubleshooting thread.
Step 4: Configure the agent's SAP path separately
To give the agent SAP tools, deploy and configure the external AWS for SAP MCP Server in its BASIC mode, then enable this repository's SAP MCP adapter. The external stack owns its runtime, its SAP credentials and provider configuration, its scopes, and its write-enable settings.
Once SAP MCP is enabled, this profile gets a Gateway Service target, and the credential changes at each hop:
1
2
3
4
1. Agent asks for SAP data
2. AgentCore Gateway Service target, reached with a Cognito machine token
3. AWS for SAP MCP Server reached with an OAuth 2.0 client-credentials token
4. SAP OData service reached with the Basic technical-user credentials
IMPORTANT
"Basic" names the last hop only. It does not mean the whole chain uses Basic authentication, and it does not mean there is no Gateway target. People plan around both of those misreadings.
That last hop is the only thing the
cognito-m2m setup changes. Switching to cognito-m2m swaps the external runtime's username and password for an SAP-issued bearer token, and leaves the Cognito sign-in, the runtime authorizer, the Gateway Service target, and the poller's Basic credentials exactly as they are here.Step 5: Validate, with two separate checks
Run both, and record the results against the deployment commit you tested:
| Check | What it proves | What it does not prove |
|---|---|---|
| The poller log shows a successful SAP OData read | The network route, the stored secret, and the poller's Basic authentication all work | That agent-driven SAP access is configured at all |
| The agent completes a SAP read through the external MCP runtime | The agent topology and the external MCP-to-SAP configuration work | Per-user SAP identity, which this profile never provides |
Do not expose real secret values while validating. When authentication fails, separate a network failure from a 401 and a 403 before you start changing SAP roles or rotating credentials. Those three symptoms point at three different teams.
Write controls and audit boundaries
Give the technical user only the SAP permissions the intended services require. That is the layer SAP enforces itself, and it is the one that matters most.
Beyond it, two more layers can reduce exposure:
- The external MCP runtime decides which write tools exist at all, through its own deploy-time global and per-operation flags.
- Cedar policy at the Gateway can gate
odata_create,odata_update, andodata_function_importby role, and forbidsodata_deletefor its Gateway service target.
That Cedar layer only blocks anything when all three of these are true:
- the request goes through the relevant Gateway target,
- the policy engine is deployed, and
cedar_enforcement_mode: ENFORCEis set.
The default is
LOG_ONLY, which records decisions without blocking them. The policy also does not cover the direct-to-MCP path used by entra-obo. And there is no runtime write switch in the agent: trigger_mode controls whether unattended work starts on its own, not what the agent may write to SAP.Where to go next
cognito-m2m: SAP client credentials . SAP-issued OAuth 2.0 client credentials instead of a password, and what you have to validate in your own SAP system.entra-obo: per-user SAP identity . The path to take when SAP needs to record the signed-in person rather than a shared account.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 4Connect an AI agent to SAP with a technical user account | 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