# Governance

Governance lets you automatically screen agent outputs and incoming source content against a configurable set of safety, privacy, and compliance policies. When content violates a policy, Seclai flags or blocks it so you can review it before it reaches end users.

> **Governance is one of three safety layers** in Seclai. It screens content against your compliance rules, while the [prompt scanner](https://seclai.com/docs/prompt-scanner) blocks injection attacks at ingress, and [agent evaluations](https://seclai.com/docs/agent-evaluations) validate output quality. See the [Safety & Quality Overview](https://seclai.com/docs/safety-overview) for a comparison of all three.

## Why Governance Matters

LLMs are probabilistic — they can produce outputs that are factually wrong, biased, legally risky, or off-brand even when your prompt and data are perfectly clean. Unlike traditional software where outputs are deterministic, every model call carries a non-zero chance of producing something you wouldn't want your users to see.

This creates a new category of production risk that traditional software testing doesn't cover:

- **Safety** — Models can generate harmful, violent, or sexually explicit content, especially when adversarial inputs slip through.
- **Privacy** — Models sometimes surface personally identifiable information (PII) from their training data or from the context you provide, even when not asked for it.
- **Bias** — Outputs can reflect or amplify societal biases in ways that damage trust and may violate anti-discrimination requirements.
- **Legal exposure** — Reproducing copyrighted text, generating defamatory claims, or making regulated statements (medical, financial, legal advice) without disclaimers creates real legal liability.
- **Brand reputation** — Off-brand tone, competitor mentions, or confidential information leaking into user-facing outputs can erode trust quickly.

Manual review doesn't scale — you can't have a human read every LLM response before it ships. Governance automates this screening: every piece of content is evaluated against your policies the moment it's produced, and anything that violates a policy is flagged or blocked before it reaches end users.

Seclai's governance system is designed to make this practical at production scale — configurable policies, multiple evaluation tiers to balance cost and accuracy, scoped enforcement so you can be strict where it matters and lightweight where it doesn't, and a review queue for human oversight when the system flags something.

## Plan Requirement

Governance features are **not available on all plans**. Your subscription must include the **governance access** entitlement. When governance access is not included:

- The **Governance** page shows an upgrade prompt with a blurred overlay instead of the normal interface
- REST API requests to any `/governance/` endpoint will be rejected
- MCP governance tools will return an error: _"Governance is not available on your current plan"_

To check whether your plan includes governance, visit **Settings → Account** and look for the governance access indicator, or check the `plan_governance_access` field in the account API response.

If you need governance but your current plan does not include it, upgrade from the **Settings → Subscription** page.

---

## Overview

**Example scenarios where governance helps:**

- A customer support agent accidentally includes a customer's full credit card number in its response. A **PII policy** catches this and blocks the output before it reaches the end user.
- Your marketing agent generates a blog post that mentions a competitor by name and makes unfounded comparison claims. A **brand policy** flags the content for human review before publication.
- A legal research agent summarizes case law but inadvertently reproduces copyrighted text verbatim. A **legal policy** detects the lengthy verbatim passage and blocks it.
- An internal knowledge agent surfaces confidential project codenames in a response to an external user. A **custom policy** screening for internal-only terms flags the output.
- A content syndication source starts ingesting articles containing hate speech. A **content safety policy** on the source connection flags the items during polling — before they ever enter your knowledge base.

In each case, governance catches the problem _after_ the agent or source produces the content but _before_ it reaches end users — giving you a safety net for compliance, privacy, and brand reputation.

---

The Governance system has five parts:

1. **Policies** — Rules that define what content is acceptable (e.g. "block personally identifiable information", "flag biased language")
2. **Settings** — Controls that determine _where_ and _how_ screening is applied (which agents, sources, and steps)
3. **Evaluations** — Individual screening results generated when content is checked against a policy
4. **Knowledge Base Associations** — Optional links between policies and knowledge bases that provide evidence-based evaluation using similarity search
5. **AI Assistant** — A natural-language interface for managing policies using a propose-then-accept workflow

You manage all five from the **Governance** section in the left sidebar.

---

## Core Concepts

### Policies

A governance policy defines what the evaluator checks for. Each policy consists of:

| Component                       | Description                                                                                                                                                                                                                                     |
| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Policy text**                 | The policy text that tells the AI evaluator what to look for. Can come from the built-in sample policy library or be written as custom text.                                                                                                    |
| **Thresholds**                  | A _flag threshold_ and _block threshold_ that determine the severity response based on the evaluator's confidence score.                                                                                                                        |
| **Scope**                       | Where the policy applies: account-wide, a specific agent, a specific step, or a specific source connection.                                                                                                                                     |
| **Enabled**                     | Whether the policy is active. Disabled policies are skipped during screening.                                                                                                                                                                   |
| **Enforcement level**           | Controls how child scopes can modify this policy (flexible, required, or locked). See [Enforcement Levels](#enforcement-levels).                                                                                                                |
| **Inheritance mode**            | _(Scoped policies only.)_ How a scoped policy relates to its parent's policy for the same document (inherit, merge, or disable). Account-level policies have no parent so this field is not shown. See [Inheritance Modes](#inheritance-modes). |
| **Knowledge base associations** | Optional links to knowledge bases that provide similarity-based evidence during evaluation. See [Knowledge Base Associations](#knowledge-base-associations).                                                                                    |

### Policy Categories

The examples are organized into five categories:

| Category           | Slug                        | What it detects                                                                              |
| ------------------ | --------------------------- | -------------------------------------------------------------------------------------------- |
| **Content Safety** | <code>content_safety</code> | Harmful, violent, hateful, or sexually explicit content                                      |
| **PII**            | <code>pii</code>            | Personally identifiable information such as names, emails, phone numbers, and government IDs |
| **Bias**           | <code>bias</code>           | Biased, discriminatory, or stereotyping language                                             |
| **Legal**          | <code>legal</code>          | Legal risks including copyright violations, defamation, and regulatory non-compliance        |
| **Brand**          | <code>brand</code>          | Off-brand messaging, competitor mentions, or tone violations                                 |

### Verdicts

When content is evaluated against a policy, the evaluator produces a **confidence score** from 0.0 (no match) to 1.0 (certain match). That score is compared against the policy's thresholds to produce one of three verdicts:

| Verdict   | Condition                                    | Default behavior                                             |
| --------- | -------------------------------------------- | ------------------------------------------------------------ |
| **Pass**  | Score < flag threshold                       | Content proceeds normally                                    |
| **Flag**  | Score ≥ flag threshold and < block threshold | Content proceeds but is queued for human review              |
| **Block** | Score ≥ block threshold                      | Content is withheld until a reviewer resolves the evaluation |

**Example:** With the default thresholds (flag = 0.5, block = 0.8), a score of 0.65 produces a **flag** verdict. The content is delivered but appears in the Review queue for a human to check.

### Screening Points

Governance evaluations happen at specific points in the pipeline:

| Screening point             | When it runs                                    | Typical use                                                      |
| --------------------------- | ----------------------------------------------- | ---------------------------------------------------------------- |
| **Source content**          | When a content source imports new items         | Screen incoming data before it enters your knowledge base        |
| **Agent input**             | Before an agent run begins processing           | Screen user-provided input to agents                             |
| **Step input**              | Before a step sends data to an external service | Screen outgoing URLs, payloads, and queries (web fetch, webhook) |
| **Step output**             | After an agent step completes                   | Screen AI-generated outputs before they're returned              |
| **Policy test**             | When you manually test content in the Test tab  | Ad-hoc testing during policy development                         |
| **Policy test (in review)** | After opting a test evaluation into review      | Promote test results to the Review queue for tracking            |

**Step input screening** applies to steps that send data to external services: **web fetch**, **web search**, and **webhook call**. This catches policy violations in outgoing requests _before_ they leave your agent — for example, preventing PII from being sent to a third-party API.

> **Tip:** Policy test evaluations are not visible in the Review queue by default. If you want a test result to appear alongside production evaluations for review, use the [opt-into-review](#opting-test-results-into-review) action.

*Figure: Screening points in an agent pipeline — input governance screens the user's message before processing, while output governance evaluates the final result asynchronously.*

*Figure: Source content governance — incoming content is scanned for injection and evaluated against policies before indexing to a knowledge base.*

### Policy Actions: Observe, Enforce, Redact

Every policy has an **action** that controls how the agent pipeline reacts to violations. The three modes trade off pipeline impact against the strength of the response:

| Action      | Pipeline behavior                                                                       | Modifies content?                                                            | Streaming-compatible?                | Latency added per step  | Best for                                                              |
| ----------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ------------------------------------ | ----------------------- | --------------------------------------------------------------------- |
| **Observe** | Evaluation runs asynchronously after the agent continues.                               | No                                                                           | Yes                                  | None                    | Monitoring, audit trails, rollout before promoting to Enforce/Redact  |
| **Enforce** | Agent pauses for evaluation; a `BLOCK` verdict halts the run.                           | No (halt or pass)                                                            | **No** (disables real-time delivery) | ~1–6 s (tier-dependent) | Hard policy boundaries — safety, compliance, fraud                    |
| **Redact**  | Agent pauses while a redactor LLM rewrites the violating spans, then the run continues. | **Yes** (replaces violations with `[REDACTED]`, `[EMAIL]`, or a custom mask) | **Yes** (sentence-bounded buffer)    | ~0.5–2 s per sentence   | Short, locally-recognisable violations — PII, profanity, banned terms |

**Observe** is the audit-only baseline. The classifier still runs and produces `PASS` / `FLAG` / `BLOCK` verdicts that show up on the [Review tab](https://seclai.com/docs/governance#review-tab), but the agent never waits and never halts. Use this to tune thresholds and spot patterns before promoting a policy to a stronger action.

**Enforce** is the binary safety net. The agent pauses on the relevant step until the classifier returns; a `BLOCK` verdict raises and stops the run. Because the verdict has to come back before any content can be released, **Enforce disables real-time streaming** on agents that have a `streaming_result` step — tokens can't be emitted before the classifier has seen the full output. Use this for policies where any violation slipping through is unacceptable.

**Redact** is the fine-grained alternative. Instead of halting on a violation, a small, fast redactor LLM (Bedrock Amazon Nova 2 Lite) rewrites the offending spans out of the content and the agent continues. **Redact is streaming-compatible**: the runtime wraps the token iterator with a sentence-bounded buffer, runs each sentence through the redactor, then emits the rewrite — so chatbots in regulated industries still see live responses. The redactor is best at short, locally-recognisable violations like PII shapes, profanity, banned phrases, or specific brand terms. It is **not** suited for nuanced or multi-sentence violations like subtle bias or long-form legal/medical advice; the redactor's prompt explicitly excludes those, and enabling Redact on a broad legal/medical/financial policy will silently no-op the violation. Use Enforce for those rules and a narrower Redact policy for known banned phrases.

**Per-policy redaction message.** Redact policies can carry an optional `redaction_message` — a fixed string the redactor uses verbatim in place of every violating span. Leave it empty to use the default `[REDACTED]` mask, or set operator-owned copy like `[Customer info redacted by Acme compliance]` for a consistent user-facing result.

**Mutual exclusion.** Enforce and Redact policies cannot coexist on the same scope **and** the same screening point: e.g. you cannot have both Enforce(output) and Redact(output) on the same agent. The semantics conflict — does a violation halt the run or get rewritten? Pick one per (scope, screening point). Mixing across screening points is fine: Enforce(input) + Redact(output) on the same scope is allowed, since the two policies fire at different junctures in the run. Observe coexists with either.

**Streaming-result steps.** Per-step policies on a `streaming_result` step are restricted to Observe or Redact at the API level; Enforce on that scope is rejected. ENFORCE would defeat real-time streaming, so the editor hides the option and the API returns a structured `422`.

*Figure: Enforce: the terminal step pauses for evaluation; a BLOCK verdict halts the run.*

*Figure: Observe: evaluation runs asynchronously and the agent continues immediately.*

> **Tip:** Start with **Observe** to learn your violation patterns. Promote to **Enforce** for hard refusal cases where any violation must not be delivered, or to **Redact** for short PII / profanity / banned phrase rules — you can also stack a broad Enforce policy with a narrow Redact policy on a different scope.

### Evaluation Tiers

The evaluation tier controls which AI model the evaluator uses, trading off between speed, cost, and thoroughness:

| Tier         | Speed      | Cost      | Accuracy                        | Best for                                  |
| ------------ | ---------- | --------- | ------------------------------- | ----------------------------------------- |
| **Fast**     | ⚡ Fastest | Lowest    | Good for clear-cut violations   | High-volume screening, simple policies    |
| **Balanced** | Moderate   | Mid-range | Strong general-purpose accuracy | Most production use cases                 |
| **Thorough** | Slowest    | Highest   | Best nuanced judgment           | Complex policies, legal/compliance review |

You can set the evaluation tier at any scope level (account-wide, per-agent, per-source). Lower scopes inherit from their parent unless overridden.

### Performance & Cost Impact

Governance evaluation has different performance characteristics depending on how you configure it:

| Configuration                      | Latency added to agent runs                 | Credit cost per step           |
| ---------------------------------- | ------------------------------------------- | ------------------------------ |
| **No policies**                    | None                                        | None                           |
| **Observe policies only**          | None                                        | Per evaluation (async)         |
| **Redact policies (per sentence)** | &lt;200ms streaming, ~0.5–1 seconds regular | One redactor call per sentence |
| **Enforce policies (Fast tier)**   | ~1–2 seconds per step                       | Lowest per eval                |
| **Enforce policies (Balanced)**    | ~2–4 seconds per step                       | Moderate per eval              |
| **Enforce policies (Thorough)**    | ~3–6 seconds per step                       | Highest per eval               |

Seclai minimizes evaluation latency with several optimizations:

- **Pre-resolved policies** — effective policies are computed once when the agent run starts, not on every step
- **Parallel evaluation** — when multiple Enforce policies apply to a step, they are evaluated concurrently rather than sequentially
- **Batched evaluation** — Observe Fast-tier policies without knowledge base associations are combined into a single LLM call
- **Cached settings** — governance configuration is cached so it doesn't require a database query per step
- **Streaming-friendly Redact** — for streaming agents, the redactor wraps the token iterator with a sentence-bounded buffer so users still see live responses

For the best balance of safety and performance, use **Enforce** for your most critical refusal cases, **Redact** for short locally-recognisable violations on streaming agents, and **Observe** for everything else. The Fast tier is often sufficient for clear-cut violations; reserve Balanced or Thorough for nuanced policies where accuracy matters more than speed.

---

## Scoping Model

Both policies and settings support hierarchical scoping:

```
Account (broadest)
  └─ Agent
       └─ Agent Step
  └─ Source Connection
```

**How policy scoping works:**

- **Account-wide policies** apply to all agents and sources unless a narrower scope exists.
- **Agent-scoped policies** apply only to that agent's runs. They are _additive_ — the agent gets both account-wide and agent-scoped policies.
- **Step-scoped policies** apply only to a specific step within an agent.
- **Source-scoped policies** apply only to content from that source.

**How settings scoping works:**

Settings use a **most-specific-wins** override model. If an agent has its own governance settings, those override the account-wide settings for that agent. If a specific step has settings, those override the agent-level settings for that step.

**Example:** You enable governance account-wide with the "balanced" tier but set one high-volume agent to use the "fast" tier. The agent-scoped setting overrides only the tier; all other settings (e.g., `review_output`) still inherit from the account level.

### Enforcement Levels

Every policy has an **enforcement level** that controls how child scopes can interact with it. This is set on the parent-scope policy.

| Level        | Description                                                                                |
| ------------ | ------------------------------------------------------------------------------------------ |
| **Flexible** | Child scopes may merge alongside this policy or disable it entirely. This is the default.  |
| **Required** | Child scopes may merge (evaluate alongside) but **cannot** disable this policy.            |
| **Locked**   | Child scopes cannot merge or disable. The policy applies exactly as defined at this scope. |

**Example:** An account-wide PII policy with enforcement level **Required** ensures that every agent and source is always screened for PII. An agent-scoped policy can merge additional rules alongside it, but cannot suppress the PII check.

### Inheritance Modes

> **Note:** Inheritance mode only applies to **scoped policies** (agent, step, or source). Account-level policies have no parent scope, so inheritance mode is not shown when creating or editing account-wide policies.

When you create a scoped policy (agent-level, step-level, or source-level), the **inheritance mode** declares how the child relates to the parent:

| Mode        | Description                                                                                                                       |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------- |
| **Merge**   | Both the parent policy _and_ this child's evaluation run side by side. Useful for adding stricter thresholds at a narrower scope. |
| **Disable** | Suppress the parent policy at this scope. Only allowed when the parent's enforcement level is **Flexible**.                       |

**Validation rules:**

- Setting inheritance mode to **Disable** when the parent's enforcement level is **Required** or **Locked** will be rejected.
- Setting inheritance mode to **Merge** when the parent's enforcement level is **Locked** will be rejected.
- **Inherit** is always allowed regardless of the parent's enforcement level.

### Choosing the Right Scope

The scope at which you define a policy determines its blast radius, testability, and maintenance cost. As a general rule, prefer the narrowest scope that covers your use case:

| Scope            | Precision                                      | Testability                                                      | Best for                                                                                        |
| ---------------- | ---------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **Step-level**   | Highest — targets a single well-defined output | Easiest — you know exactly what content the policy will evaluate | Protecting specific delivery points (e.g. an email step that must never contain PII)            |
| **Agent-level**  | High — covers all output steps of one agent    | Straightforward — test with representative inputs for that agent | Agents with domain-specific compliance requirements                                             |
| **Account-wide** | Broadest — applies to every agent and source   | Hardest — must work across all content types and contexts        | Organization-wide rules that must never be bypassed (e.g. regulated industries, legal mandates) |

**Guidance:**

- **Start at the step level** when you know which step produces the sensitive output. Step-level policies have the most well-defined scope, making them the easiest to test, tune, and update without unintended side effects elsewhere.
- **Move to agent level** when multiple steps in the same agent need the same policy, or when the policy applies to the agent's overall behavior rather than one specific output.
- **Use account-wide policies sparingly.** They add evaluation overhead to every agent and source in your account. They are appropriate for hard compliance requirements (e.g. "never output content in language X" in a regulated industry) but heavy-handed for narrower concerns.

**On policy actions and latency:**

**Enforce** policies add evaluation latency because the pipeline must wait for the verdict before delivering output. **Redact** policies add latency too, but it's bounded per sentence rather than per step, and streaming continues. **Observe** adds no latency at all — evaluation is async after the agent has continued.

- Pair Enforce with the **narrowest scope possible** to limit the latency impact. An Enforce policy scoped to one step only adds latency to that step, not the entire agent.
- For monitoring and trend detection, prefer **Observe** — it captures the same data without impacting agent response time.
- For streaming agents, prefer **Redact** over Enforce — Enforce disables streaming entirely, while Redact rewrites violations between sentence boundaries and the user still sees a live response.
- When you need account-wide Enforce, use the **Fast** evaluation tier to minimize the per-step delay.

---

## Knowledge Base Associations

Policies can be linked to one or more **knowledge bases** to enable evidence-based evaluation. When a policy has knowledge base associations, the evaluator performs a similarity search against each linked knowledge base before scoring and uses the retrieved content as evidence in the evaluation.

This is useful for:

- **Known-bad content detection** — link a knowledge base containing examples of prohibited content; high-similarity matches provide strong evidence for blocking.
- **Reference-based compliance** — link a knowledge base with regulatory text or brand guidelines so the evaluator can check content against authoritative references.
- **Contextual screening** — provide domain-specific context that helps the evaluator make more informed judgments.

### Match Actions

Each knowledge base association has a **match action** that tells the evaluator how to interpret similarity matches:

| Match action | Description                                                                                                       |
| ------------ | ----------------------------------------------------------------------------------------------------------------- |
| **Block**    | High-similarity matches are strong evidence the content should be blocked (e.g. known-bad examples).              |
| **Flag**     | High-similarity matches suggest the content should be flagged for human review.                                   |
| **Inform**   | Matches are provided as context and reference to the evaluator LLM with no enforcement bias. This is the default. |

Each association also has a **position** (starting from 0) that controls the order in which knowledge bases are queried. Lower positions are queried first.

### Circularity Detection

When a policy is scoped to an agent or source, linking a knowledge base that is _sourced from_ the same agent or source can create a **circular reference** — the governance system would be using the content it's supposed to screen as evidence for screening decisions.

Seclai automatically detects circular knowledge bases and prevents you from creating these associations:

- **In the UI:** Knowledge bases that would create a circular reference are marked and cannot be selected when editing a policy's associations.
- **In the API and MCP:** The `set_policy_knowledge_bases` endpoint returns an error if any of the specified knowledge bases would create a circular reference.
- **Detection endpoint:** Use the `GET /policies/circular-knowledge-bases` endpoint or the `get_circular_knowledge_bases` MCP tool to retrieve the list of knowledge base IDs that would be circular for a given scope. Pass `agent_id` or `source_connection_id` to check for a specific scope.

---

## Getting Started

### Enabling Governance

Once your plan supports governance:

1. Go to **Governance** in the left sidebar
2. The Overview tab shows your current status
3. Use the Settings to enable governance and configure screening options

Once enabled at the account level, governance will screen content at the configured screening points.

### Creating a Policy

To create an account-wide policy from a sample policy:

1. Go to **Governance → Policies**
2. Click **Add Policy**
3. Toggle off **"Use AI assistant"** to see the manual form
4. In the **Sample policies** section, browse the examples and click one to populate the form
5. Optionally adjust the name, flag and block thresholds, and enforcement level
6. Click **Create Policy**

To create an account-wide policy:

1. Click **Add Policy**
2. Toggle off **"Use AI assistant"**
3. Alternatively, use a sample starter (Content Safety, PII Detection) or write your own policy text from scratch (see [Writing Effective Policies](#writing-effective-policies))
4. Set thresholds and enforcement level
5. Click **Create Policy**

> **Note:** The Add Policy page creates **account-wide** policies. Account-wide policies have no parent scope, so inheritance mode is not shown here. To create **scoped policies** (agent, step, or source level), use the Governance panel on the resource's detail page — see [Scoped Policy Overrides](#scoped-policy-overrides) below.

**Via API:**

```bash
# Account-wide policy from a sample policy
curl -X POST \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/policies \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "sample_slug": "content-safety",
    "policy_name": "Content Safety",
    "policy_text": "Do not allow harmful, violent, or explicit content.",
    "category": "content_safety",
    "flag_threshold": 0.5,
    "block_threshold": 0.8,
    "enforcement_level": "flexible",
    "action": "enforce"
  }'

# Custom policy text (account-wide) — Observe-only audit
curl -X POST \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/policies \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "policy_name": "Competitor Mentions",
    "policy_text": "Flag any content that mentions competitor product names.",
    "category": "brand",
    "flag_threshold": 0.4,
    "block_threshold": 0.9,
    "enforcement_level": "required",
    "action": "observe"
  }'

# Redact-action policy with a custom substitution string
curl -X POST \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/policies \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "policy_name": "PII Redactor",
    "policy_text": "Redact email addresses and phone numbers.",
    "category": "pii",
    "action": "redact",
    "redaction_message": "[Customer info redacted by Acme compliance]"
  }'

# Agent-scoped policy override (inheritance_mode applies to scoped policies)
curl -X POST \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/policies \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "sample_slug": "content-safety",
    "policy_name": "Content Safety",
    "policy_text": "Do not allow harmful, violent, or explicit content.",
    "category": "content_safety",
    "agent_id": "AGENT_UUID",
    "enforcement_level": "required",
    "inheritance_mode": "merge",
    "action": "enforce"
  }'
```

### Scoped Policy Overrides

In addition to account-wide policies (created from the Policies page), you can create **scoped policy overrides** that apply only to a specific agent, agent step, or content source. Scoped policies are created from the **Governance panel** on each resource's detail page.

**For agents:**

1. Open an agent's detail page
2. Switch to the **Governance** tab
3. In the Policy Overrides section, click **Add Policy Override**
4. Choose a sample policy or enter custom policy text
5. Set the enforcement level and inheritance mode — since scoped policies have a parent (the account-level policy), inheritance mode controls how this override relates to the parent
6. Click **Create**

**For agent steps:**

1. Open an agent's detail page and click **Edit** on a step
2. In the step edit modal, scroll to the **Governance** tab
3. Follow the same process as above — the policy will be scoped to that specific step

**For content sources:**

1. Open a source connection's detail page
2. Switch to the **Governance** tab
3. Follow the same process — the policy will be scoped to that source

Each scoped policy also has a **link icon** that navigates to the full policy edit page, where you can adjust thresholds, view knowledge base associations, and see the policy's scope badge.

> **Tip:** Use the `create_governance_policy` MCP tool with `agent_id`, `agent_step_id`, or `source_connection_id` parameters to create scoped policies programmatically. See the [MCP Tools](#mcp-tools) section.

### Configuring Thresholds

Each policy has two thresholds that control how strictly it's enforced:

| Threshold           | Default | Effect                                                       |
| ------------------- | ------- | ------------------------------------------------------------ |
| **Flag threshold**  | 0.5     | Content scoring at or above this value is flagged for review |
| **Block threshold** | 0.8     | Content scoring at or above this value is blocked entirely   |

**Tuning guidelines:**

- **Lower the flag threshold** (e.g. 0.3) to catch more borderline cases at the cost of more false positives
- **Raise the flag threshold** (e.g. 0.7) to reduce review noise, only flagging high-confidence matches
- **Lower the block threshold** (e.g. 0.6) for zero-tolerance policies where you'd rather over-block than miss something
- **Raise the block threshold** (e.g. 0.95) when you only want to block near-certain violations
- The block threshold must always be ≥ the flag threshold

Use the [Test tab](#testing-policies) to experiment with different thresholds before applying them to production policies.

### Configuring Settings

Governance settings control _where_ screening happens:

| Setting                | Default         | Description                                                           |
| ---------------------- | --------------- | --------------------------------------------------------------------- |
| **Governance enabled** | true            | Master toggle for governance at this scope                            |
| **Review output**      | true            | Screen agent step outputs against policies                            |
| **Review input**       | false           | Screen agent/user inputs and imported source content against policies |
| **Evaluation tier**    | null (inherits) | AI model tier: fast, balanced, or thorough                            |

Settings can be configured at the account level via the API or MCP tools, or per-agent/per-source from the resource's detail page (using the Governance panel).

**Via API:**

```bash
# Enable input screening for a specific source
curl -X PUT \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/settings \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "source_connection_id": "SOURCE_UUID",
    "review_input": true,
    "governance_enabled": true
  }'
```

### Linking Knowledge Bases

To enhance a policy with evidence-based evaluation, link one or more knowledge bases:

1. Go to **Governance → Policies**
2. Click on a policy to open its detail view
3. In the **Knowledge Bases** section, click **Add Knowledge Base**
4. Select a knowledge base from the list (circular references are automatically disabled)
5. Choose a **match action** for each association:
   - **Block** — similarity matches are treated as strong evidence for blocking
   - **Flag** — similarity matches suggest the content should be flagged
   - **Inform** — matches are provided as context only (default)
6. Drag to reorder associations by priority (position 0 is queried first)
7. Click **Save**

**Via API:**

```bash
# Replace all KB associations for a policy
curl -X PUT \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/policies/{policy_id}/knowledge-bases \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "knowledge_bases": [
      {
        "knowledge_base_id": "KB_UUID_1",
        "match_action": "block",
        "position": 0
      },
      {
        "knowledge_base_id": "KB_UUID_2",
        "match_action": "inform",
        "position": 1
      }
    ]
  }'

# List current associations
curl https://api.seclai.com/authenticated/accounts/{account_id}/governance/policies/{policy_id}/knowledge-bases \
  -H "Authorization: Bearer YOUR_TOKEN"

# Check which KBs would be circular for an agent-scoped policy
curl "https://api.seclai.com/authenticated/accounts/{account_id}/governance/policies/circular-knowledge-bases?agent_id=AGENT_UUID" \
  -H "Authorization: Bearer YOUR_TOKEN"
```

---

## Writing Effective Policies

When the built-in policy library doesn't cover your needs, you can write custom policy text. The policy text is the instruction given to the AI evaluator — it determines what the model looks for when screening content.

### Policy Structure

An effective policy text should include:

1. **What to detect** — a clear description of the content pattern to flag
2. **Examples** — concrete examples of violating content (helps the model calibrate)
3. **Non-examples** (optional) — examples of acceptable content that might look similar
4. **Severity guidance** (optional) — what constitutes a minor vs. major violation

```
Detect any content that contains pricing information for competitor products.

Examples of violations:
- "CompetitorX charges $49/month for their basic plan"
- "Switching from RivalCo saves you 30%"
- "Their enterprise tier starts at $500/seat"

Not violations:
- "Our pricing starts at $15/month"
- "Compare plans on our pricing page"
- General industry pricing trends without naming competitors
```

### Best Practices

- **Be specific.** Vague policies like "flag bad content" produce inconsistent results. State exactly what constitutes a violation.
- **Include 3–5 examples.** Examples dramatically improve evaluator accuracy, especially for domain-specific policies.
- **Test before deploying.** Use the Test tab to verify your policy catches what you expect and doesn't over-flag acceptable content.
- **Start with higher thresholds.** Begin with flag = 0.6 and block = 0.9, then lower them after reviewing initial results.
- **One concern per policy.** A policy that tries to detect PII _and_ brand violations will be less accurate than two separate policies.
- **Use the Thorough tier for complex policies.** Simple pattern-matching policies work well with the Fast tier, but nuanced judgment calls benefit from the Thorough tier.
- **Review and iterate.** Check the Review queue regularly and adjust policies based on false positive/negative patterns.

### Example Policies

**Medical advice detection:**

```
Flag any content that provides specific medical diagnoses, treatment
recommendations, or medication dosage advice. General health information
and wellness tips are acceptable.

Violations:
- "Based on your symptoms, you likely have strep throat"
- "Take 400mg of ibuprofen every 6 hours"
- "You should discontinue your current medication"

Not violations:
- "Consider consulting a healthcare provider"
- "Regular exercise can improve cardiovascular health"
- "The CDC recommends annual flu vaccinations"
```

**Financial advice detection:**

```
Flag content that provides specific investment recommendations, price
predictions, or personalized financial advice.

Violations:
- "You should buy AAPL stock now"
- "Bitcoin will reach $200k by next year"
- "Move your 401k into bonds"

Not violations:
- "Diversification is a common investment strategy"
- "Historical market returns have averaged ~10% annually"
- "Consult a financial advisor for personalized advice"
```

**Internal-only information:**

```
Flag any content that references internal project codenames, unreleased
product features, or internal-only URLs.

Violations:
- References to "Project Phoenix" or "Project Titan"
- URLs containing "internal.company.com" or "staging.company.com"
- "The upcoming v3.0 release will include..."

Not violations:
- Publicly announced product features
- Public documentation URLs
- General product roadmap statements already shared externally
```

---

## Monitoring & Review

### Overview Dashboard

The **Overview** tab provides a real-time summary of governance activity:

- **Total evaluations** — how many pieces of content have been screened
- **Pass / Flag / Block counts** — breakdown by verdict
- **Unresolved flags and blocks** — items awaiting human review
- **By screening point** — where evaluations are occurring (source content, agent input, step output)
- **By category** — which policy categories are triggering most often

Use this dashboard to spot trends: a sudden spike in flags might indicate a policy that's too sensitive, while zero evaluations might mean governance isn't enabled where you expect it.

### Reviewing Evaluations

The **Review** tab shows all evaluations that need attention:

1. **Filter** by verdict (flag/block), screening point, date range, agent, or source
2. **Review** each evaluation: see the content excerpt, policy name, confidence score, and AI explanation
3. **Resolve** evaluations after review (see below)

### Resolving Evaluations

When you resolve an evaluation, you're marking it as reviewed. This serves as an audit trail and clears the item from the unresolved queue.

- Click **Resolve** on an evaluation
- Optionally add a **resolution note** (e.g., "False positive — content is acceptable", "Confirmed violation — notified content team")
- The evaluation is timestamped with your name and note

**Via API:**

```bash
curl -X POST \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/evaluations/{evaluation_id}/resolve \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"resolution_note": "False positive — acceptable context"}'
```

---

## Testing Policies

### How Testing Works

The **Test** tab lets you evaluate content against your policies without affecting real agent runs or source pulls:

1. Go to **Governance → Test**
2. Paste or type the content you want to test
3. Optionally select a specific policy (or test against all active policies)
4. Click **Test**
5. Review the results: each policy produces an evaluation with a score, verdict, and explanation

Testing uses the same evaluator as production screening, so results accurately reflect what would happen in a live run.

> **Note:** The Test tab is disabled when no active policies exist. Create or enable at least one policy to use it.

### Testing Draft Policies

You can test content against a **draft policy** that hasn't been saved yet. This is useful when writing a new custom policy and you want to iterate on the policy text before committing it.

Draft testing lets you specify:

- **Content** — the text to evaluate
- **Policy text** — the draft policy text to evaluate against
- **Thresholds** — optional flag and block thresholds (defaults: 0.5 and 0.8)
- **Knowledge base associations** — optional list of knowledge bases to include in the evaluation, each with a match action and position

The draft policy is not persisted. Evaluation results are returned immediately but are not stored as permanent evaluations.

**Via API:**

```bash
curl -X POST \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/test-draft \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Contact John Smith at john@example.com",
    "policy_text": "Flag any content containing personally identifiable information.",
    "flag_threshold": 0.5,
    "block_threshold": 0.8,
    "knowledge_base_associations": [
      {
        "knowledge_base_id": "KB_UUID",
        "match_action": "inform",
        "position": 0
      }
    ]
  }'
```

### Opting Test Results into Review

By default, test evaluations (screening point `policy_test`) do not appear in the Review queue. If you want a test result to be visible in the Review tab — for example, to share it with a colleague or track it as part of a review workflow — you can **opt it into review**.

Opting a test evaluation into review changes its screening point from `policy_test` to `policy_test_review`. This makes it appear in the Review queue alongside production evaluations. The action is idempotent: if the evaluation is already in review, the operation succeeds without changes.

> **Note:** Only evaluations with screening point `policy_test` can be opted into review. Attempting to opt a production evaluation (source content, agent input, or step output) will return an error.

**Via API:**

```bash
curl -X POST \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/evaluations/{evaluation_id}/opt-into-review \
  -H "Authorization: Bearer YOUR_TOKEN"
```

### Interpreting Results

Each test result includes:

| Field           | Description                                           |
| --------------- | ----------------------------------------------------- |
| **Policy name** | Which policy was evaluated                            |
| **Score**       | Confidence from 0.0 (no match) to 1.0 (certain match) |
| **Verdict**     | Pass, flag, or block based on the policy's thresholds |
| **Explanation** | AI-generated reasoning for the score                  |

**Tips for iterating:**

- If a policy flags content that should pass, consider raising the flag threshold or adding "not violation" examples to the policy text
- If a policy misses content that should be caught, consider lowering the flag threshold or adding more violation examples
- Test with both violating and non-violating content to verify the policy doesn't over-flag

**Via API:**

```bash
# Test against all active policies
curl -X POST \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/test \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"content": "Contact John Smith at john@example.com or 555-0123"}'

# Test against a specific policy
curl -X POST \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/test \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Contact John Smith at john@example.com",
    "policy_id": "POLICY_UUID"
  }'
```

---

## Governance AI Assistant

The governance AI assistant lets you manage policies using natural language. Like all Seclai AI assistants, it follows a **propose-then-accept** pattern — the assistant generates a plan, you review it, and accept or decline. It never makes changes without your approval.

1. **Describe what you want** — e.g., "Add a PII policy with strict thresholds" or "Disable all bias policies"
2. **Review the proposed plan** — the AI generates a list of specific actions (create, update, delete, enable, disable) with full details
3. **Accept or decline** — if the plan looks right, accept it and the actions are executed automatically; if not, decline and try again

**Example prompts:**

- "Add PII and content safety policies with low flag thresholds"
- "Create a custom policy that flags medical advice"
- "Disable all policies except PII detection"
- "Lower the block threshold on my content safety policy to 0.7"
- "Set up governance policies and enable input screening"

The AI assistant has full context about your current policies, settings, and the sample policy library, so it can make informed recommendations.

**Via API:**

```bash
# Generate a plan
curl -X POST \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/ai-assistant \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"user_input": "Add a PII detection policy with strict thresholds"}'

# Accept the plan
curl -X POST \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/ai-assistant/{conversation_id}/accept \
  -H "Authorization: Bearer YOUR_TOKEN"

# Decline the plan
curl -X POST \
  https://api.seclai.com/authenticated/accounts/{account_id}/governance/ai-assistant/{conversation_id}/decline \
  -H "Authorization: Bearer YOUR_TOKEN"
```

For general best practices on getting the most from all AI assistants, see [AI Assistant Best Practices](https://seclai.com/docs/ai-assistants#best-practices).

---

## Integration Points

Governance integrates into the existing Seclai pipeline at multiple points:

| Integration                  | Where                                     | What happens                                                                                                                               |
| ---------------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **Source content screening** | During content source pulls               | New items are evaluated before being indexed. Blocked items are withheld.                                                                  |
| **Agent input screening**    | Before an agent run processes input       | User-provided input is checked. Blocked input prevents the run.                                                                            |
| **Step input screening**     | Before a step sends data externally       | Outgoing content (URLs, payloads, queries) is checked before web fetch, web search, and webhook steps. Enforce policies can halt the step. |
| **Step output screening**    | After each agent step completes           | AI-generated outputs are checked. Blocked outputs are replaced with a governance notice.                                                   |
| **Agent detail page**        | GovernancePanel on the agent detail page  | Configure per-agent governance settings and create agent-scoped policy overrides with enforcement and inheritance controls.                |
| **Source detail page**       | GovernancePanel on the source detail page | Configure per-source governance settings and create source-scoped policy overrides.                                                        |
| **Step edit modal**          | GovernancePanel in the step edit dialog   | Create step-scoped policy overrides for individual agent steps.                                                                            |
| **Dashboard All Traces**     | Dashboard → Agents tab → All Traces       | Select past runs and submit them for retroactive governance evaluation against active policies.                                            |

### Retroactive Evaluation

In addition to real-time screening, you can evaluate **past** agent runs against your current governance policies. This is useful when:

- You create a new policy and want to check whether recent runs would have been flagged
- You adjust policy thresholds and want to see how the change would affect historical runs
- You need to audit a batch of runs for compliance

**How to use it:**

1. Go to **Dashboard → Agents tab** and scroll to the **All Traces** section
2. Use the filters (status, agent, tag, evaluation, governance) to find the runs you want to evaluate
3. Select one or more runs using the checkboxes
4. Click **Run Governance Eval** — this button appears only when you have at least one active governance policy and at least one run is selected
5. Confirm the evaluation in the modal
6. Results are processed asynchronously and appear in the **Gov** column once complete

Retroactive evaluations use the same policies, thresholds, and evaluation tiers as real-time screening. Results are recorded as standard governance evaluations and appear in the [Review queue](#reviewing-evaluations).

---

## API Reference

All governance endpoints are under:

```
/authenticated/accounts/{account_id}/governance/
```

> **Authentication:** All endpoints require a valid access token via the `Authorization: Bearer` header.

### Sample Policy Endpoints

Sample policies available for adoption:

| Method | Endpoint                                        | Description                                                                      |
| ------ | ----------------------------------------------- | -------------------------------------------------------------------------------- |
| GET    | <code>/sample-policies</code>                   | List available sample policies from the library, optionally filtered by category |
| GET    | <code>{'/sample-policies/{sample_slug}'}</code> | Get a specific sample policy including its full policy text                      |

### Policy Endpoints

CRUD operations for account governance policies:

| Method | Endpoint                               | Description                                                                                                                       |
| ------ | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| GET    | <code>/policies</code>                 | List account policies (supports pagination and scope filters: <code>agent_id</code>, <code>source_connection_id</code>)           |
| GET    | <code>{'/policies/{policy_id}'}</code> | Get a specific policy by ID                                                                                                       |
| POST   | <code>/policies</code>                 | Create a new policy from a sample policy or custom text, with optional scope, thresholds, enforcement level, and inheritance mode |
| PATCH  | <code>{'/policies/{policy_id}'}</code> | Update a policy's enabled status, thresholds, enforcement level, inheritance mode, or custom text                                 |
| DELETE | <code>{'/policies/{policy_id}'}</code> | Soft-delete a governance policy                                                                                                   |
| GET    | <code>/resource-policy-counts</code>   | Get policy counts grouped by resource (agent, source, step). Useful for governance indicators on resource lists.                  |

### Knowledge Base Association Endpoints

Link knowledge bases to policies for evidence-based evaluation:

| Method | Endpoint                                               | Description                                                                                                                                                          |
| ------ | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| GET    | <code>{'/policies/{policy_id}/knowledge-bases'}</code> | List all knowledge base associations for a policy, ordered by position                                                                                               |
| PUT    | <code>{'/policies/{policy_id}/knowledge-bases'}</code> | Replace all knowledge base associations for a policy (atomic replacement)                                                                                            |
| GET    | <code>/policies/circular-knowledge-bases</code>        | Get knowledge base IDs that would create circular references for a given scope. Pass <code>agent_id</code> or <code>source_connection_id</code> as query parameters. |

### Settings Endpoints

Configure where and how governance screening is applied:

| Method | Endpoint               | Description                                                                                                     |
| ------ | ---------------------- | --------------------------------------------------------------------------------------------------------------- |
| GET    | <code>/settings</code> | List all governance settings, optionally filtered by <code>agent_id</code> or <code>source_connection_id</code> |
| PUT    | <code>/settings</code> | Create or update governance settings for a scope (account-wide, agent, source)                                  |

### Evaluation Endpoints

View and manage screening results:

| Method | Endpoint                                                      | Description                                                                                                                    |
| ------ | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| GET    | <code>/stats</code>                                           | Aggregate governance statistics (pass/flag/block counts, unresolved totals)                                                    |
| GET    | <code>/evaluations</code>                                     | List evaluations with rich filtering: verdict, screening point, date range, agent, source, policy                              |
| POST   | <code>{'/evaluations/{evaluation_id}/resolve'}</code>         | Resolve a flagged or blocked evaluation with an optional resolution note                                                       |
| POST   | <code>{'/evaluations/{evaluation_id}/opt-into-review'}</code> | Promote a <code>policy_test</code> evaluation to the review queue (changes screening point to <code>policy_test_review</code>) |

### Audit Trail Endpoints

View the change history for governance policies:

| Method | Endpoint                                       | Description                                                                                                                                                |
| ------ | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| GET    | <code>/changes</code>                          | List all governance policy changes for the account. Supports filters: <code>change_type</code> (created/updated/deleted), <code>action</code>, date range. |
| GET    | <code>{'/policies/{policy_id}/changes'}</code> | List audit trail entries for a specific policy, showing all creates, updates, and deletes.                                                                 |

### Credit Estimation Endpoints

Get estimated credit costs for governance evaluations:

| Method | Endpoint                       | Description                                                                                                      |
| ------ | ------------------------------ | ---------------------------------------------------------------------------------------------------------------- |
| GET    | <code>/credit-estimates</code> | Get estimated min/max credit ranges per evaluation tier (fast, balanced, thorough) based on current usage rates. |

### Testing Endpoints

Ad-hoc policy testing without affecting production:

| Method | Endpoint                 | Description                                                                                                                        |
| ------ | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| POST   | <code>/test</code>       | Test content against active policies. Optionally specify a <code>policy_id</code> to test against a single policy.                 |
| POST   | <code>/test-draft</code> | Test content against an unsaved draft policy with optional thresholds and knowledge base associations. The draft is not persisted. |

### AI Assistant Endpoints

Natural-language governance management using the propose-then-accept workflow:

| Method | Endpoint                                                 | Description                                                    |
| ------ | -------------------------------------------------------- | -------------------------------------------------------------- |
| POST   | <code>/ai-assistant</code>                               | Generate a governance plan from a natural language description |
| POST   | <code>{'/ai-assistant/{conversation_id}/accept'}</code>  | Accept and execute a previously proposed governance plan       |
| POST   | <code>{'/ai-assistant/{conversation_id}/decline'}</code> | Decline a proposed governance plan                             |
| GET    | <code>/ai-assistant/conversations</code>                 | List previous AI assistant conversations                       |

See the interactive API documentation at `/docs` when your API server is running for full request/response schemas.

### MCP Tools

If you use an MCP-compatible client (Claude Desktop, Claude Code, Cursor), 28 governance tools are available — covering the same operations as the REST API plus the AI assistant.

**Policy management:**

| Tool                                          | Description                                                                          |
| --------------------------------------------- | ------------------------------------------------------------------------------------ |
| <code>list_governance_policy_documents</code> | List available sample policies from the library, optionally filtered by category     |
| <code>get_governance_policy_document</code>   | Get a specific sample policy including its full policy text                          |
| <code>list_governance_policies</code>         | List governance policies assigned to the account, with optional scope filters        |
| <code>get_governance_policy</code>            | Get a specific account governance policy by ID                                       |
| <code>create_governance_policy</code>         | Create a new policy from a sample policy or custom text, optionally scoped           |
| <code>update_governance_policy</code>         | Update a policy's enabled status, thresholds, enforcement level, or inheritance mode |
| <code>delete_governance_policy</code>         | Soft-delete a governance policy                                                      |

**Knowledge base associations:**

| Tool                                      | Description                                                                                             |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| <code>list_policy_knowledge_bases</code>  | List knowledge base associations for a policy, ordered by position                                      |
| <code>set_policy_knowledge_bases</code>   | Replace all knowledge base associations for a policy (atomic replacement). Rejects circular references. |
| <code>get_circular_knowledge_bases</code> | Get knowledge base IDs that would create circular references. Optionally scope to an agent or source.   |

**Settings and statistics:**

| Tool                                         | Description                                                                     |
| -------------------------------------------- | ------------------------------------------------------------------------------- |
| <code>get_governance_settings</code>         | Get governance settings for a scope (account, agent, or source)                 |
| <code>update_governance_settings</code>      | Update governance settings (enabled, review flags, evaluation tier)             |
| <code>list_governance_settings</code>        | List all governance settings, optionally filtered by agent                      |
| <code>get_governance_stats</code>            | Get aggregate governance statistics (pass/flag/block counts, unresolved counts) |
| <code>get_governance_credit_estimates</code> | Get estimated credit costs per evaluation tier (fast, balanced, thorough)       |

**Evaluations and testing:**

| Tool                                             | Description                                                                                                |
| ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- |
| <code>list_governance_evaluations</code>         | List governance evaluations with filtering by verdict, screening point, and date range                     |
| <code>resolve_governance_evaluation</code>       | Resolve a flagged or blocked evaluation with an optional note                                              |
| <code>bulk_resolve_governance_evaluations</code> | Resolve multiple evaluations at once with an optional shared resolution note                               |
| <code>opt_evaluation_into_review</code>          | Promote a test evaluation to the review queue (changes screening point to <code>policy_test_review</code>) |
| <code>test_governance_policy</code>              | Test content against active governance policies and see evaluation results                                 |
| <code>test_draft_governance_policy</code>        | Test content against an unsaved draft policy with optional thresholds and KB associations                  |

**Audit trail and cost estimation:**

| Tool                                         | Description                                                                             |
| -------------------------------------------- | --------------------------------------------------------------------------------------- |
| <code>list_governance_audit_trail</code>     | List all governance policy changes for the account, with optional date and type filters |
| <code>list_governance_policy_changes</code>  | List the audit trail for a specific governance policy                                   |
| <code>get_governance_credit_estimates</code> | Get estimated credit costs per evaluation tier (fast, balanced, thorough)               |

**AI assistant:**

| Tool                                       | Description                                                            |
| ------------------------------------------ | ---------------------------------------------------------------------- |
| <code>generate_governance_plan</code>      | Generate a plan for policy changes from a natural language description |
| <code>accept_governance_plan</code>        | Accept and execute a previously proposed governance plan               |
| <code>decline_governance_plan</code>       | Decline a proposed governance plan                                     |
| <code>list_governance_conversations</code> | List recent governance AI assistant conversations (plans, outcomes)    |

See the [MCP Server documentation](https://seclai.com/docs/mcp#governance-tools) for setup instructions and usage examples.

---

## Exporting

Governance data can be exported for offline analysis, compliance audits, or archival. Two resource types are available:

**Governance Policies**

Export all governance policies, including policy text, thresholds, scope, enforcement level, and knowledge base associations. Supported formats: **JSON** and **JSONL**.

- **UI:** Go to **Governance → Policies** and click the **Export** button.
- **API:** `POST /authenticated/resource-exports` with `resource_type: "governance_policies"`.
- **MCP:** Use the `create_resource_export` tool with `resource_type: "governance_policies"`.

See [Export Formats → Governance Policies](https://seclai.com/docs/export-formats#governance-policies) for the full file schema.

**Governance Evaluations**

Export governance evaluation results — screening verdicts, confidence scores, AI explanations, and resolution notes. Supported formats: **JSON**, **JSONL**, and **CSV**.

- **UI:** Go to **Governance → Review** and click the **Export** button. You'll see an estimate of the record count before confirming.
- **API:** `POST /authenticated/resource-exports` with `resource_type: "governance_evals"`.
- **MCP:** Use the `create_resource_export` tool with `resource_type: "governance_evals"`.

See [Export Formats → Governance Evaluations](https://seclai.com/docs/export-formats#governance-evaluations) for the full file schema and available filter options.

> **Audit trail:** Governance exports (both policies and evaluations) are automatically recorded in the [audit trail](#audit-trail-endpoints) for compliance tracking.

---

## Permissions

| Role              | Access                                                                           |
| ----------------- | -------------------------------------------------------------------------------- |
| **Owner / Admin** | Full access: configure policies, settings, resolve evaluations, use AI assistant |
| **Member**        | Full access (same as admin for governance)                                       |
| **Viewer**        | No access to governance features                                                 |

---

## Next Steps

- [Agents](https://seclai.com/docs/agents) — Learn about the agents that governance screens
- [Content Sources](https://seclai.com/docs/content-sources) — Learn about the sources whose content governance can screen
- [MCP Server](https://seclai.com/docs/mcp) — Manage governance from AI coding tools
- [API Examples](https://seclai.com/docs/api-examples) — Common API integration patterns
- [Alerts](https://seclai.com/docs/alerts) — Set up monitoring for agent runs and source pulls