> Canonical: https://antifailure.dev/developer-policy > The rules for the control plane API and for the engine's Model Context Protocol surface. # 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. - Terms of Use Scope, warranty, and liability. Read - Acceptable use What the product may not be pointed at. Read - Service levels There is no SLA. Here is what there is. Read ## Know what happens before you deploy. Create a disposable production twin for every risky change. Catch migration failures before they reach customers.