Lesson 2 of 6
SAP-side controls: users, authorizations, systems and transports
9 min
Listen to this lesson
Agent-side controls can be misconfigured, switched off or bypassed by a creative shell command. SAP-side controls hold regardless of what the agent's software does, because the ABAP system enforces them. Start here, and treat agent-side controls (lesson 3) as a second layer.
Whose identity does the agent use?
SAP's ADT MCP server runs locally inside ADT for Eclipse or VS Code: it starts an HTTP server on localhost (by default port 2234 in Eclipse, 2236 in VS Code) protected by an auto-generated bearer token, and works through the ABAP projects configured in that ADT installation. Changes it makes in the system are therefore made under the user that the ADT project logs on with. That is the key design decision.
| Option | How it works | Strengths | Weaknesses |
|---|---|---|---|
| Developer's own user | Agent uses the developer's normal ADT project | Simple; SAP's documented setup | Agent has every right the developer has; SAP logs can't tell human from agent |
| Separate restricted user per developer | A second ADT project logs on with an agent user that has a narrower role; ADT MCP access restrictions allow only that project | SAP-side least privilege; version history and logs show the agent user | More users to manage; check licensing and user policy with your SAP contract owner |
| Shared technical user | One user for all agent activity | Few users | No personal accountability; credentials shared; avoid |
Identity options for agent work through ADT, with trade-offs.
Contoso chooses the second option. Each developer who uses agents gets a second user in CMD only, named after them with an _AGT suffix (for example KENJI_AGT), with role ZCMC_AGENT_DEV. Nadia's reasoning: SAP-side least privilege can't be negotiated away by an agent, and every change in version history shows whether a human or an agent session made it. Sam confirmed the user type and licensing treatment with Contoso's SAP contract owner before rollout.
Agent users get no SAP GUI logon need beyond what ADT requires, no access to transactions outside development, and passwords managed like any other personal credential. They are locked automatically if the matching developer leaves, and reviewed in the quarterly access review like any other user. When a developer stops using agents, the _AGT user is locked rather than deleted, so its change history stays readable.
The agent role
| Authorization | Developer role | ZCMC_AGENT_DEV |
|---|---|---|
| S_DEVELOP (repository objects) | Change in all customer packages | Change only in packages listed for agent work; display elsewhere |
| S_DEVELOP with object type DEBUG | Debugging, sometimes with change | Display debugging only; never change values in the debugger |
| S_TRANSPRT | Create, change, release own requests | Create (01) and change (02) only; no release (43), no release of others' requests (75) |
| S_ADT_RES and S_RFC (SADT_REST_RFC_ENDPOINT) | ADT access | Same; needed for ADT to work |
| Table display (S_TABU_DIS, S_TABU_NAM) | Broad display in development | Limited to tables of the agent packages and test data tables |
| User and role administration (S_USER_*) | None for developers | None |
| ATC exemption approval | Quality experts only | None; exemptions are a human decision |
Contoso's agent role compared with its developer role (illustrative design).
System and client limits
- Development only. Agent users don't exist in CMQ or CMP. The laptops used for agent work have no ADT projects for CMQ or CMP under the agent user.
- No production shortcuts. Opening production in SE06 or SCC4 is break-glass at Contoso, only for settings that can't be transported. It is never opened for an agent.
- ADT MCP access restrictions on. In ADT, the MCP server's access restrictions (enabled by default) limit access to listed projects and changes to listed packages; reading is still possible in all packages, which is why table and data access is limited in the role.
- Token hygiene. The MCP server's bearer token is a shared secret between ADT and the agent. It stays out of repositories and is regenerated if exposed.
Transport controls
Release is the control point. Because the agent role has no S_TRANSPRT activity 43, the agent can't release even if it tries; the developer releases after review, with ATC checking on release. Luis's import checks from sap-aid-204 (merged pull request, request number in the review record) apply unchanged.
What would you do?
To save time, a developer asks Sam to give KENJI_AGT release authorization "just for the migration sprint", since SAP's migration agent needs transport permissions. What should Sam do?
- SAP-side controls hold whatever the agent's software does; build them first.
- SAP's ADT MCP server acts through the ADT project's user, so the identity design decides attribution and blast radius.
- Contoso: per-developer _AGT users in CMD only with role ZCMC_AGENT_DEV: package-limited S_DEVELOP, S_TRANSPRT 01 and 02 only, no debug change.
- Release stays with people; ADT MCP access restrictions repeat the package limit on the client side.
Check your understanding · not graded
Lesson check
1. Under which SAP user do changes made through SAP's ADT MCP server appear?
2. Which S_TRANSPRT activity does Contoso withhold from agent users?
3. What do the ADT MCP server's access restrictions limit by default?
4. Why does Contoso prefer a separate _AGT user over the developer's own user?