Security & enterprise readiness
mxto is a local toolchain, not a cloud service. Your Mendix™ model and credentials stay on infrastructure you control. Here is the technical detail your security team will ask for.
Where your model goes
All your data stays on your machine
mxto runs as a binary on your machine, your server, or your CI runner. It reads your Mendix project locally and writes its outputs to a local directory. There is no mxto cloud service: mxto performs no upload of your model to anything we operate. Your model and its data never leave infrastructure you control.
The real data boundary: your AI agent
mxto is the toolchain your own AI agent drives: Claude Code, Cursor, your own. The honest boundary is this: where your model text travels is determined by your agent and its LLM provider, under your contract (not by mxto). Run a local model and nothing leaves your network; run a hosted model and your model text follows your provider's terms. mxto gives you the choice instead of making it for you.
Credentials
Mendix™ Personal Access Token VERIFY
Your Mendix PAT is read from the environment (e.g. an .env file or CI secret) and
used only to authenticate to Mendix Team Server for model pull and commit. It is not transmitted
to any third party and is not written to mxto's output artifacts. VERIFY
that the token is never emitted to logs.
Change safety & auditability
Every change is a reviewable diff
mxto produces the change and the diff; a human approves the commit to a shared Team Server branch. Commits carry a local audit trail and support rollback to a previous commit. Nothing is forced into your model without a reviewable artifact.
Round-trip proof gates every write
Before a change is trusted, mxto round-trips the model (extract, re-emit, diff), so any silent drop or corruption surfaces as a diff rather than a production incident. See what "0 unexpected diffs" means.
Deployment & operating boundaries
Headless, on your infrastructure
mxto runs on Mac, Linux and CI with no IDE in the loop. Its only outbound dependencies are the systems you point it at: Mendix™ Team Server (git) for model pull/commit and (when you ask it to deploy and test) a Mendix runtime you control. VERIFY the full egress list against the shipping binary.
CI integration
Because mxto is a headless binary, it slots into a CI pipeline like any other build step: extract → author → mxbuild → deploy → test, gated on the round-trip. VERIFY: link a reference CI configuration here before publish.
Compliance
SOC 2: not certified, by design.
mxto is not SOC 2 certified, and a local toolchain does not need to be. SOC 2 exists to assure you about how a vendor handles data on its servers, but mxto has no servers in the loop and holds none of your data: everything runs and stays on your own machine. The trust boundary is your infrastructure, not ours. BRAND/LEGAL may add a Data Processing Agreement / sub-processor note if a specific buyer requires one.
System requirements
What you need to run it
A Mendix™ Personal Access Token + Project ID, a Mac/Linux/CI machine, RAM and disk scaled to your model size, and your own AI agent subscription (Anthropic / Cursor / compatible). Full detail in the system requirements proof file.