Trust model

A single statement of the enforcement model shared across this repository's extensions and data-labelling schemes, so individual specs don't re-litigate it.

Annotations are claims, not guarantees

An annotation on a tool result or definition is a claim made by whoever produced it. Nothing in these extensions assumes the producer is honest or competent. The value of an annotation comes from two things:

1. Verifiability. Where a claim needs to be trusted, the evidenceRef pointer (see trust-annotations) lets a consumer resolve and check the evidence behind it — re-hash the referenced record, verify a signature, check an inclusion proof — rather than taking the claim on faith.
2. Accountability. Enforcement lives with the parties that can impose consequences: registries and marketplaces that admit servers, hosts/clients that gate actions, and operators that set policy. The annotation gives those parties a machine-readable surface to act on.

This mirrors the framing repeated throughout the SEP-1913 discussion: trust comes from the ecosystem verifying annotations, not from developer good faith. A server that lies in its annotations is a server a registry can refuse to list and a host can refuse to trust — the same accountability model as any other declared capability.

Defense in depth, not a single gate

As framed in the IG's inaugural meeting, these annotations are defense in depth: they reduce the likelihood of unintended actions (unnecessary destructive operations, data crossing a boundary it shouldn't), they don't claim to be a complete security boundary. A host SHOULD combine them with its own checks (its own injection detection, its own policy engine) rather than treating any single annotation as authoritative.

Human-in-the-loop on the risky edges

A recurring pattern from the IG research (Joanna's "phases" work, and the SEP-1913 thread): rather than blanket-blocking flows a policy engine is unsure about, flag the specific call for user confirmation. This preserves utility while keeping a human on the genuinely risky edges, and is the recommended default for requiresReview (action-metadata) and for IFC policy violations (the ifc-fides scheme).

Cross-domain is the hard case

Policy engines work well inside a single user/organization universe and struggle across universes (cross-org, cross-domain flows). These extensions provide the signal (where data came from, how sensitive it is, what a tool does with it); they do not solve cross-domain enforcement on their own. That remains an open question and a likely area for future work (e.g. asymmetric crypto for domain integrity verification).