Policies¶
Policies are the rules Trust3 evaluates against every agent in your inventory. They define what "governed" means for your organization — required ownership, approved models, data scope, usage limits, and compliance framework requirements.
Policy types¶
Trust3 organizes policies into three types. Each type offers different rule fields suited to what you want to check:
| Type | What it governs | Evaluation modes |
|---|---|---|
| Compliance | Framework-specific requirements: field completeness, documentation, and approval records | Scan-time only |
| Data Access | Which data an agent may reach, ownership, models, platforms, sensitivity tags, and trust score thresholds | Scan-time or Runtime |
| Cost Governance | Token budgets, request volume, and off-topic or out-of-scope usage from agent activity | Scan-time or Runtime |
Evaluation mode¶
Data Access and Cost Governance policies run in one of two modes. Compliance is scan-time only. All policies default to scan-time unless you use runtime-only rule fields.
| Mode | When | Where |
|---|---|---|
| Scan-time | Inventory scans and scheduled evaluation | Trust3 control plane (asset registry, lineage, ingested usage) |
| Runtime | Each agent action (request or trace) | AI Assets Collector in your data plane |
The mode must match your rule fields — you cannot mix scan-time and runtime fields in one policy. Trust3 enforces this when you save. Runtime policies sync to the collector on a versioned schedule; see Control plane and data plane.
Compliance policies¶
Compliance policies verify that agents meet declared regulatory or organizational requirements — documentation, classification, and oversight procedures.
- Fires when: an agent is scanned or assessed.
- Outcome: Flag as violation, create an issue, require remediation.
- Who configures this: Compliance or GRC team.
Rules fall into two groups:
- Governance Hygiene — applies regardless of framework. Checks that the agent is properly registered and owned: owner declared, model approved, deployment status set, purpose documented.
- Regulatory Requirements — framework-specific fields that appear based on the selected framework. For EU AI Act: risk classification (Article 6), human oversight procedures (Article 14), technical documentation (Article 11), training data provenance (Article 10), registered in the EU AI database (Article 49).
Common rule fields include:
- Owner — a named owner is assigned
- Model — the model in use is documented
- Purpose — business purpose is recorded
- Deployment status — deployment state is known
Example: "All production agents must have a declared owner." A missing owner creates a compliance violation and an issue.
Data Access policies¶
Data Access policies evaluate whether an agent's access to data or destinations is appropriate, based on what the agent is, what it uses, and what it can reach.
- Outcome: Flag as violation and reduce Trust Score (scan-time). Runtime policies can also block or warn on the request via the collector.
- Who configures this: Platform, IT, or Security team.
| Field | Mode | What it checks |
|---|---|---|
| Owner, Model, Platform | Scan-time | Ownership and approved stack from inventory |
| Trust Score | Scan-time | Minimum or maximum score thresholds |
| Tags | Scan-time | Sensitivity tags on connected data in lineage (for example PII or PHI) |
| Deployment status | Scan-time | Whether the agent is running or stopped |
| Data classification | Runtime | Classification labels on data the agent is accessing on this request |
| Destination type | Runtime | Where output or data is being sent (for example Confluence or S3) |
Example (scan-time): Owner defines who is accountable and routes violations — "Production agents must have a declared owner." The policy fires on the agent's ownership state during scan.
Example (runtime): "Agents must not access PII-classified data on this request."
Cost Governance policies¶
Cost Governance policies enforce limits on an agent's consumption of tokens or API calls, and flag out-of-scope usage.
- Outcome: Flag as violation.
- Who configures this: Platform, Operations, or Finance team.
Scan-time rules use a rolling lookback window (one day by default; configurable when authoring). Runtime Cost policies support Off topic only — token and request-count fields are scan-time.
| Field | Mode | What it checks |
|---|---|---|
| Total tokens, Input tokens, Output tokens | Scan-time | Token budget caps over the lookback window |
| Request count | Scan-time | How many requests an agent made in the window |
| Off-topic count | Scan-time | Count of off-topic queries in the window |
| Off topic | Runtime | Whether the current request category is outside declared scope of the agent |
Token budgets and off-topic rules belong on Cost Governance policies, not on Compliance or Data Access policies.
Examples: "Marketing agent must not exceed 500K tokens per day" (scan-time). "Off topic usage must not exist" (runtime, per request).
Framework scope¶
Policies are organized by compliance framework. The Policies page shows policies for your active framework, selected in Settings → General → Framework.
Switch the active framework to see the corresponding policy pack. Available frameworks:
- NERC CIP / Utility
- EU AI Act
- FERC
- Internal AI Governance
Framework selection affects which Compliance catalog policies and EU AI Act–specific rule fields appear. Data Access and Cost Governance policies you create apply to the agents and conditions you specify in the policy — they are not tied to a single framework pack.
Out-of-box policy library¶
Trust3 ships with policies pre-configured for each framework. For NERC CIP / Utility, the default active policies include:
| Policy | Standard | What it checks |
|---|---|---|
| BES Cyber System Categorization | CIP-002 | Agent assets are classified by BES impact level |
| Personnel & Training | CIP-004 | Agent owners have appropriate access authorization |
| System Security Management | CIP-007 | Agents meet system security configuration requirements |
| Information Protection | CIP-011 | Agents handling BES Cyber System Information meet documentation requirements |
| Supply Chain Risk Management | CIP-013 | Third-party model and platform dependencies are documented |
Each policy in the sidebar shows a gap count — the number of assets currently failing that policy's rules.
Creating a policy¶
From the Policies page, click + New Policy. Choose one of two paths:
Import from document or URL¶
Upload a compliance PDF or paste a URL. GIA reads the document and proposes enforceable policy rules mapped to Trust3's rule schema. You review each proposed rule, adjust if needed, and activate. No manual rule-building required.
Best for: moving from a written regulatory requirement or internal AI policy document to an enforced rule. See GIA — Import policies from documents.
Create a Trust3 AI asset policy¶
Define a policy manually. Choose the policy type (Compliance, Data Access, or Cost Governance), specify which AI assets the policy applies to, and author your rules. Evaluation mode follows from the fields you choose — see Evaluation mode. All policies are subject to review before activation.
Best for: custom rules specific to your organization that don't map to an existing framework document.
Combining rules (AND / OR)¶
Policies can combine multiple rules with AND and OR logic:
- AND — every rule in the group must pass
- OR — at least one rule in the group must pass; if all branches fail, the violation lists each failing branch
You can nest groups to express more complex conditions. Trust3 limits how deeply groups can nest, and rejects duplicate or conflicting rules when you save a policy. The rule fields available in the builder depend on the policy type you selected.
Violation lifecycle¶
When a policy rule fails against an agent:
- A violation is recorded with severity, the affected agent, the rule that failed, and suggested remediation
- The agent's Trust Score drops — see Trust Score
- The violation appears in the agent's detail panel under the Policies tab
- When the underlying issue is fixed and the agent is re-evaluated, the violation closes and the Trust Score recovers
For runtime policies, the collector can also block or warn on the request at action time before a violation is recorded in Trust3.
Violations can be waived with an approver and reason recorded, for cases where the risk is accepted rather than remediated.
Who can create policies¶
| Role | Can view | Can create |
|---|---|---|
| Admin | ✓ | ✓ |
| Compliance | ✓ | ✓ |
| Legal | ✓ | ✗ |
| Developer | ✓ (read only) | ✗ |