The approval policy: one page security and audit can sign

Everything so far becomes useful when it fits on one page that developers can follow and auditors can test. Contoso's policy for agentic development took Nadia, Sam, Luis, Kenji and Priya three meetings to write and Grace one to approve. This lesson walks through its sections and the reasoning behind each line. Use it as a template, not as a standard: your systems, contracts and risk appetite differ.

Tiers of agent use

The policy, section by section

1. 1. Purpose and scope. Coding agents used on Contoso's SAP development systems and SAP BTP development subaccounts.
2. 2. Approved tools. SAP's ADT MCP server; SAP's custom code migration agent with the assistants SAP lists; Claude Code under the corporate agreement; SAP's CAP, UI5 and Fiori MCP servers at pinned versions. Anything else is denied by managed MCP policy until reviewed.
3. 3. Identity and access. Per-developer _AGT users in CMD only, role ZCMC_AGENT_DEV; no shared users; ADT MCP access restrictions on.
4. 4. Agent configuration. Managed settings: Manual as the starting mode, bypass and (for the pilot) auto mode disabled, feedback command disabled, deny and ask rules for ADT tools, approved MCP servers by URL or command, managed hooks only, telemetry to the central store.
5. 5. Change control. One request per change; reviewed diff with two approvals for agent changes; only people release; Luis imports.
6. 6. Data. No production data in agent-accessible clients; feed tool denied; data preview only on approval; local transcripts retained for a short, set period.
7. 7. Evidence and audit. Trace model from lesson 4; monthly random trail test; findings reported to Grace's steering group.
8. 8. Incidents. Suspected injection or misuse: lock the _AGT user, regenerate the ADT MCP token, preserve logs, review recent requests from that user.
9. 9. Review. Quarterly, and after major SAP or agent releases; owner Nadia.

Making it testable

Auditors test policies by sampling. Every line above maps to something they can check: the role definition in PFCG, the user list in CMD, the managed settings file on a sample of laptops, the MCP policy, the review records, the Security Audit Log filter, the monthly trail test results. If a line can't be tested, rewrite it until it can. "Developers use agents responsibly" isn't testable; "agent users hold no S_TRANSPRT activity 43" is.

Write the policy for the people who follow it, too. Developers need to know, in one glance, what they may do today and how to ask for more. Contoso publishes the tier table and the onboarding flow on the team wiki, links the managed settings file so anyone can read what is enforced, and keeps a short list of "things the agent will refuse and why", so a blocked tool call reads as policy working rather than a broken tool. Expect the first version to be wrong in places. The quarterly review exists to fix it with evidence: prompts that fire too often, findings from trail tests, and new capabilities from SAP and the agent vendor.