Skip to main content

Documentation Index

Fetch the complete documentation index at: https://www.c1.ai/docs/llms.txt

Use this file to discover all available pages before exploring further.

Activation required. AI access management must be enabled for your tenant before you can use it. To get started, contact the C1 support team for a walkthrough.
Tool call hooks are interception points that run on every governed MCP tool call. They can observe a call, modify its inputs or outputs, or deny it outright. Use them to redact sensitive data, cap risky parameters, or enforce conditional access rules that see beyond the entitlement grant model.

​
How hooks work

Each hook fires on one of two events:
EventWhen it runsWhat it can do
Pre-tool useBefore C1 forwards the call to the MCP serverInspect or rewrite the input, or deny the call
Post-tool useAfter the MCP server returnsInspect or rewrite the output, or deny the response from reaching the client
Hooks run in priority order (lower priority numbers run first). Each hook is independently enabled or disabled and can be scoped to specific tools with a CEL filter expression. Multiple hooks can stack on the same call — input or output modifications from earlier hooks are passed to later ones, and any hook can short-circuit the chain by denying. Hooks are fail-closed. If a hook errors, times out, or its filter expression fails to evaluate, the call is denied. Custom function hooks have a 60-second invocation timeout. Every hook execution is recorded in the audit log with one of these statuses: ALLOWED, MUTATED, DENIED, ERROR, TIMEOUT, or FILTER_ERROR.

​
Configure a hook

1
Go to Settings > AI Governance and open the Hooks tab.
2
Click Add hook.
3
Fill out the form:
FieldNotes
NameRequired. 1–100 characters.
DescriptionOptional. Up to 2048 characters.
Hook typeBuilt-in pattern for one of the patterns below, or Custom function to invoke a function.
EventPre-tool use or Post-tool use. Some built-in patterns only support one event.
FilterOptional CEL expression. Available variable: ctx.tool_name. Empty matches all tools. Example: ctx.tool_name.startsWith("github_").
Priority0–1000. Lower runs first.
EnabledToggle on to activate the hook immediately on save.
4
If you selected Built-in pattern, choose the pattern and configure its options. If you selected Custom function, pick the function from the dropdown.
5
Click Save.

​
Built-in patterns

C1 ships five pre-built hook patterns. Each one is a self-contained handler with its own configuration; no function code is required.
PatternEventWhat it does
PII field redactionPostReplaces values in JSON output fields whose names match a configurable list (defaults: ssn, social_security_number, date_of_birth, salary, bank_account) with a placeholder string.
Credit card blockingPostScans tool output for Luhn-valid credit card numbers and denies the response if any are found.
Query scope limitPreCaps numeric input fields (defaults: limit, page_size, count, max_results) at a configured maximum to prevent oversized queries.
Write authorizationPreDenies tool calls whose classification is in a blocked list, optionally only outside a configured business-hours window (timezone, start/end times, days of the week).
Sensitive file guardPreDenies tool calls that reference sensitive file paths or directories (defaults: .env, *.pem, *.key, id_rsa, .ssh/, .aws/, and similar).

​
Custom function hooks

When the built-in patterns don’t fit, write a function and attach it to a hook. C1 invokes the function with a JSON payload describing the call and uses the return value to decide whether to allow, modify, or deny. See the Functions overview and Create a function for how to author and deploy a function.

​
Pre-tool-use payload

The function receives: 
{
  "tool_name": "github_create_issue",
  "input": { /* the tool's input arguments */ },
  "context": {
    "tool_source": "connector",
    "classification": "WRITE"
  }
}
tool_source is either builtin or connector. classification is the tool’s configured action class (READ, WRITE, DESTRUCTIVE, SENSITIVE, or DANGEROUS).

​
Post-tool-use payload

The function receives the same fields plus the call result: 
{
  "tool_name": "github_create_issue",
  "input": { /* original input */ },
  "output": { /* whatever the tool returned */ },
  "error": "",
  "context": { /* same as pre */ }
}

​
Return value

In both events the function returns an object with any subset of these fields: 
{
  "deny": false,
  "reason": "explanation shown in audit log",
  "input":  { /* pre only: replacement input */ },
  "output": { /* post only: replacement output */ }
}
  • Set deny: true to block the call. The reason is recorded in the audit log and surfaced to the AI client as a denial.
  • Omit input (pre) or output (post) when you don’t need to modify the payload.
  • Returning an empty object {} is equivalent to allowing the call unchanged.
If the function throws, exceeds the 60-second timeout, or returns invalid JSON, the call is denied and the failure is recorded as ERROR or TIMEOUT in the audit log.