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/password or X.509) stay in the laptop's OS keychain.

Where your data goes 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 default, prompts also go through the CSPeach server at api.cspeach.dev to the AI model, so usage can be metered. Your own model key, with prompts going straight to the model, is a future option and not offered today. 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, the default Prompts pass through us, so we can meter usage. Your own model key: a future option, not offered today. 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
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 today. Other modes are for the future.

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

LLM mode today, and a future option Managed, the default and the one mode offered today: 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. Future option, not offered today: your own model key, with prompts and responses going from the laptop straight to the model. In every mode, your ABAP goes from the laptop straight to your SAP system over ADT. Managed, the default 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. Future option: your own model key Your laptop Runs the cspeach CLI CSPeach server Signed skills and routing AI model Anthropic, today Sign-in, skills Prompts and responses Not offered today. Prompts would go from the laptop straight to the model. 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.
Today · 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.

Future option

Your own model key

Not offered today. It is an option for the future, for companies that need prompts to go from the laptop straight to the model provider, on their own key and their own contract. Today every CSPeach call runs managed.

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

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.

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 (a future 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 — every CSPeach call goes to the model provider named above. SAP AI Hub, and a local model on your own hardware, are two more places it could go.
  • Your own model key — not offered today. Every CSPeach call runs managed, through our proxy. Your own key is an option for the future.
  • 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.