What Guard covers
Guardrail groups
The nine kinds, how a group is authored and tested, and why nothing enforces them yet.
Organization policies
The five modules, what each rule holds, and the receipts behind every change.
Access control
The three roles, the settings gate and its one exception, and workspace authority.
Receipts and audit
What writes a receipt, what leaves no trace, and how the hash chain is checked.
Data handling and security
Where credentials live, what is encrypted, and what telemetry leaves the deployment.
The gates a request passes
Model and compliance policy
Every chat request resolves its model through one server-side checkpoint before a provider is contacted: disabled providers, disabled models and Require ZDR (Zero Data Retention) are decided there, and when an organization turns on Enforce Study Mode the same checkpoint pins the model whatever the request asked for. A denial is HTTP 403 with a machine reason —policy_denied:provider, policy_denied:model or policy_denied:compliance, joined by commas when more than one applies — and the person in chat sees “The selected AI model is not allowed for your organization.” Require ZDR and Enforce Study Mode act on every request even though the settings screen that carries their toggles has no navigation entry and is opened by URL. Enforcement is not the same as a working outcome: Study Mode pins openai/gpt-oss-120b, a model no route in this release can execute, so a turn sent under it fails instead of answering. Model policy covers each flag, that failure, and how saving an organization OpenAI or Anthropic key turns ZDR enforcement off for models routed through it.
Scopes and allowlists at the gateway
A tool call has to come from a workspace you belong to — a workspace is the boundary that holds a set of connected accounts and the permissions on them — and anything else is HTTP 403,workspace_membership_required. It then clears two more checks: the action must be enabled in that connection’s policy, and a write also needs the connect:write scope on the token the caller is using. A disabled action and one that does not exist return the same 404, integration action not found or disabled, so a tool you have not enabled cannot be probed; a write to an enabled action without the scope returns 400, integration action '<tool>' requires connect:write. GitHub connections add a further check when selected repositories are enforced. See tools and permissions.
Who may change a control
Organization settings are owner and admin only, checked in the browser and again on the server — a write from anyone else fails with, for example, “Only organization owners or admins can manage guardrails.” The MCP Gateway and Workspaces pages are the deliberate exception: any member can open them, and workspace membership and authority decide what they change there. Access control has the full rule.Sandboxed execution and the receipt chain
Background work runs inside a disposable computer, and there is no host execution path to fall back to, so that container is the boundary for the agent’s shell. Receipts are SHA-256 hash-chained: each append compares the expected previous hash against the stored head, and the runtime refuses to fold a chain that does not verify (Receipt runtime refused to replay invalid chain for stream '<stream>': <reason> at index <index>). See receipts and audit.
The dotted edge is the gap worth knowing: a call to the gateway’s REST route, POST /connect/call, writes tool.called and, when it succeeds, tool.observed. The same tool called over the MCP endpoint, POST /connect/mcp — the one an MCP client such as Codex is pointed at — passes the same membership, scope and allowlist checks, but is not recorded.
The enforcement matrix
Saying it accurately
Next step: see how guardrail groups are built and tested.