SECURITY OVERVIEW

What buyers and operators need to know before production.

This page describes the public security posture of Stage0 as a hosted API. It covers what data reaches Stage0, how decisions are traced, and what buyers should verify before treating it as a production control layer.

This page does not claim a certification status (SOC 2, ISO 27001, etc.). If your procurement process requires a formal certification, contact us to discuss the current posture and roadmap.

What data Stage0 receives

Request payload

The `/check` endpoint receives the fields you choose to send: goal, tools, constraints, side_effects, environment, and optional context fields. Stage0 does not require PII. Avoid sending credentials, user data, or secret values in check payloads.

API key

Each request is authenticated with an API key bound to your account. Keys are hashed at rest and never returned in full after creation.

Request metadata

Standard HTTP metadata: IP address, timestamp, user agent. These are used for rate limiting and abuse detection.

No execution payload

Stage0 does not receive the output of agent actions, database contents, file contents, or downstream execution results. It only sees the proposed action before it runs.

Request tracing

Every `/check` response includes fields that let you carry the decision into your own audit trail. Stage0 does not provide a hosted audit log UI — you are expected to store these fields in your own system.

`request_id` — unique identifier for the check request
`policy_version` — the policy configuration version that evaluated the request
`environment` — the environment tag passed in the request
`decision` — GO, NO_GO, or DEFER
`verdict` — ALLOW, DENY, or DEFER
`issues` — structured reason codes for the decision

Data retention posture

Stage0 retains request logs for a limited window for operational purposes (debugging, rate limiting, abuse detection). Logs are not exposed to other customers. If you require a specific retention period or data deletion SLA, contact us before production rollout.

Fail-closed behavior

If Stage0 is unavailable, returns an unexpected status code, or times out, your runtime must treat the missing decision as a denial and stop the side effect. This is the enforced contract: a missing authorization is not an implicit allow. Your integration is responsible for implementing fail-closed behavior server-side.

Hosted architecture

Cloud-hosted API

Stage0 is a hosted SaaS API. There is currently no self-hosted or on-premises deployment option. If data residency or network isolation is a hard requirement, contact us to discuss.

HTTPS only

All API traffic is over TLS. Unencrypted HTTP requests are rejected.

Key isolation

API keys are scoped to individual accounts. A key from one account cannot access data or decisions from another account.

No agent execution

Stage0 does not execute tasks, call external tools, or trigger downstream actions on your behalf. It returns a decision and stops.

What buyers should verify

Before treating Stage0 as a production control layer, confirm each of the following:

Your integration fails closed when Stage0 is unreachable or returns an error
You carry `request_id` and `policy_version` into your own logs on every check
High-risk actions include approval context before the `/check` call is made
Final enforcement logic lives in your server-side runtime, not client-side code
You have reviewed the production behavior docs at `/docs#production`
You have confirmed that the data you send in check payloads does not include credentials or PII

Security questionnaire or procurement review

If your procurement process requires a security questionnaire, architecture review, or a conversation about data handling, contact us before rollout. Include your runtime shape, risk surface, and any specific compliance requirements.