Risk Governance and Safety
FactVerse AI Agent workflows can read operational context, run analysis, prepare drafts, and support controlled actions. Risk governance keeps each step aligned with tenant permissions, tool access, data evidence, review ownership, and audit records.
Use this page when deciding which outputs can be accepted directly, which outputs require confirmation, and which outputs need named human review before they affect an operating record or connected system.
Governance flow
Risk levels
The risk level should match the output's operating impact.
| Risk level | Typical output | Expected handling |
|---|---|---|
| Informational | Read-only answer, source lookup, status summary, or document retrieval. | Return evidence, timestamps, and open gaps. |
| Audited analysis | Health score, anomaly explanation, simulation comparison, or engineering summary. | Record input boundary, assumptions, evidence, and reviewer notes. |
| Confirmed draft | Draft work request, inspection note, scenario package, or recommended follow-up. | Ask the user to confirm before creating or handing off the draft. |
| Human-approved action | Work-order dispatch, task assignment, controlled update, or operating change proposal. | Route to a named reviewer or approver before the action is accepted. |
| Policy-controlled operation | High-impact action governed by site policy, safety procedure, or change-control rule. | Follow the customer's predefined operating policy, approval role, and audit requirement. |
This model should be applied per output. A workflow can produce a read-only summary, then later move into a draft or approval path when the user asks for an operating action.
Agent role and risk boundary
Each configured agent should have a role that matches the highest-impact output it is expected to produce.
| Agent role | Normal responsibility | Governance focus |
|---|---|---|
| Capability agent | Runs a calculation, model, data preparation step, or specialized analysis. | Input quality, assumptions, and traceable output. |
| Assistant agent | Helps users investigate context, prepare recommendations, or create reversible drafts. | Evidence quality, user confirmation, and draft review. |
| Worker agent | Carries an approved operating task through a controlled workflow. | Approval path, action record, and rollback or follow-up handling. |
| Orchestrator agent | Coordinates multiple agents, tools, or operating steps. | Clear ownership for each sub-step, review gate, and final decision. |
Use Agent Lifecycle and Configuration to define the agent purpose, owner, entry route, tool boundary, and review boundary.
Review gates
Review gates should be visible in the workflow design and run record.
| Gate | Use when | What to record |
|---|---|---|
| Evidence only | The result is read-only and has clear source references. | Source records, timestamps, and unresolved gaps. |
| Audit | The result is analysis or compute output that may guide a decision. | Inputs, assumptions, output, reviewer notes, and trace ID. |
| Confirmation | The agent prepares a reversible draft or follow-up record. | User confirmation, draft content, and scope used. |
| Human approval | The output affects a task, work order, operating record, or connected system. | Approver, decision, reason, final record, and follow-up owner. |
| Policy-controlled | The output touches a high-impact operation or site-specific controlled process. | Policy owner, operating rule, approval evidence, and audit record. |
Use Workflow Run Record to capture the final evidence trail.
Guardrails
Guardrails reduce risk before a result or action reaches a reviewer.
| Guardrail area | What to check |
|---|---|
| Tenant isolation | The request, records, tools, and output stay within the intended tenant and site boundary. |
| Tool input validation | Required fields, value ranges, and controlled options are present before a tool runs. |
| Evidence grounding | Answers that summarize operations cite source records, documents, scenes, or tool results. |
| Sensitive data handling | Personal, confidential, or regulated data is minimized and handled according to policy. |
| External access | Tools that call outside systems are reviewed for purpose, destination, and allowed data. |
| Emergency disablement | Operators have a known way to pause an agent or workflow when risk conditions change. |
Guardrail findings should be visible to the operating owner. A blocked output should leave enough context for the owner to fix data, scope, policy, or workflow design.
Audit trail
The audit trail should let another reviewer reconstruct the workflow run.
| Audit item | Expected content |
|---|---|
| Request context | User, tenant, boundary, workflow type, and time window. |
| Access context | Endpoint, scope set, visible tools, and client identity. |
| Evidence | Source systems, records, timestamps, scene versions, documents, and tool outputs. |
| Risk decision | Output type, review gate, reviewer, and approval status. |
| Result | Accepted answer, draft, approved action, rejected output, or blocked reason. |
| Feedback | Field result, correction, accepted change, or next review date. |
The audit trail should connect with the customer's operating records, such as work orders, inspection tasks, scenario packages, or validation notes.
Evaluation and drift review
Before expanding an agent workflow, review whether it behaves consistently on representative cases.
| Review area | Customer-facing question |
|---|---|
| Baseline cases | Does the agent handle normal, weak-data, exception, and blocked-action cases? |
| Critical cases | Are safety, compliance, tenant-boundary, and high-impact cases reviewed separately? |
| Accepted corrections | Are reviewer corrections fed back into the workflow design and runbook? |
| Behavior change | Do output quality, data coverage, approval rates, or field feedback show a change in behavior? |
| Scope adjustment | Should the agent keep the same tool boundary, move to a lower-impact mode, or return to pilot review? |
Use this review to decide whether an agent remains ready for regular use, needs a narrower scope, or should be retired from Agent Hub.
Design checklist
| Check | Ready when |
|---|---|
| Risk level | Each output type has an expected risk level and review gate. |
| Owner | The workflow has an operating owner and reviewer. |
| Evidence | Source references, timestamps, assumptions, and missing data are visible. |
| Access | Endpoint, scopes, and runtime-visible tools match the workflow boundary. |
| Guardrails | Tenant, input, grounding, sensitive-data, and external-access checks are defined. |
| Approval | Drafts, actions, and policy-controlled operations have clear approval paths. |
| Audit | The run record captures decisions, blocked results, approvals, and feedback. |
Related pages
| Need | Use |
|---|---|
| Understand the platform model | Agent Platform Overview |
| Configure agent ownership and lifecycle | Agent Lifecycle and Configuration |
| Plan endpoint and scope boundaries | Access and Scope Planning |
| Capture evidence and approvals | Workflow Run Record |
| Diagnose access or audit failures | MCP Errors and Audit |