Author, simulate and publish
How a change moves from a draft to a live revision on the LLM Gateway and MCP Gateway tabs of the Policy Engine. The Browser Extension and Endpoint Agent tabs do not use this draft workflow.
The loop
1. Open the card
Each card shows what is live. Select Configure to edit it in place. Scope shortcuts add a User, Smart group or Application condition with a seeded priority (900, 700 and 600), so a narrower scope wins without you choosing numbers.
2. Edit into the shared draft
Every edit, from every card and every admin, collects in one shared draft. Pickers are backed by your real catalogs (people, applications, Smart Groups, detections), so you cannot enter a value that would fail validation. Anything too complex for a card stays byte-preserved under Advanced policies and remains editable in source view.
Conditions are built from a field, an operator and a value. Operators adapt to the field: is, is not, is any of, is none of, is set, is not set, contains, starts with, ends with, matches pattern, is inside CIDR, includes (ignoring case), has entry and has count. Data found takes is any of, is all of or is none of, with an optional occurrence threshold.
- Rows join with
andoror, and an any-of group nests a bracketed set of alternatives inside the sentence. - On a card, every Applies to chip must match (AND), and values accept
*and?wildcards. For "A or B", add a second configuration or an any-of group.
3. Validate
Problems are reported against the exact field that caused them, with warnings kept separate from errors.
4. Simulate
Use Describe a request (MCP: Describe a call) to see the winning value per control for one request. Leave API surface empty and the request simulates as chat; Add detection reports a data type as found, with a count per type. For more coverage, run up to 100 synthetic cases against your draft and read the engine's actual decision evidence: which rules matched, on which stage, and the call-level outcome.
A policy validating, or appearing to be in scope, is not evidence of the outcome. Simulation is the only thing that reports the engine's real decision.
5. Replay recorded traffic
Evaluate the draft against traffic that already happened, up to 90 days back and up to 5,000 requests for the LLM Gateway. This is how you find the rule that would have blocked more than you intended.
6. Publish
Review the draft, then publish. On the LLM Gateway, publish takes a message; on the MCP Gateway it takes no message, and drafts can be renamed. All pending changes publish together as the next numbered revision, shown as Revision N in the header. Drafts carry a concurrency guard, so a colleague's publish cannot be silently overwritten.
7. Watch, then adjust
The activity view rolls up governed calls, blocked calls and tokens saved over the last 7 or 30 days.
8. Roll back if needed
History lists every published revision with its checksum. Rolling back republishes an earlier document as a new revision, so the timeline only moves forward and an incident stays fully auditable. Rollback changes only policies; it never touches classic app settings (see What happens to classic settings).
Worked example: block secrets for contractors
Goal: on the LLM Gateway, block requests carrying Auth & Secrets for the Contractors Smart Group, and leave everyone else as they are. Assume the live revision is Revision 4.
- Draft. On the Data & Adversarial Risks card, select Configure, add a Smart group scope for Contractors, pick Auth & Secrets and set the action to block. The edit joins the shared draft; live traffic is unchanged.
- Positive test. Select Describe a request. Describe a user in Contractors and use Add detection to report Auth & Secrets. The card should resolve to block.
- Negative test. Describe the same request for a user outside Contractors. The card should resolve to the value you had before, for example monitor. If it shows block, the scope is wrong.
- Replay. Replay the last 30 days. The would-be-blocked set should contain only Contractors' calls that carried secrets.
- Publish with a message such as "Block secrets for contractors". The header now shows Revision 5.
- Verify. Check the activity view and Findings & Interactions for blocked calls from Contractors only.
- Roll back if it misfires. Open History, find Revision 4 and roll back. Its document is republished as Revision 6, and live traffic behaves as it did under Revision 4. Revision 5 stays in History for the audit trail.
Source view and the Advanced workspace
Every policy has an exact text form in QuilrQL, the policy language. The </> toggle switches between the sentence editor and source in both directions. You need source only for review, diffing or bulk work.
policy block_request_secrets priority 900 {
request
data_type ("Auth & Secrets")
then {
dlp.action = block;
risk.level = critical;
}
}
Advanced policies > Advanced workspace opens the source-level editor for the whole document:
- New draft from active revision clones the live revision into a named draft.
- Edit with the visual builder (one policy at a time) or the full QuilrQL source. Suggested policies inserts ready-made rules, and Insert from catalog inserts exact values for users, apps and more.
- Save draft explicitly. Validation and publication run only against the saved source.
- 02 Analyze runs Diagnostics, Simulation and Historical Try against the candidate, then publish the revision.