> 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/beyond-regex-and-semantic-checks.md).

# Beyond Regex and Semantic checks

Warrant is an execution boundary, not a command-string filter. It decides over typed operations, controls the actuator that performs supported side effects, and binds each decision to the runtime and policy that execute it.

That distinction matters more than whether a text classifier is sophisticated. A regex can recognize a phrase, and a semantic model can label intent, but neither is a security boundary if the agent can still call the underlying tool directly or if the checked request can change before execution.

### The short comparison

| Property                    | Regex check                      | Basic semantic check                       | Warrant local CLI                                                          |
| --------------------------- | -------------------------------- | ------------------------------------------ | -------------------------------------------------------------------------- |
| Input                       | Command or prompt text           | Parsed command, tool call, or intent label | Closed typed operation and parameters                                      |
| Unknown operation           | Often unmatched                  | Depends on classifier defaults             | Denied                                                                     |
| Policy scope                | String patterns                  | Labels and parameter rules                 | Exact operation plus exact/subtree path authority                          |
| Decision stability          | Depends on mutable checker state | Depends on model/rules                     | Canonical policy and runtime hashes are bound into evidence                |
| Approval                    | Usually a reusable exception     | Commonly a risk label or generic review    | One exact action, artifact, path, and target preimage                      |
| Execution ownership         | Usually none                     | Often none                                 | Supported side effects run only through Warrant's actuator                 |
| Drift handling              | Usually unchecked                | Usually reevaluated inconsistently         | Agent, policy, route, artifact, and runtime drift fail closed              |
| Multi-step bad-state search | No                               | Usually no                                 | Implemented in Warrant's strict verifier; not yet invoked by the local CLI |

### Why regex is not a boundary

Consider a rule that blocks `rm -rf` or `DROP DATABASE`. The same effect can arrive through:

* different quoting, encoding, whitespace, or command construction;
* a script or package-manager lifecycle hook;
* a GitHub workflow that receives a production credential;
* an MCP tool whose friendly name hides a destructive implementation;
* a direct API, database, or cloud-provider call;
* a previously approved request whose parameters or target changed.

Adding more patterns grows a blacklist but does not establish which capability was invoked, which resource it can reach, or which bytes ultimately execute. A miss can become an allow, and a match commonly has no control over the downstream side effect.

Warrant's local path does not ask whether a command *looks dangerous*. It accepts only the five workspace operations in its closed catalog. Shell, network, database, Kubernetes, delete, rename, and unknown operations have no local actuator and cannot become an allowed Warrant action.

### Why a semantic classifier is still insufficient

A semantic checker is useful for discovery or review, but classification is not authority. Even a model that correctly labels an operation as “safe” does not prove:

* that the caller supplied every relevant parameter;
* that the target remains unchanged after review;
* that the same policy and tool route are live at execution;
* that another tool or credential cannot reach the same effect;
* that retries cannot duplicate a side effect;
* that the classifier itself cannot be influenced by untrusted tool output.

Warrant deliberately does not claim to infer benign intent. It enforces explicit authority instead:

```
authenticated session
  -> closed tool schema
  -> typed operation and canonical path
  -> policy decision
  -> exact owner approval when required
  -> artifact and target-preimage recheck
  -> registered workspace actuator
  -> integrity-linked transition trace
```

The local write boundary commits the exact content bytes and the target's expected preimage. Approval of one file does not authorize different bytes, another path, or a second write. Policy, agent, configuration, or runtime drift denies rather than falling back to an unverified route.

### Warrant's reachability verifier

The repository also contains a typed finite-state reachability checker. This is a separate strict/server track today; the public v0.3.0 CLI does **not** invoke it and must not be described as `strict_verified`.

The verifier lets an operator define a forbidden effect:

```json
{
  "name": "production database must not be deleted",
  "never": {
    "effect": "delete",
    "resource": "database:production"
  }
}
```

It can also forbid a compound state:

```json
{
  "name": "deployment and billing authority stay separated",
  "never_state": [
    {"capability": "deploy", "principal": "agent"},
    {"capability": "billing_admin", "principal": "agent"}
  ]
}
```

Modeled transitions declare `requires`, `grants`, `revokes`, and `effects`. Warrant explores distinct reachable states, applies the same policy gate used at runtime, and returns a counterexample when a bad state is reachable:

```
agent can dispatch production workflow
  -> workflow receives database authority
  -> workflow performs destructive database effect
  -> forbidden state reached
```

Approval-gated transitions are explored pessimistically as potentially approved. A result is `complete` only when the finite declared state space is exhausted, the world signature is checked, the model explicitly reports no known omitted edges, and the worst-case approval scope was explored.

Search depth is configured from 1 through 8 and defaults to 4. `verified: true` can therefore still describe a bounded result; `complete: true` additionally means the depth cap left no reachable transition unexplored in the declared finite model.

Strict activation goes further than producing a report: an unsafe, incomplete, unsigned, under-approximated, or stale report keeps execution deny-all. A qualifying report is content-addressed and bound to the policy, catalog, actuator configuration, verifier implementation, and live execution epoch.

The verifier explores every distinct reachable state in the supplied finite model; it does not claim to enumerate every real-world path or prove an unbounded theorem.

### Where regex may still appear

Regex can be one conservative discovery input. For example, Warrant's GitHub Actions importer can use reviewed patterns to translate shell fragments into typed effects. That classifier is not allowed to certify completeness by itself.

The GitHub importer marks an unclassified fragment, unexpanded action or reusable workflow, or unsupported trigger as under-approximated. When the caller preserves that output and forwards its provenance into verification, strict activation cannot qualify the result as complete.

Discovery completeness and propagation of importer provenance remain trusted inputs. If a caller discards the warning or manually claims `under_approximated: false`, the verifier cannot infer the missing real-world edge. Regex may help add a modeled edge, but it is not proof that the surrounding workflow inventory is complete.

The local JSON policy language itself uses exact and subtree paths. It does not use regex or glob matching for filesystem authority.

### Current assurance boundary

The downloadable CLI currently claims `integrated` assurance:

* typed, closed operations;
* exact policy and runtime evidence;
* authenticated MCP sessions;
* operation-specific approval;
* exact workspace actuation;
* fail-closed drift handling.

It does not yet claim:

* local bad-state reachability qualification;
* OS-enforced filesystem, process, or network containment;
* protection from invoking the original agent binary directly;
* protection from ambient same-user credentials or unmanaged network routes;
* semantic truth or benign intent for an allowed in-scope value.

Bringing `strict_verified` to the local product requires compiling a complete local transition model, running reachability during setup, binding the signed report into the session and execution fence, and invalidating it whenever the policy, agent profile, tool inventory, catalog, actuator, or verifier changes. OS containment and credential brokerage are also required before “all real paths” can include host-level bypasses.

Continue with How the boundary works, Policies, and the Security model.


---

# 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/beyond-regex-and-semantic-checks.md?ask=<question>&goal=<endgoal>
```

`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.