Two programmable surfaces, and what each one is allowed to do.
The control plane has an HTTP API, and the engine serves its tools to a model over the Model Context Protocol. They have different threat models, so they get different rules rather than one paragraph covering both.
Tokens, limits, and what a token can reach.
| Authentication | A token belongs to one organization and carries a role. Nothing in the API is reachable without one, and a token is stored as a hash, so a leaked database does not yield a working credential. |
|---|---|
| Rate limits | Every public endpoint has one, declared in a single registry that the middleware reads. An endpoint added without a limit is a build failure rather than an endpoint with no limit, which is the usual way this goes wrong. |
| Scope | A token reaches its own organization and no other. This is enforced by row level policy in the database rather than only by a check in the application. |
| If a token leaks | Revoke it. Revocation is immediate for the API. A token already inside a running engine keeps working until that run finishes, and this is stated because the opposite would be assumed. |
A model driving the engine is still you, for every purpose in these terms.
The engine can serve its tools to a model over the Model Context Protocol, which means a model can create environments, run workloads and tear them down. The rule that follows is the one worth stating plainly: an action a model takes through your engine is your action. The acceptable use policy applies to it unchanged, and a model misreading an instruction is not a defence any more than a script with a bug would be.
The MCP server runs on your machine and speaks over a local transport rather than a network port. It has whatever access your shell has. Granting a model that surface is a decision with the same weight as giving it your terminal, and it should be made the same way.
What you may do with the interfaces.
- Build whatever you like against the API for your own organization, including things we did not anticipate. That is what an API is.
- Automate the CLI in your own pipelines. The exit codes and the report format are the contract, and the report is versioned so that a parser does not break silently.
- Do not use the API to work around a limit on your plan, including by spreading one workload across organizations.
- Do not present output from this product as a certification, an audit, or a guarantee of correctness to a third party. It is evidence about one run under conditions that run created.
- Interfaces marked internal or undocumented may change without notice. The documented API and the report schema will not change incompatibly without a version.
Know what happens before you deploy.
Create a disposable production twin for every risky change. Catch migration failures before they reach customers.