Security model
Makion is built on one principle: the AI can investigate your SAP system freely, but it can only change it under direct human control — and that control is enforced in code, not by asking the model nicely. This page explains each layer of protection so you can evaluate the product with confidence.
Makion is not affiliated with SAP SE. SAP and ABAP are trademarks of SAP SE and are used here only descriptively.
On-prem: your SAP, your server, your machine#
Everything runs on infrastructure the customer controls. The Makion backend is hosted by the customer, the SAP connector runs on the developer's own machine, and the AI login lives on the customer's own server. There is no third-party SaaS operated by Makion in the path: your SAP connection, your SAP data, your credentials, and your AI login never leave infrastructure you own.
This is a deliberate answer to the two hardest objections to AI-in-SAP — third-party access to the system, and data residency. Both are resolved by the on-prem, customer-owned design.
Read-only roles physically cannot write#
A role is a permission boundary enforced at the tool level, not a prompt request. When you pick a read-only role — Architecture, Code review, Research, and every consulting and support role — the agent is handed only the read set of SAP tools. The write tools are never passed to it.
Because the write tools were never given to the agent, there is no prompt you could write that makes a read-only role lock, set source, create, or activate anything. "Read-only" therefore means read-only in fact, not just in intent. This is what makes it safe to hand the agent an entire custom-code estate to analyze, or a production incident to triage.
Object deletion is permanently disabled — for every role#
No role in Makion can delete an SAP object. The delete operation is disabled unconditionally — for read-only and write roles alike — and the request is blocked before it ever reaches SAP. There is no setting that turns it back on.
Environment tiers: QAS and PROD are read-only#
Every SAP connection in the Systems tab is tagged with an environment tier — DEV, QAS, or PROD. QAS and PROD are read-only. An agent connected to a QAS or PROD system is handed only read tools no matter which role is selected, so it can never change those systems. Only a DEV system is writable, and only then through a write role you deliberately choose.
The environment-change confirmation#
Because DEV is writable and QAS/PROD are read-only, quietly changing a system's tier could hand an agent write access to production. Makion refuses to let that happen by a stray click.
Any change that would alter a system's read-only guarantee triggers an environment-change confirmation first. The dialog shows the System, Host, Client, and Target, and requires you to type an exact confirmation string — the tier and the system name — before it proceeds. Wrong text, or cancel, aborts the change. Making a production system writable is therefore always a deliberate, typed decision, never an accident.
Never downgrade a PROD or QAS system to a writable tier to "get work done faster." The read-only tag is the guarantee that an agent can never change those systems.
The human apply gate in Autonomous mode#
Autonomous mode is the strongest gate in the product. When the agent runs unattended, its SAP access is read-only for the entire run — it can only propose changes into a ship queue. Getting a change into SAP is a three-stage flow, and every stage after the first is a human action:
- Propose (agent, read-only) — the agent writes its intended changes into the ship queue. Nothing touches SAP.
- Approve (human) — a person reviews a proposal and approves or rejects it. Approving only records the decision; it does not write anything.
- Apply (human) — a person clicks Apply to SAP and confirms. This is the only step that writes.
A proposal can sit Approved indefinitely with zero effect on SAP. The live system changes only when a human explicitly applies it. If you want a hard, button-level human gate on every write, use Autonomous mode rather than an interactive write role.
In interactive Chat, a write role does change SAP during the conversation you are directing — that is the purpose of a write role, and you chose it and steer it. The propose → approve → apply gate is specific to Autonomous mode.
SAP passwords are encrypted with Windows DPAPI#
Your SAP password is encrypted on your own machine with Windows DPAPI, scoped to your user account. It is never stored in plaintext, and it never leaves your machine — it is used only by your own connector to open the tunnel to SAP. When you edit a saved system, the password field shows (saved — leave empty to keep) rather than the value.
A full audit trail#
Makion records what happens. SAP connections, the SAP calls the agent makes, errors, and agent runs are all captured in an audit trail, so you can review exactly what was read, what was changed, and when. See the Audit trail.
The layers together#
| Layer | What it guarantees |
|---|---|
| On-prem hosting | SAP data, credentials, and AI login stay on infrastructure you own. |
| Read-only roles | The agent is handed only read tools — it physically cannot write. |
| Deletion disabled | No role can delete an SAP object, ever. |
| Read-only QAS/PROD tiers | An agent can never change a QAS or PROD system. |
| Environment-change confirmation | Making a system writable requires a typed confirmation. |
| Autonomous apply gate | Unattended runs are read-only; a human approves and applies every write. |
| DPAPI-encrypted passwords | SAP passwords are encrypted, user-scoped, never in plaintext. |
| Audit trail | Connections, SAP calls, errors, and runs are recorded. |
Related pages#
- How roles work — read-only vs write, enforced at the tool level.
- Systems & SAP connections — tiers and the environment-change confirmation.
- Autonomous mode — the propose → approve → apply human gate.
- Audit trail — the record of connections, SAP calls, and runs.
- FAQ — short answers to common safety questions.