> For the complete documentation index, see [llms.txt](https://cerebral-systems.gitbook.io/cerebral-systems-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cerebral-systems.gitbook.io/cerebral-systems-docs/policies-1.md). # Policies ## Security model Warrant's local product is an **integrated application boundary**. It is stronger than a regex prompt or command check because it controls a typed tool route and the exact workspace actuator. It is not an operating-system sandbox and is not currently a `strict_verified` runtime. ### Security objective For a managed agent session, Warrant aims to ensure that: * authority comes from one explicit local policy; * supported operations use closed schemas and workspace-relative paths; * denied or unknown operations do not reach an actuator; * supported writes execute only after action-specific local-owner approval; * the approved artifact and target preimage are rechecked at actuation; * the live runtime still matches the evidence qualified at setup; * meaningful action transitions produce an integrity-linked trace. The relevant trust boundary ends at Warrant's managed shim, hook/MCP integration, local daemon, and workspace actuator. ### What is enforced #### Closed capabilities The policy names all five supported workspace operations. Unknown operations, fields, decisions, paths, or tool inputs deny. Raw shell and unmanaged MCP calls are not expressible in the closed policy operation set; agent adapters separately close their native tool surfaces. Agent configuration is replaced at authority-bearing sections instead of being silently merged. Managed argument grammars reject flags and subcommands that could change the workspace, tool set, policy mode, MCP route, or permissions. #### Measured runtime Warrant binds and rechecks the agent launcher, agent bytes, exact pinned adapter version, interpreter for script launchers, managed shim, Warrant runner, policy, generated configuration, MCP route, workspace, operation catalog, actuator, verifier, and environment evidence. A deliberate upgrade requires setup again. Unexplained drift denies launch or execution. #### Local identity and approvals Session handles and configuration live in owner-private state. MCP calls are tied to an authenticated, expiring local runtime session. Policy changes and approval decisions require separate local-owner authority rather than agent-supplied identity. An agent cannot approve itself by changing its name, prompt, summary, requested autonomy, or claimed risk. Approval binds one action and exact artifact; it is not a reusable grant. #### Workspace actuation The actuator anchors operations to the qualified workspace and rejects traversal, symlinks, hardlinks, special files, cross-device escape, stale preimages, and changed artifacts. Reads and discovery are bounded. Search is literal text, not a shell or regular-expression execution route. ### What is not enforced Warrant v0.3.0 and the current source preview do not provide: * OS-enforced filesystem, process, or network containment; * a raw-network allowlist or provider egress firewall; * protection from invoking the pinned agent binary directly; * protection from another same-user process, the host owner, root, or malware; * model-provider authentication brokerage for Codex, Grok, Hermes, OpenClaw, or PicoClaw; * prompt confidentiality, model routing, provider retention control, or training guarantees; * semantic intent detection for an allowed operation and in-scope value; * a content-aware secret classifier; * local Kubernetes, database, cloud, browser, package-manager, delete, or arbitrary command actuation; * a formal proof over the complete agent or host state machine. The closed policy language and evidence seal make decisions deterministic and inspectable. They do not prove that no bypass exists outside the managed application surface. ### Credentials and network No Warrant signup or Warrant API key is used. Warrant maintains local owner authority for approvals and policy changes. Install and authenticate each model agent separately. Claude Code's macOS profile can check the presence of its default Keychain credential without reading it. The other clean profiles do not receive provider tokens from Warrant and normally report `model-ready=false` until a future credential broker exists. The managed child environment is deliberately small and rejects credential-like variables. That reduces accidental inheritance; it does not revoke credentials an agent can reach through an OS keychain, another process, or an unmanaged file. Agents still need provider network access for inference. Any prompt and file content the agent intentionally receives may be transmitted to that provider. Never expose a file through policy if the configured provider must not receive it. ### Application boundary versus OS containment | Scenario | Warrant result | | --------------------------------------------------------- | --------------------------- | | Managed agent calls an unknown or denied Warrant tool | Denied | | Managed agent proposes an allowed, approval-gated write | Held for local owner | | Approved bytes or target preimage change before execution | Denied | | Agent/profile/policy/config evidence drifts | Launch or execution denied | | Agent is started through its original binary path | Outside Warrant | | Same-user process opens a host file directly | Not OS-contained | | Agent sends an allowed read to its model provider | Not blocked by Warrant | | Prompt injection asks for a denied typed operation | Policy denies the operation | | Prompt injection uses an uncontained host/network bypass | Outside this boundary | For sensitive production use, pair Warrant with an OS sandbox or disposable VM, non-ambient credentials, filesystem mounts that expose only intended data, and egress controls. Those outer controls make “all actions go through Warrant” enforceable at the host level. ### Grok Build repository-upload risk A [primary wire analysis of Grok Build 0.2.93](https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547) recovered an unread tracked file and Git history from a repository bundle transmitted during its tests. That evidence demonstrates transmission and storage for the tested version and environment. It does **not** demonstrate model training, and it does not prove identical behavior in every later release. The maintained analysis reports that xAI disabled the upload server-side on 2026-07-14. Warrant does not treat a remote default as its security boundary. The current-source adapter remains pinned to Grok Build 0.2.101 and layers several local controls: 1. Grok starts in an empty, owner-private session workspace, not the original Git checkout. 2. Original workspace access is exposed only through authenticated Warrant MCP tools and the selected local read policy. 3. Hash-bound `managed_config.toml` and `requirements.toml` set `harness.disable_codebase_upload = true` and disable indexing, remote fetch, feedback, telemetry, trace upload, memory, subagents, and compatibility imports. 4. A hash-bound `warrant-agent.md`, passed through an absolute `--agent`, disables injected native tools and names only Warrant MCP tools for interactive and headless sessions. 5. The managed environment does not forward `XAI_API_KEY` and sets provider-specific telemetry and trace-upload vetoes. 6. Exact version, binary, configuration, and launch evidence must still match at run time. These measures reduce the chance that Grok can package the original checkout through its normal codebase-upload path. They do not establish raw-network containment or prevent the Grok process from opening an absolute host path as the same user if a bypass exists. Prompts and files explicitly read through Warrant still go to the configured xAI inference service. xAI documents the current [Grok Build overview](https://docs.x.ai/build/overview), [CLI controls](https://docs.x.ai/build/cli/reference), [enterprise network and sandbox behavior](https://docs.x.ai/build/enterprise), [`GROK_HOME` configuration scopes](https://docs.x.ai/build/settings), and [MCP configuration](https://docs.x.ai/build/features/mcp-servers). Treat those as provider behavior documentation, not proof of Warrant's host containment. ### `privacy-locked` is not secret detection The source-preview `privacy-locked` template permits exact `README.md` and the full `docs/`, `src/`, and `tests/` subtrees. It denies root `.env`, `.git`, `.github`, and other root files by omission. A secret nested inside an allowed subtree remains in scope. For example, `src/.env` is readable unless a custom policy explicitly excludes it. File names, contents, entropy, and credential formats are not classified automatically. Use a custom policy for known sensitive paths, keep secrets out of the workspace, and use an outer filesystem sandbox when exclusion must hold against the process rather than only Warrant's typed reads. ### Formality boundary The local policy compiler is closed and deterministic, and the runtime seal commits the evidence used for decision and execution. That is materially stronger than matching a command string with regex or loading a mutable `policy.json` without binding it to execution. It is still not full formal verification. The current local product does not model all agent, process, filesystem, network, credential, and provider transitions, and it does not prove temporal properties over that complete state. Describe it as a proof-bound or evidence-bound execution gateway, not as a formally verified OS security boundary. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cerebral-systems.gitbook.io/cerebral-systems-docs/policies-1.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.