Security & data flow

Your code stays yours.

Plain answers to the questions security teams ask about CSPeach. No badges, no certification logos — just how the data actually moves, so your architects can verify it themselves.

How it reaches SAP

Laptop-direct. Nothing in between.

The cspeach CLI runs on the developer's machine and talks to your SAP system over ADT REST — the same protocol Eclipse ADT uses — directly from the laptop. ADT traffic never transits CSPeach servers, in any mode. SAP credentials (user and password; certificate logon is not available yet) stay in the laptop's OS keychain.

Where your data goes Managed is the standard mode; enterprise customers can run the model in their own Azure subscription. Your ABAP goes from your laptop straight to your SAP system over ADT, in every mode, with nothing in between. In every mode the CSPeach server handles sign-in and licence and serves the signed skills and routing instructions, which the laptop checks. In managed mode, the standard mode, prompts also go through the CSPeach server at api.cspeach.dev to the AI model, so usage can be metered. In the enterprise option, prompts go from the laptop to the model in the customer's own Azure subscription and never reach us. The CSPeach server never reaches your SAP system. Our side Your side In every mode Sign-in, signed skills and routing. Managed prompts use this path too. Managed, our standard mode Prompts pass through us, so we can meter usage. The model in your own Azure · enterprise Prompts go to your Azure. They never reach us. Your ABAP goes straight to SAP Over ADT, in every mode. Nothing in between. CSPeach server api.cspeach.dev Sign-in and licence Signed skills and routing instructions Usage metering for managed prompts Never reaches your SAP system AI model The model provider Your laptop Runs the cspeach CLI Your SAP system Runs the checks and activation Your own Azure The AI model, in your own subscription
ADT traffic never transits CSPeach servers, in any mode.

Stays on your side

laptop ↔ your SAP · never transits cspeach.dev
  • ABAP source reads and writes — every ADT call goes laptop → SAP
  • SAP credentials — OS keychain on the developer's machine
  • CSPeach sign-in key — OS keychain on the developer's machine; a file in the profile only where no keychain is available
  • Syntax checks, ATC runs, activations, transports
  • Snapshots taken before every write — stored locally
  • SAP audit identity — the real developer in CHANGE_LOG, not a bridge user

Touches our side

Sign-in and signed skills in every mode. Prompts only in managed mode.
  • LLM prompts and responses, in managed mode — a prompt carries the code the task reads: the objects your developer names, and what CSPeach opens to do that work. That prompt transits our proxy on its way to the model provider, which today is Anthropic
  • Usage metadata — skill, tokens, model, cost, for metering and billing
  • Account and licence — from sign-in (device-code flow). Revoking a seat stops CSPeach on it in every mode: in managed mode at the next request; otherwise at the next start or licence check (every 4 hours), and within 72 hours of its last successful check on a laptop that cannot reach us. It is a licence check on the developer's machine: a deterrent backed by the install list, not a lock that cannot be worked around
  • Skills and routing instructions — signed; skill text is served only to signed-in seats and checked on the laptop. Any licensed seat can read it: this is licence control, not secrecy

Source your team never shares with a skill never leaves SAP. We walk through the full architecture in a demo. Book a demo.

Where the AI runs

Managed is our standard mode.

The SAP path is identical in every mode. What changes is where the AI call goes. In managed mode it goes through our proxy.

Managed, and the model in your own Azure Managed is the standard mode; enterprise customers can run the model in their own Azure subscription. In managed mode, prompts go from the laptop through the CSPeach server at api.cspeach.dev to the AI model, so usage can be metered, and sign-in, signed skills and routing come from the same server. In the enterprise option, prompts and responses go from the laptop to the model in the customer's own Azure subscription and never reach us; sign-in and signed skills still come from the CSPeach server. In every mode your ABAP goes from the laptop straight to your SAP system over ADT. Managed, our standard mode Your laptop Runs the cspeach CLI CSPeach server api.cspeach.dev AI model Anthropic, today Prompts Prompts Prompts pass through our server, so we can meter usage. Sign-in, signed skills and routing come from it too. The model in your own Azure · enterprise Your laptop Runs the cspeach CLI CSPeach server Signed skills and routing Your own Azure The AI model, yours Sign-in, skills Prompts and responses Prompts and responses go from the laptop to the model in your own Azure. They never reach us. In every mode Your laptop Runs the cspeach CLI Your SAP system Checks and activation Your ABAP goes straight to SAP Over ADT, the same in every mode. Nothing in between.
The SAP path is identical in every mode.
LLM modes on the roadmap Two modes still to come. With SAP AI Hub the laptop's prompts go through a customer-side translation proxy to your own SAP AI Core in your BTP tenant. With Local the model runs on your own hardware, so no AI call leaves the machine at all. The laptop-to-SAP leg over ADT REST is the same one every mode uses. WHERE THE AI RUNS Two more modes on the roadmap. STAYS ON YOUR SIDE YOUR BTP YOUR OWN HARDWARE SAP AI Hub On the roadmap Local On the roadmap ADT REST PROMPTS Your laptop cspeach CLI Your SAP system IDENTICAL IN EVERY MODE A translation proxy CUSTOMER-SIDE Your SAP AI Core your AI Core token A local model No AI call leaves the machine.
Two more modes are on the roadmap.
Standard · default

Managed

Our own model key, on our proxy. Prompts and responses transit api.cspeach.dev so we can meter and bill per use. Lowest-friction way to start.

Enterprise

The model in your own Azure

Managed is our standard mode: CSPeach calls the model through our service. For enterprise customers, the AI model can also run in the customer's own Azure subscription; ask us.

On the roadmap

SAP AI Hub

Your AI Core token, your BTP tenant. LLM traffic goes laptop → your SAP AI Core. Requires a customer-side translation proxy.

On the roadmap

Local

A local model on your own hardware. No AI call leaves the machine. For teams whose policy rules out any external AI call.

What the model provider does with your prompts

In managed mode, CSPeach calls Anthropic only through its commercial API. The provider's published terms say it does not use API inputs or outputs to train its models by default, and that it deletes them within 30 days — unless it has to keep them longer to enforce its usage policy or to comply with the law.

These are the provider's terms, not ours. We link them so you can read them yourself: no training on API traffic by default and deletion within 30 days.

As published in September 2026

Write safety

Every write is gated, logged, reversible.

CSPeach can write to your SAP system — that's the point. It does so under ten Forge Rules embedded in every skill. The developer approves the writes: one by one, or, in a plan run, once for the plan's exact object list. Anything off the list still asks. So does any delete, another package or transport, and the deploy. The approvals = per-write setting restores a card before every write.

Every change takes the same road A write starts because you asked. For multi-object work the agent lays out a plan you approve, then it snapshots, writes, runs a syntax check, activates, and confirms the object really went active. If either check fails, CSPeach fixes the object and checks again, up to three tries, and takes the write again. When it still cannot pass, or the next step is one only a person can do, it stops and says what it needs; you do that step and it carries on from there. The whole road sits in the session’s transport, or in the request that already holds the object, and stays on the record. THE PATH OF A WRITE Every change takes the same road. THE SESSION’S TRANSPORT · R9 ON THE RECORD · /export audit PASSES FAILS FAILS TRIES AGAIN STILL FAILING, OR IT NEEDS YOU YOU DO THE STEP · IT CARRIES ON You ask R8 A plan you approve MULTI-OBJECT WORK R7 Snapshot Write Syntax check R10 · EVERY WRITE Activate Activation check REPORTS IF IT DIDN'T It stops and asks you SAYS WHAT IT NEEDS CSPeach fixes it and checks again UP TO THREE TRIES Broken code is never activated. The snapshot from before the write is there if you want to go back.
Writes happen only when you asked for them. A failed check is fixed and checked again; broken code is never activated.
R1No blind generation. It asks the missing questions before touching anything.
R6Read-only by default. Writes happen only when you asked for them.
R7Snapshot before every write. The prior state is captured first — always a way back.
R8No batch without a plan. Multi-object changes need your approved plan, object by object.
R9Transport isolation. A session writes to the session's transport. An object already locked in a request stays in that request, and the card says so. In a team project, every write card names the project's request.
R10Verify after every write. Syntax check, then activation check. A failure is fixed and checked again, or CSPeach stops and asks you.

Your administrator can also set one of SAP’s four access levels per system. How CSPeach sits next to SAP’s ABAP tools.

Telemetry

What we collect. Stated plainly.

The CLI sends no analytics or telemetry events today. There is a telemetry setting in the CLI config (default minimal) reserved for future use — no emitter is wired to it. If that changes, this page changes first.

What our servers do see: in managed LLM mode, your prompts and the model's responses transit api.cspeach.dev on their way to the model provider, and we record usage metadata — skill, tokens, model, cost — to meter and bill. Your account email from sign-in, and the computer name and a machine id for each computer a seat signs in from, so you and we can see where a seat is used. That's the list.

What our servers never see: your ADT traffic, your ABAP source outside the prompts you choose to send, your SAP credentials, your SAP system addresses.

Usage counts. When CSPeach runs on a model outside our proxy (the enterprise option above), the CLI sends usage counts only: seat, skill, model, token counts, turn time, CLI version, session id and a request id. Never prompts, responses, code, object names, SAP system ids or file paths. usage_reporting = "off" in the CLI config turns them off. In managed mode our proxy records the same metadata as before.

Commands on the laptop. Running commands is off by default. When it is on, only listed build commands run, and known risky patterns ask for approval every time, even inside an approved plan: code passed on the command line, git setting changes, network tools, commands that name a deploy or publish, and reads of files such as .npmrc or *.pem. A run with no person at the keyboard declines them.

In the same spirit of honesty

What's not ready yet.

The lifecycle we show in a demo is live today — including SAP writes, RAP end-to-end, ATC and transports. A few edges aren't finished, and we'd rather you hear it from us:

  • ABAP Unit execution — /abap-test writes test classes, but running them from the CLI doesn't work yet. Run them in Eclipse for now.
  • SEGW, number ranges, message classes — guidance-only in places where the needed SAP APIs don't exist on modern systems. The skill tells you the exact GUI steps instead of doing them.
  • Fiori app testing — /abap-fiori-build builds the app, previews it against your system and checks that it renders. It does not write automated UI checks for it.
  • S/4HANA Cloud Public Edition and SAP BTP ABAP Environment — not tried yet. CSPeach has run on ECC EHP7+, on-premise S/4HANA and S/4HANA Cloud Private Edition.
  • One model provider — in managed mode, every CSPeach call goes to the model provider named above; in the enterprise option, the model runs in the customer's own Azure subscription. SAP AI Hub, and a local model on your own hardware, are two more places it could go.
  • A BTP lane — for shops that need every tool to go through their own BTP. Designed. Not built yet.
  • CAP apps on BTP — CSPeach builds and checks a CAP app on the developer's laptop. Deploying it to BTP is the next step. Not built yet.
  • SAP single sign-on — CSPeach logs on to SAP with the developer's user and password. SNC, SAML and certificate logon don't work yet; standalone mode needs no SAP logon at all.

Security contact

Report a problem. Hear from us if one affects you.

Reporting a vulnerability. Email [email protected] with what you found and how to reproduce it. We read every report, confirm we received it, and keep you updated while we fix it. Please give us a reasonable time to fix an issue before you publish it, and do not access or change data that is not yours while you test. The same contact is published in machine-readable form at /.well-known/security.txt.

If an incident affects you. We notify affected customers within 72 hours of confirming a security incident: what happened, what data was involved, and what we are doing about it.

Who else handles data. The services our backend and website use, what each one does and where, are listed on the trust page.