Agents do the work. People decide what counts.
M1rror is built so that a design decision, an implementation and a test result can each be checked on their own. This page describes the controls in the pilot, and is plain about what isn’t qualified yet. We don’t claim certifications we don’t hold.
- Approved
Who moves it
Designated reviewers
What proves it
An approval record bound to the release digest, with reviewers, blockers and expiry.
- Implemented
Who moves it
A scoped run, authorised by a repository operator
What proves it
A branch whose diff stays inside the contract’s allowed paths and budget.
- Tested
Who moves it
Deterministic checks, not the agent’s word
What proves it
Recorded results for the exact SHA, including failures and the baseline.
- Merged
Who moves it
You, under your branch protection
What proves it
The merged SHA, compared against what was tested. Deployed is a separate state again.
The rules every run follows
People approve.
Agents can draft, propose and submit evidence. They cannot approve their own work, edit acceptance criteria or suppress a failing check.
Approvals bind to what was reviewed.
Each approval records a digest of the release. Change the target and you get a new release, not an edited one.
Code work needs its own approval.
Design approval doesn’t authorise implementation. A separate approval names the base commit, paths, budget and tools.
Your code never runs in the control plane.
Builds and tests run in a disposable workspace with allowed-path checks, a time limit and a scrubbed environment.
Spending is reserved up front.
A run reserves its budget before it starts. Cancel stops the work and releases what wasn’t used.
Permissions are checked again at execution.
A queued action re-checks access when it runs, so a revoked grant stops it.
How the platform is put together
The same controls apply whether a person clicks a button or a coding agent calls a tool.
- One governed action layer
- The workbench, the REST API and the MCP server all execute the same policy-checked actions. There is no separate, looser path for agents.
- Server-side tenancy
- Workspace scope comes from your session on the server, never from the request. Unknown or cross-workspace IDs return “not found”.
- Immutable records
- Releases, approvals, implementation contracts and evidence are never edited in place. Only their status changes; a changed target means a new release.
- Canonical digests
- Approvals and contracts are validated against published JSON Schemas and hashed with a canonical JSON digest, so a modified budget, path or release is rejected at execution.
- Hostile input is expected
- Repositories, uploads, screenshots, reference text and tool output are treated as untrusted. Permissions and destinations are decided by the control plane, not by instructions found inside them.
- Errors without leaks
- Failures report what happened and whether work was preserved, without stack traces, secrets or raw provider payloads.
- Separate roles
- Editors draft, designated reviewers decide on designs, repository operators authorise code work and billing administrators control spend. One person may hold several roles; the capabilities stay distinct.
- Audited support access
- Staff diagnostics are a separate trust domain with least-privilege access that can’t read raw source or secrets.
Not yet qualified
These capabilities are visibly gated in the product. They return a clear “gated” state rather than a simulated success.
Mobbin reference catalog: not yet available.
M1rror has no Mobbin catalog of its own. Bring your Mobbin account through the official Mobbin MCP server in your own agent and save the screens you pick.
Figma live sync: not yet available.
No live two-way sync. Import frames and styles with a Figma token (variables on Enterprise plans), or use the Figma MCP server from your agent; tokens export as DTCG JSON.
Sandboxing for untrusted repositories: not yet available.
Runs use local isolation that isn’t qualified for untrusted code, so only repositories you connect and own may run.
Capture beyond live web apps: not yet available.
Web bundles and Electron apps are next. Native binaries aren’t analyzed in the hosted product.
Live billing: not yet available.
Stripe runs in test mode during the pilot. No real charges are made.