Most cautious
advisory-only
Proposes, never writes
The agent reads, reviews and drafts. It shows you the change but cannot apply it. The mode a production system is pinned to.
CSPeach is an AI coding agent that can change your SAP system — that's the point.
It stays read-only until you ask. Every overwrite is snapshotted first, every change goes
in the session's transport (or the request that already holds the object), syntax-checked, activated, and verified. And you can pin any system to
advisory-only, so on that system the agent proposes and never writes.
The write gate
One setting decides the agent's reach on each system. It ships at
approval-gated — the agent asks before every write, or once for a
plan's exact object list. Set approvals = per-write and plans ask
before every write too. Move it up for speed, down for caution.
Proposes, never writes
The agent reads, reviews and drafts. It shows you the change but cannot apply it. The mode a production system is pinned to.
Asks before each write, or once per plan object list
Outside a plan run, the agent does the work but pauses at every write, showing you exactly what it will change. In a plan run you approve the plan's object list once; anything not on it pauses again. Nothing lands without your yes.
Writes within the session
For trusted, non-production work. The agent writes without a prompt per change — every overwrite still snapshotted, and every change syntax-checked and verified.
advisory-only — the agent cannot be talked, prompted or
configured past that ceiling mid-session, and even a snapshot restore is blocked on a pinned
system. The safe setting is the one that can't be nudged.
The gates
When the agent does change something, it passes through the same gates in the same order — the rules are built into every skill, not bolted on. Here is that road, gate by gate.
Nothing changes on its own. The agent reads your code, runs checks and answers questions. A write happens only because you asked for one.
Before it overwrites or deletes a source, the agent captures the prior state. There is always a version to go back to — no exceptions, even for a one-line fix.
When a job touches more than one object, the agent lays out the full plan — object by object — and waits for your go before it starts. No surprise mass changes.
A session writes to the session's transport. One exception: if SAP already holds the object in a request, the change stays in that request, and the card says so: “object already locked here”. In a team project, the lead names one request at the start, and every write card names the request it goes to.
After a write, a syntax check runs. If it fails, CSPeach fixes the code and checks again — broken code is never activated. If it still cannot pass, it stops and asks you. After activation, the agent confirms the object really went active, and reports if it didn't.
Every write is part of the session record. Run /export audit and the agent writes out a reviewable file of what it did — the trail you hand to a lead or an auditor.
And a way back. Because every overwrite is snapshotted, a change to existing code can be
restored. Press Esc twice to rewind through the write gates — the same
ceilings apply, so a restore is blocked on a system pinned to advisory-only.
Whose hands
It works through the developer's own SAP logon — so your system's own controls decide what it can touch, and your audit log names a real person.
The agent connects as the developer's own SAP user and inherits exactly that user's privileges. It cannot reach an object the developer couldn't reach, and it holds no elevated or shared service account of its own.
SAP authorization checks are never bypassed. Whatever your roles allow is the limit; whatever they deny stays denied.
Because the agent acts as the real developer, your change documents and change logs name that person — not a bridge user. The session's own record is exportable on demand with /export audit.
The result is a reviewable account of what changed, in which transport, by whom — the kind of trail a release or audit process expects.
Where the AI runs
The path to SAP is laptop-direct in every mode. In managed mode, our standard mode, the AI call goes through our proxy.
Start with our proxy and our own model key. Prompts transit api.cspeach.dev on the way to the model provider, which today is Anthropic, so we can meter usage. The lowest-friction way to begin.
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.
The full list of modes — including SAP AI Hub and local options for the future — plus the full data-flow and a plain telemetry statement, is on the security page.
Subprocessors
These are the outside services our backend and website use today, what each one does for us, and where. Your SAP system and the ADT traffic to it are not on this list: they stay between the developer's laptop and SAP.
What for: hosting our backend: the application, the database, the cache, the secrets vault, the container registry and our operational logs.
Data: accounts, seats, usage metadata, billing records and, in managed mode, prompts in transit on the way to the model provider.
Where: United States. The application, cache and vault run in East US 2 (Virginia); the database runs in Central US (Iowa), with its backups copied to the paired US region.
What for: running the AI model, in managed mode.
Data: the prompts and responses of each request: the code and text the task sends. Its handling of that data is described on our security page.
Where: the provider's published terms say data is stored in the United States, and that processing may run in other regions (the provider names the US, Europe, Asia and Australia) unless US-only processing is set for the account. Our account does not set it today. This entry is updated when the provider's terms or our account setting change.
What for: subscriptions, invoices and card payments.
Data: the billing email address, the amounts we charge, and the payment details you enter on Stripe's own checkout and billing pages. Card numbers go to Stripe and never reach our servers.
Where: United States.
What for: sending our emails: sign-in links, invitations and account notices.
Data: the recipient's email address and the message we send.
Where: United States.
What for: sign-in for our own staff to the CSPeach admin console.
Data: our staff's GitHub user names. No customer data.
Where: United States.
What for: web fonts on this website and the videos embedded in its pages.
Data: what the visitor's browser sends when it loads a font or a video: IP address and browser details. Nothing from the product or your SAP system.
Where: a global network that serves each visitor from a nearby location.
What for: DNS for cspeach.dev and serving this website and its static pages. Calls to api.cspeach.dev go straight to our Azure backend and do not pass through it.
Data: what any web host sees from a website visit: the visitor's IP address, browser and the pages requested.
Where: a global network that serves each visitor from a nearby location. We name the provider on request.
Questions about this list: [email protected]. How we handle security reports and incidents is on the security page.
One more thing, plainly
This page carries no compliance logos and claims no certifications, because we won't put a badge here we haven't earned. What it describes instead are mechanisms that are live in the product today: the write gate, the snapshot, the transport, the checks, the audit file.
We describe them; your team verifies them. If you want to see the road a write takes for real, book a demo — we run a real session on a real system.