HOLD FOR LAUNCH Document Agent classifiers; fix stale AIAM pages

[c1-squire-dev]

Update: renamed to Classifier, rebased on main

The product has since renamed this feature from Guardrail to Classifier (the old Guardrail* API is kept, deprecated, for compatibility — the model layer is unchanged). This revision renames all three pages (including their filenames/URLs) and the sibling corrections to match, rebases onto latest main, and keeps the OCSF audit event fields (guardrail_decision, aigov.guardrail.decision, guardrail_id) as-is with a note explaining they weren't renamed — only the admin UI and public API were. Re-ran npx mintlify broken-links: still zero broken links introduced by these pages.

What changed since the last review

The previous revision of this PR used "Agent classifiers" as an umbrella term for existing AIAM mechanisms (toolsets, hooks, kill switches, step-up auth). That name is already a shipped feature with its own object model (Classifier, ClassifierBinding, AgentClassifierRule, ToolGate) and admin page at AI > Classifiers. A reader who followed those pages and then opened that page would have found a UI sharing nothing with them but the name.

All three pages are rewritten to document the actual feature. The sibling pages the old version copied from are corrected too, since they were the source of most of its errors.

The pages

Page	Content
agent-classifiers	Classifiers as rule cascades over the three risk signals (private data / untrusted content / exfiltration); bindings; Agent vs Gateway surfaces; how rules relate to tool gates and hooks
agent-classifiers-configure	Create a classifier → bind it → author rules → attach gates and hooks → promote Observe to Enforce → judge settings
agent-classifiers-reference	Object model, rule and gate fields, CEL variables per surface, evaluation order, constraints, troubleshooting

Scope note: classifier templates/presets are intentionally not covered.

Sibling-page corrections

• tool-call-hooks — hooks live under AI > Classifiers, not C1 Gateway (moved in an earlier PR); adds the pre-output event, the caller payload block (with the warning that it is never an authorization input), event-dependent filter variables, the six undocumented built-in patterns (11 exist, 5 were documented), the claw tool_source, corrected pattern defaults, and the Managed by classifiers toggle
• tools-and-toolsets — classification is one five-value field, not "Action (Read/Write/Delete)" + "Risk (Sensitive/Dangerous)" axes; there is no "Delete" value; real toolset names (All approved tools / Read tools) and per-connector scope
• enable-ai-access-management — empty allowed-client-types means all types allowed (was documented as personal-only); default classification is Sensitive, not Unclassified; real client-lifecycle labels and defaults; adds the per-server kill switch
• ai-clients, aiam-overview — matching lifecycle and toolset fixes

Verification method

The previous revision's stated method — tracing claims to sibling docs — was the root cause of its errors: it propagated their staleness and couldn't detect a collision with an undocumented feature. This revision verified against the implementation and by exercising the feature in a dev tenant.

Caught and fixed during verification:

• The judge does not fail closed with no score. When unreachable at run entry it seeds a cautious MEDIUM untrusted-content floor; only a mid-run rescore failure keeps the prior floor.
• Tool gate filters expose nine CEL variables, not the two the in-product helper text names. Documented both, and noted which two the UI mentions.
• Rule CEL failure is skipped, not denied — the opposite of hook filter behavior, where a failed filter denies the call. Both are now stated explicitly because the asymmetry is surprising.

Deliberately not documented, because they are declared but unimplemented: Classifier.default_outcome at eval time, a system baseline rule on the Classifier object, and centrally-patched template distribution. Confirmed unimplemented rather than assumed.

Test plan

• Exercised the feature end-to-end in a dev tenant: created a classifier, inspected a rule cascade (IF ctx.private_data >= 2 && ctx.exfiltration >= 2 → Block / Enforce), opened the rule form, checked the judge settings tab, and deleted the classifier. All UI labels, helper text, and defaults in these pages are transcribed from that session.
• Confirmed live that C1 Gateway > Settings contains no hook UI (only C1 Gateway, Client governance, and Default C1 Gateway Classifier policy) — the old nav path was wrong.
• Confirmed live that the two bindings live on different pages: the agent binding on AI > Classifiers, the gateway binding on AI > C1 Gateway > Settings.
• Confirmed live client-lifecycle defaults: Hide inactive clients after 1 day, Close credentials after 1 month, Delete closed clients after 3 months — and that the third is measured from close, not from last activity.
• npx mintlify broken-links — no new broken links; anchors verified against real headings. The 8 reported are pre-existing in unrelated files.
• docs.json validates.
• Review the rendered preview.

For reviewers

Terminology. These pages call the risk axes "signals" and the cascade a "classifier," matching the product's current naming.

Tenant availability is conveyed only by the standard "Activation required" note already used across the AI access management pages. The pages name no internal gating.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
conductorone	🟢 Ready	View Preview	Jul 30, 2026, 4:18 AM

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
conductorone	🟡 Building	–	Jul 30, 2026, 4:16 AM

[c1-squire-dev]

Review v3 addressed

2a / 2b — done (383e3ae). Documented that a guardrail with no rules (or whose every rule is Disabled) matches nothing and is indistinguishable at call time from an unbound surface, and that a call matching no rule writes no guardrail_decision event — so "traffic arrived and matched nothing" and "no traffic arrived" are identical silence in the system log. Folded the second point into the Observe troubleshooting entry, which previously gave the right advice without explaining why both cases look the same.

No "system baseline rule" documented, per the review — the proto comment claiming one is stale; baseline is only an audit label (rule_kind) applied when nothing matched, not a rule object.

1 — gate filter patterns: staying out, by doc-owner decision.

The review is factually right and I confirmed it independently: AIGOV_GUARDRAIL_PRESETS doesn't exist on main (only on the unmerged saravana.venkatesan/FN-454/guardrail-presets), it's absent from the live c1dev flag list, and ToolGateFormDrawer.tsx has no flag check of its own — the pattern selector renders for anyone who can open the gate form. The two-things-called-preset distinction in the review is accurate.

I raised the contradiction with the doc owner rather than restoring unilaterally, and the decision is to keep them out. The gate filter is documented as a CEL expression entered directly, which is correct and complete for authoring a gate; the prefill helper is just undocumented. Re-raise if that changes.

Cross-page dependency — already resolved in this PR, not a follow-up.

The review flags tool-call-hooks.mdx as stale on three counts and suggests a separate PR. All three were fixed here:

Defect	Status
Hooks under AI > C1 Gateway > Settings	Fixed — now AI > Guardrails → General tab → Hooks section
5 of 11 built-in patterns documented	Fixed — all 11, plus a separate configuration/defaults table
"hooks cannot see the caller"	Fixed — caller block in both payload examples, with the warning that it's never an authorization input

That page also gained the pre-output event, event-dependent filter variables, the claw tool_source, corrected pattern defaults, and the Managed by guardrails section. So a reader following the Step 5 link lands on corrected content. No follow-up needed for those three.

Still open for product, not docs:

• guardrail_decision is missing from the published OCSF event catalog that /product/admin/system-log calls authoritative — a customer building a SIEM detection from that list won't find it. The docs give the literal filter values so they work regardless.
• Guardrail.default_outcome / default_deny_reason are settable via the public API and never read by the evaluator. Not a docs bug; an admin can set "default outcome = DENIED" and get silence.
• Observe is hard to consume as designed: no admin UI, no notification, no aggregate count, and informational severity means a warnings-and-above SIEM filter hides exactly what you're staging against.

[linear-code]

FN-570

[mindymo]

Screenshot verification: UI discrepancies found

I reviewed the new Classifiers/hooks/tool gate documentation against current screenshots of the actual UI. Style-wise the PR is in good shape (no docs-writing guide violations), but I found several places where the docs don't match what's in the product right now. Flagging for the project team before this ships:

1. Hook filter variables don't match. tool-call-hooks.mdx's "Filter variables by event" table says Pre-tool/Post-tool hooks only see ctx.tool_name, and Pre-output hooks see ctx.untrusted_class/ctx.surface. The actual hook filter field's helper text reads: "Available variables: ctx.tool_name, ctx.tool_input, ctx.surface, ctx.channel_id, ctx.workspace_id, ctx.user_roles" — and this list was identical regardless of which event was selected, so the doc's per-event split doesn't reflect current UI behavior.

2. An undocumented third Hook type exists. The Hook type dropdown offers Custom function, Built-in pattern, and Patch tool input. The docs only describe the first two.

3. Tool gates have an undocumented "Exclusions" section, including an "Exclude task result read-backs" checkbox that's checked by default. This isn't mentioned in either the configure guide (Step 4) or the tool gate fields table in the reference page.

4. Event isn't independently selectable for every Hook type — it's autopopulated and greyed out for two of the three. Custom function lets you choose Pre-tool use or Post-tool use; Built-in pattern autopopulates to Post-tool use (greyed out); Patch tool input autopopulates to Pre-tool use (greyed out). None of the three paths in the current UI expose Pre-output as a selectable event. The docs describe Pre-output extensively — as a hook event and as the stage for two built-in patterns (Block output, Link filter) — so the open question for the team is whether the Pre-output event has shipped in this build at all, not just a wording mismatch.

One thing that did check out correctly: the tool gate filter helper text ("Available variables include ctx.tool_name and ctx.tool_input") matches the doc's note exactly.

[mindymo]

Please see my PR comment, there are a few gaps here we need to address.

[sathyasaravanamuthu]

Review addressed

Verified all four points against the current frontend source (HookFormDrawer.tsx, ToolGateFormDrawer.tsx, patternTypes.ts, toolGateFilterSnippets.ts) rather than re-screenshotting, since the dev environment I'd used for the earlier live verification wasn't available. Confirmed and fixed in 929525d:

1. Hook filter variables — the doc's Pre-tool/Post-tool row listed only ctx.tool_name; the actual helper text (and the code's TOOL_USE_CTX_HINT) exposes six: ctx.tool_name, ctx.tool_input, ctx.surface, ctx.channel_id, ctx.workspace_id, ctx.user_roles. The Pre-output row was also missing ctx.user_roles. Both fixed, split into two tables with per-variable notes. The code is event-dependent (the helper text branches on currentEvent === PRE_OUTPUT), so if what you saw live looked identical across events, that's worth a second look separately — I couldn't reproduce it from source alone.

2. Patch tool input — confirmed real (HookFormDrawer.tsx:445, gated behind a preview flag, not by any per-hook-type UI logic). Added a new section: RFC 7396 merge-patch semantics, CEL-expression or static-fields source, locked to Pre-tool use, and a note that it still has its own top-level Filter field deciding whether it fires (separate from the patch source, which decides what to merge).

3. Tool gate Exclusions — confirmed (ToolGateFormDrawer.tsx + toolGateFilterSnippets.ts): two checkboxes, both on by default (Exclude task result read-backs, Exclude built-in tools), each ANDed onto the saved filter without touching what you typed. Documented in both the configure guide and the reference page.

4. Pre-output reachability — resolved with a concrete answer instead of an open question: Pre-output is selectable in the shipped UI, through two of the ten built-in patterns — Block output (locked to it) and Link filter (a real choice between Post-tool use and Pre-output; every other pattern locks to a single non-Pre-output event). Custom function hooks can't reach it; Patch tool input hooks are locked to Pre-tool use. Documented the full per-hook-type table.

One more mismatch found while verifying #4, not in your original list: the Built-in patterns table listed eleven patterns, but the proto (hooks.proto) defines thirteen and the frontend's pattern picker (patternTypes.ts) only wires up ten of those thirteen. The doc's eleven and the UI's ten don't overlap cleanly — it was missing two patterns the UI does offer (Block tool output, Pre-tool block) while including three the UI doesn't offer at all (Secrets masking, Encoded content guard, Prompt injection scan — defined in the proto, absent from patternMetaList, so there's no picker entry for them regardless of tenant/flag state as far as I can find in the frontend source). Added the two real ones with their actual config (a single deny-message field each), and flagged the three UI-unreachable ones with a note rather than silently deleting them, in case there's a flag or rollout path I'm not seeing from source alone — happy to remove them outright if you confirm they're not coming.