Put policy in front of the model, not inside the prompt.
A system prompt asks the model to police itself. Tileward Governance makes the decision before governed-model inference begins, so a denial is a stopped request with a decision record, not a completion that happened to say no. We tested that boundary with 2,251 Requests for the same forbidden thing, rewritten to get past the rule: reworded, reframed, buried beside ordinary work, or split across sentences. The meaning stays the same; only the phrasing changes.. Fifty crossed the gate. Five of fifty The control group: fifty perfectly reasonable requests that policy allows. They are there to catch the opposite failure, a system so cautious it blocks legitimate work. were refused. The boundary is inspectable: an enterprise team can test, audit, and improve it.
See the policy bypass eval for the one-card result.
Govern the request before compute and output begin.
| Architecture | What enforces the rule | What a denial means |
|---|---|---|
| Prompt instruction | The model receiving the request. | The model chose not to answer. |
| Pre-inference policy gate | A policy decision before the governed model. | The request does not start governed-model inference. |
Keep the policy decision stable when the wording changes.
A direct request about a locked topic is the easiest possible test. We tested the same governed material after it was reframed, represented differently, placed beside ordinary work, or split across clauses. The property we want is that A boundary that can be walked around by rewording is a feature, not a control. Same meaning in, same decision out..
Security failure
A request that policy says to deny is allowed through the gate. The governed model may now receive material it was not authorized to receive.
Utility failure
A request that policy says to allow is refused. The boundary protects nothing at the cost of work a customer was entitled to do.
One battery tests both protection and permission.
The corpus covers two policy shapes: direct locks on a topic and allow-only policies, where prohibited material sits beside work that is ordinarily permitted.
| Population | Cases | Crossed the gate | Observed result |
|---|---|---|---|
| Direct locked-topic requests | 1,100 | 11 | 99.0% stopped in this corpus |
| Prohibited material beside allowed work | 1,151 | 39 | 96.6% stopped in this corpus |
| All adversarial cases | 2,251 | 50 | 2.2% observed bypass rate |
| Benign controls | 50 | 5 refused | 90.0% allowed in this corpus |
It is the share of this hand-authored attack corpus that the gate stopped. It does not estimate a population bypass rate, establish coverage of an unknown attack class, or show that the corpus represents real traffic.
Every bypass becomes a regression case.
The early corpus was narrower than the one behind the figures above, so the two rounds do not sit on the same axis.
Each pass over the early corpus found requests the gate was reading as new when their governed meaning had not changed; each finding was repaired, and the corpus was widened along the way. Every figure on this page is the state after that work.
The value is a visible boundary.
The residual failures are a mixed tail rather than one defect with one fix, and they are spread across both policy shapes. They are open findings against a control that is running, and the people who should have the detail are the ones depending on it, under an agreement.
The five benign refusals are few and targeted rather than sampled traffic, so they do not establish a general false-refusal rate.
This study governs English. When the gate recognises an unsupported language on a protected policy path, it refuses the request rather than claiming semantic coverage it does not have.
Test the policy against your real edge cases.
Bring a topic you cannot let an assistant discuss and we will lock it, try to cross the policy ourselves, and show you the decision record. Talk to an engineer, compare the supporting eval, or read how Governance works.