SAP systems hold financial records, purchase orders, vendor master data, and HR payroll. An agent with write access to SAP via official API can post journal entries, approve purchase requisitions, or modify supplier bank details. Prompt-level instructions alone cannot prevent a misconfigured or compromised agent from executing these actions; you need machine-enforced policy gates that restrict which API calls are permitted, scope credentials to specific operations, and produce tamper-evident audit records for every model-assisted action.
Claw EA connects to SAP via official API with enterprise buildout controls. This integration is planned and requires WPC approval gates, scoped tokens (CST), and explicit least-privilege auth scopes before any write or admin action reaches SAP.
Step-by-step runbook
- Map the SAP surface. Identify which SAP APIs the agent needs (e.g., OData services for purchase orders, BAPI wrappers for goods receipt). List every endpoint and HTTP method. Read-only endpoints go in one group; write and admin endpoints go in another.
- Author a Work Policy Contract (WPC). Encode the allowed SAP endpoints, HTTP methods, and business object types into a signed WPC. The WPC is hash-addressed and stored in the clawcontrols registry, so any modification produces a different hash and fails verification.
- Issue a scoped token (CST). Use clawscope to mint a CST pinned to the WPC's policy hash. The CST limits the agent's session to the exact SAP operations declared in the contract. Pin it to a specific job ID for anti-replay binding.
- Configure the OpenClaw agent. OpenClaw is the baseline agent runtime. Set the agent's tool policy to deny all SAP write tools by default, then allow only the endpoints listed in the WPC. Run the agent in sandbox mode to contain tool execution.
- Route model calls through clawproxy. All LLM inference passes through clawproxy, which emits gateway receipts for each model call. These receipts record the prompt hash, model identifier, and timestamp.
- Execute and collect proof. When the agent completes its SAP task, a proof bundle is assembled containing gateway receipts, the WPC hash, and the CST binding. Store the resulting Trust Pulse artifact for audit viewing.
- Review and rotate. After each job, verify the proof bundle. Rotate the CST. If the WPC needs changes (new endpoints, broader scope), a new contract must be signed and a new hash issued.
Threat model
| Threat | What happens | Control |
|---|---|---|
| Agent posts fraudulent journal entries | Financial statements are corrupted; regulatory exposure | WPC restricts allowed transaction codes and API endpoints; CST scoped to read-only unless explicit write approval exists |
| Prompt injection via SAP notification text | Attacker-controlled text in a purchase order description tricks the agent into approving or modifying records | OpenClaw sandbox isolates tool execution; tool policy denies elevated actions; gateway receipts capture the model call that preceded the action |
| Credential over-provisioning | Agent's SAP service account has SAP_ALL or broad authorization objects, enabling lateral movement across modules | CST is pinned to a specific policy hash; the WPC enumerates exact OData paths and methods; SAP-side service account uses least-privilege authorization objects |
| Replay of a previous job's token | Old CST is reused to execute unauthorized SAP operations | Marketplace anti-replay binding ties CST to a specific job ID; reuse in a different context fails validation |
| Agent modifies vendor bank details | Payment fraud via supplier master data manipulation | WPC excludes vendor master write endpoints; any attempt to call them is blocked before reaching SAP |
Policy-as-code example
{
"wpc_version": "1.0",
"name": "sap-po-read-agent",
"target": "sap",
"connection": "official_api",
"auth": {
"type": "oauth",
"scope": ["API_PURCHASEORDER_2.read"]
},
"allowed_operations": [
{
"service": "API_PURCHASEORDER_2",
"methods": ["GET"],
"entity_sets": ["A_PurchaseOrder", "A_PurchaseOrderItem"]
}
],
"denied_operations": [
{
"service": "API_PURCHASEORDER_2",
"methods": ["POST", "PATCH", "DELETE"]
},
{
"service": "API_BUSINESS_PARTNER",
"methods": ["*"]
}
],
"cst_binding": {
"policy_hash_pinned": true,
"max_ttl_seconds": 900
}
}This WPC allows the agent to read purchase orders but blocks creation, modification, and deletion. It also denies all access to the Business Partner API, preventing vendor master changes. The CST is pinned to this policy hash and expires after 15 minutes.
What proof do you get?
Every model call the agent makes is routed through clawproxy, which emits a gateway receipt containing the prompt hash, model identifier, response hash, and timestamp. These receipts are signed and cannot be altered after the fact.
At job completion, receipts are bundled with the WPC hash and CST metadata into a proof bundle. This bundle is the single artifact an auditor needs to reconstruct what the agent was allowed to do, what model calls it made, and whether the policy was respected throughout execution.
The proof bundle is stored as a Trust Pulse artifact, viewable in the marketplace. For SAP-regulated environments (SOX, GxP), this gives you a per-job audit trail that ties agent behavior back to a specific, immutable policy contract. Transparency log inclusion proofs are planned and can be added when available.
Rollback posture
| Action | Safe rollback | Evidence |
|---|---|---|
| Agent posted an incorrect goods receipt | Reverse the material document in SAP using standard reversal transaction; revoke the CST immediately via clawscope | Proof bundle shows the exact model call and WPC that authorized the action |
| CST leaked or suspected compromise | Revoke the CST; issue a new one with a fresh job binding; no SAP credentials are embedded in the CST itself | Revocation event logged in clawscope audit trail |
| WPC found to be overly permissive | Publish a new, tighter WPC with a new hash; old CSTs pinned to the previous hash become invalid for new jobs | Old and new WPC hashes are both in the clawcontrols registry for comparison |
| Agent ran against wrong SAP tenant | Kill the agent session; CST anti-replay binding prevents the same token from being used on a different job | Gateway receipts show which model calls were made; proof bundle ties them to the specific CST and WPC |
FAQ
Is the SAP integration available as a native connector today?
No. SAP connectivity is planned and requires enterprise buildout. The agent connects to SAP via official API using OAuth, API key, or service account authentication. Write and admin actions require WPC approval gates and scoped tokens before any call reaches SAP.
Why can't prompt instructions replace policy-as-code for SAP?
A prompt instruction like "do not modify vendor bank details" is advisory. The model can ignore it, especially under prompt injection. A WPC is a signed, hash-addressed artifact that is enforced at the execution layer before the API call is made. The agent never gets the chance to call a denied endpoint.
How does this work with SAP's own authorization model?
Claw EA's controls operate as an outer boundary. The SAP service account should still use least-privilege authorization objects (e.g., restrict to specific company codes or purchasing organizations). The WPC adds a second, agent-specific layer that is independent of SAP's internal role assignments.
Can the agent use SAP's Joule alongside Claw EA controls?
Joule is SAP's embedded AI copilot with its own interaction patterns. If your agent calls SAP APIs that Joule also uses, the WPC and CST controls apply to your agent's calls regardless. Joule's own security model is managed within SAP BTP.
What happens if automatic cost budget enforcement is needed?
Automatic cost budget enforcement is planned. Today, you can set a short CST TTL (e.g., 15 minutes) and limit the number of allowed operations in the WPC to bound exposure. Per-call cost tracking is available through gateway receipts.