A threat model for coding agents on SAP systems

Kenji's team wants to use coding agents on ABAP in CMD: SAP's custom code migration agent for remediation, and a general coding agent through SAP's ADT MCP server for new work. Before Nadia, Contoso's security and GRC lead, signs anything, she asks the question every security review starts with: what can go wrong, and how bad would it be? This course answers it for security, Basis and release managers, and ends with a one-page policy that security and audit can sign. It uses Claude Code as the concrete example on the agent side, because its controls are well documented; the principles apply to any agent.

What makes an agent different from a developer

A coding agent is a program that reads context, decides on actions and executes them through tools: files, shell commands and MCP servers such as SAP's ADT MCP server, whose tools create objects, activate them, run ATC and ABAP Unit, create transport requests and read runtime feeds such as short dumps. Three properties drive the risk. It acts fast and in volume. It takes instructions from whatever it reads, not only from its user. And it can't be held accountable; a person always has to be.

Six threats

Prompt injection in an SAP setting

OWASP's GenAI Security Project ranks prompt injection first among LLM risks and separates direct injection (the user's own prompt) from indirect injection (instructions hidden in content the model processes). On SAP systems, indirect injection has plenty of carriers: fifteen-year-old comments, long texts in custom tables, message texts, ticket descriptions pasted into the chat, and short dumps that echo user input. SAP's own security considerations for the ADT MCP server warn that prompt injection attacks may compromise the client system. OWASP's mitigations map well to SAP: least privilege, human approval for high-risk actions, segregating external content and adversarial testing.

Two properties of SAP landscapes make these threats worse than in a typical web project. First, development systems are rarely empty: converted systems like CMD start as copies of production, and even after masking they hold realistic master data, customizing and sometimes forgotten business documents. Second, the path from development to production is short and well greased. A change recorded in a request in CMD is one release and two imports away from CMP, and in a busy release window those steps happen in bulk. An agent that slips a change into the right request rides that path unless something stops it. That is why this course puts so much weight on who may release, and on review before release.

A threat model is also a scoping tool. Some agent uses barely touch these threats: explaining an ATC finding in a read-only session, or drafting unit tests that a developer copies by hand. Others touch all six: an agent that changes code, creates requests and reads dumps in a system with copied data. The approval policy in lesson 6 uses that difference to set tiers, so low-risk uses don't carry the overhead of high-risk ones.