Production boundary
Use the MCP setup in development or staging. Keep production in a separate Zerops project without a zcp service. Production deploys should come from CI, a release pipeline, or a deliberate human zcli push using production credentials.
Zerops does not prevent you from adding zcp to production. The policy exists because ZCP MCP gives a coding agent operational access. In production, that is the wrong blast radius for normal app development.
The production boundary does not make ZCP output disposable. The intended path is production-shaped dev or stage infrastructure, verified behavior, and then a controlled production release outside the agent loop.
Recommended project layout
| Project | Contains | Who operates it |
|---|---|---|
| Development / staging project | zcp service, agent workspace, dev runtime, optional stage runtime, non-production managed services | Agent plus humans |
| Production project | Production runtimes, production managed services, production env values, production backups and scaling | CI/release process plus humans |
The two projects use different Zerops tokens. A development token cannot reach production. A production token should not be placed in the development zcp service or a local .mcp.json used by the agent.
Why production is a separate project
- The Zerops project is the security boundary. ZCP binds to one project at startup. Keeping production separate prevents a development agent from touching it by accident.
- Secrets stay clean. Production env values, database credentials, object-storage keys, and third-party secrets stay in the production project.
- Operational policies can differ. Production often needs HA services, stronger backup retention, stricter scaling, alerts, and release approvals. Development can stay cheaper and more flexible.
- Audit trails stay readable. Development experiments and agent retries do not mix with production deploy evidence.
This separation matters even when the same source repository deploys to both projects.
What stage proves
Stage is the production-like rehearsal inside development or staging. It is where the agent proves the change before the release leaves the ZCP loop.
Use stage to match production where it matters:
- same runtime family and version,
- same managed service types,
- same build and start command pattern,
- same deploy route,
- behavior checks against a real running service.
Stage is not production. It should use non-production data and non-production secrets. A green stage means the change is ready for release, not that the agent should deploy to production itself.
The release
After stage verifies, ZCP's job is done for that change. The production release happens outside the agent loop:
- CI deploys a merged commit or release tag to the production project.
- A release pipeline runs
zcli pushwith a production-scopedZEROPS_TOKEN. - A human runs
zcli pushagainst the production project with production credentials.
The agent can prepare the handoff by pushing code, summarizing verification evidence, and naming the runtime and URL it verified. It should not bridge development to production.
For the practical workflow, see Promote to production.
Credential rules
| Credential | Production policy |
|---|---|
Development ZCP_API_KEY | Never grants production access. Keep it scoped to the development/staging project. |
Production ZEROPS_TOKEN | Store only in the production CI/release secret store. Do not place it in the development zcp service. |
| Agent subscription or model API key | May be used by the agent, but it does not grant Zerops production access by itself. |
| Git credentials | May push source changes, but production deploy authority should stay with the release process. |
If a production deploy fails, investigate in the production project with production logs, events, backups, and CI output. Do not attach the development agent directly to production as a shortcut.
Production separation rules
| Rule | Why it matters |
|---|---|
Keep the production project without a zcp service | Production should not host an agent workspace with operational access. |
Keep production tokens out of local .mcp.json | Local agents should operate development or staging projects, not production. |
Keep production ZEROPS_TOKEN in the release secret store | Development tooling should not deploy to production outside the release process. |
| Treat stage proof as release evidence, not production approval | Stage is the rehearsal; production approval is a separate release decision. |
| Promote through CI, release tooling, or a deliberate human action | Production execution should use production credentials. |
Acceptable agent involvement
The agent can still help before the production release:
- make the code change in development,
- deploy and verify dev/stage runtimes,
- produce the URL, endpoint result, or UI proof it verified,
- push or prepare the branch your team uses for review,
- summarize release notes and known blockers for the human or CI handoff.
ZCP's involvement stops at the handoff. Production execution belongs to the release process.
Related security
- Promote to production - practical production release paths after ZCP proof.
- Trust model - the boundary that makes this policy enforceable.
- Tokens and credentials - production and development credentials stay separate.