Skip to main content
In a hybrid workforce, agents routinely process information that ranges from routine operational data to deeply sensitive personal disclosures. A scheduling agent rebooking a meeting handles low-risk data. An agent triaging pastoral care requests handles information that carries an elevated duty of care — and the governance system must know the difference. Forge’s fiduciary data classification system (STD-06) provides that distinction. It labels data by sensitivity class, designates which agents may handle classified data, and propagates access restrictions through the governance pipeline into every dispatch decision.

​
Data Classification

Every piece of data that flows through a Forge agent interaction falls into one of six classification levels. Five are elevated fiduciary classes; the sixth is the default.

FIDUCIARY DATA CLASSES (STD-06)

pastoral_counseling

Spiritual direction, pastoral conversations, confessional-grade disclosures. Highest confidentiality.

mental_health_indicator

Signals of psychological distress, wellness disclosures, behavioral health markers.

crisis_state_communication

Active crisis disclosures, safety concerns, urgent welfare communications.

donor_vulnerability

Donor financial capacity signals, giving patterns that reveal personal circumstances.

financial_transaction

Payment processing data, transaction records, financial account references.

none

No elevated classification. Standard operational data with baseline governance.

ClassDuty of CareExample
pastoral_counselingConfessional-grade confidentialityA chaplain agent processing spiritual care requests
mental_health_indicatorClinical sensitivityAn intake agent flagging behavioral health signals for routing
crisis_state_communicationImmediate welfare priorityA triage agent handling active safety disclosures
donor_vulnerabilityFinancial privacyA stewardship agent analyzing giving capacity patterns
financial_transactionTransactional integrityA processing agent handling payment authorizations
noneStandard baselineA scheduling agent coordinating team meetings
Classifications are defined in convex/trust_fabric/fiduciary/types.ts as the FIDUCIARY_DATA_CLASSES constant and the FiduciaryDataClass type. The type system enforces that only valid classes can be assigned.

​
Fiduciary Agent Designation

Not every agent may handle classified data. An agent must be explicitly fiduciary-designated before it can process any data class other than none. This designation lives on the agent definition record and consists of two fields:
FieldTypePurpose
fiduciaryFlagbooleanWhether this agent has elevated duty-of-care responsibilities
fiduciaryDataClassesstring[]Which specific data classes this agent is authorized to handle
Setting fiduciaryFlag: true without specifying fiduciaryDataClasses means the agent is fiduciary-designated but has no specific class authorizations — useful during initial onboarding before the data access scope is fully defined.

​
Designation Requirements

Fiduciary designation is a production-readiness requirement. When an agent is promoted from poc or staging to production lifecycle phase, the trust fabric validates that fiduciaryFlag is explicitly set (not undefined). This prevents agents from reaching production without a conscious decision about their data handling responsibilities. The promotion gate also requires:
  • riskTier — the agent’s risk classification (T1—T4)
  • owner — the owning team responsible for the agent
  • autonomyRung — the agent’s autonomy level (assistive, retrieval, supervised, bounded)
An agent with fiduciaryFlag: undefined cannot be promoted to production. The field must be explicitly set to true or false — the system distinguishes between “not yet classified” and “classified as non-fiduciary.”

​
Access Control Model

The fiduciary classification system enforces access control at two levels: agent designation and governance traceability.

​
Agent-Level Enforcement

An agent’s fiduciaryDataClasses array acts as an allowlist. When a workflow step involves classified data, only agents whose fiduciaryDataClasses includes the relevant class should be assigned to that step. This is enforced through role-based assignment — agents are assigned to roles that match their classification clearance.

​
Governance Traceability

Every governance decision records the agent’s fiduciary status in the traceability record. The 8-field traceability record (STD-03.3) includes: 
governancePacket: {
  agentId: string;
  nhiId?: string;
  autonomyRung: string;
  owningTeam: string;
  riskTier: string;
  fiduciaryFlag: boolean;  // Recorded on every dispatch
}
This means every action by a fiduciary-designated agent carries an immutable audit trail that records the agent’s fiduciary status at the time of dispatch. The trustFabricEvents table stores these records, and the fiduciaryFlag field is independently recorded on each trace event for fast querying.
To find all dispatch events involving fiduciary agents, query trustFabricEvents where fiduciaryFlag === true. The field is stored at the top level of the event record for efficient indexing.

​
Scope Constraints

The Trust Fabric’s scope constraint system (ScopeConstraintsV1) provides a complementary layer of data access control that works alongside fiduciary classification. While fiduciary classes define what kind of data an agent handles, scope constraints define which data domains the agent can read and write.

​
ScopeConstraintsV1 and Data Access

Scope constraints are derived from the agent’s assigned worker role and propagated into every GovernanceDecision:
FieldPurposeExample
dataAccessReadable data domains["crm", "billing", "pastoral"]
writeAccessWritable data domains["crm.notes"]
environmentsEligible execution environments["staging", "production"]
toolAllowListPermitted tools["search", "summarize"]
toolDenyListProhibited tools["delete", "export_bulk"]
When a role defines dataAccess or writeAccess, the governance engine resolves these from the role snapshot and attaches them to the decision’s scopeConstraints field. Downstream execution surfaces (Bridge, adapters) receive these constraints as part of the dispatch payload.

​
How Classification and Scope Interact

Fiduciary classification and scope constraints are complementary:
Fiduciary Classification

Answers: “Is this agent trusted with sensitive data classes?” Controls agent eligibility. Recorded in audit trail.

Scope Constraints

Answers: “Which data domains can this agent access?” Controls runtime boundaries. Conveyed to execution surfaces.

A fiduciary agent handling pastoral_counseling data would typically have a role with dataAccess: ["pastoral"] and narrow writeAccess — the classification designates trust, while the scope constraints bound the actual data domains the agent can touch during execution.
Scope constraints are currently conveyed to downstream execution surfaces but not yet fully enforced at the adapter level. The presence of these fields in the dispatch payload is the first step toward runtime enforcement. See the ScopeConstraintsV1 type definition for the full honesty note.

​
Context Trust and Fiduciary Agents

Fiduciary-designated agents are subject to the Context Trust gate (Gate 8 in the dispatch pipeline) which validates that the dispatch context provenance meets the role’s trust requirements. For fiduciary agents, this gate is particularly important because it ensures:
  1. Source class acceptance — the context originates from a trusted source (e.g., internal_verified)
  2. Freshness requirements — the context is not stale, preventing decisions on outdated information
  3. Environment eligibility — the agent is dispatched to an appropriate environment
These checks prevent a fiduciary agent from being dispatched with unverified or stale context — a critical safeguard when the agent handles data that carries an elevated duty of care.

​
Next Steps