# Annex T #### T.1 Trigger model for AI (deployment, tool enablement, prompt class, domain shift) T.1.1 **Purpose.** This Annex defines the **AI Obligation Attachment Profile**—a Nexus Standards Signed Profile Package (SPP) and associated Trigger Definitions (TRG) that make AI/agentic risk controls **machine-attachable, time-bound, testable, and correctionable**. The profile exists to prevent “silent capability drift” (new tools, new data access, new behaviors) from escaping governance and evidence. T.1.2 **Scope.** Applies to: * model deployment and redeployment (new weights, new base model, new fine-tune), * inference endpoint configuration changes (routing, safety filters, context windows), * tool enablement/disablement for agents (browsing, code execution, payments routing, privileged actions), * changes to prompt/system instructions and retrieval corpora (RAG), * domain shifts (new use domain, new population, new regulated boundary), * changes to safety policies, guardrails, and override pathways. T.1.3 **Non-execution boundary.** This profile governs **assurance and operability** only. It MUST NOT perform regulated execution (e.g., underwriting, custody, market operation, claims execution, settlement). Where AI is used in or near regulated execution stacks, the profile issues **determinations and dockets** for the regulated operator to act on externally. T.1.4 **Trigger categories (mandatory).** The profile MUST define TRGs for the following obligation attachment categories: T.1.4.1 **Deployment trigger (AI-DEPLOY).** Obligations attach when a model or endpoint is created, replaced, promoted, or scaled into production. T.1.4.2 **Tool enablement trigger (AI-TOOLS).** Obligations attach when an agent gains or modifies tool permissions (e.g., network access, file access, database access, privileged APIs, operational controls). T.1.4.3 **Prompt class trigger (AI-PROMPT-CLASS).** Obligations attach when prompt/system instruction class changes, or when usage is reclassified into a higher-risk prompt class. T.1.4.4 **Domain shift trigger (AI-DOMAIN).** Obligations attach when use expands into a new domain, geography, language population, user segment, critical function, or regulated boundary. T.1.4.5 **Data/RAG trigger (AI-RAG).** Obligations attach when retrieval corpora, embedding models, indexing pipelines, or data access scopes change. T.1.4.6 **Safety posture trigger (AI-SAFETY).** Obligations attach when guardrails, refusal policies, policy runtimes, moderation layers, or kill-switch configurations are modified. T.1.4.7 **Incident/abuse trigger (AI-INCIDENT).** Obligations attach upon detection of specified adverse events (prompt injection success, tool misuse attempt, data leakage suspicion, policy bypass, high-severity hallucination in critical workflow, abuse reports). T.1.5 **Trigger predicate binding (mandatory).** Each AI trigger MUST bind predicates to **Ontology Fabric events** (NOF) and to **evidence candidates**. At minimum: * an ontology event type (deployment\_event, tool\_permission\_change, domain\_classification\_change, retrieval\_scope\_change, safety\_policy\_change, incident\_event), * a subject entity set (model\_id, endpoint\_id, agent\_id, tool\_id, dataset\_id, service\_id), * a jurisdiction and handling election (default handling markers), * uncertainty rules (what counts as sufficient evidence for attachment under degraded conditions). T.1.6 **AI risk classes (mandatory).** The profile MUST define risk classes that drive which controls become MUST/SHOULD/MAY and which attestations are required. At minimum: * **AI-R0**: low-impact, non-sensitive, no privileged tools, no critical decisions. * **AI-R1**: moderate impact, user-facing, limited tools, non-critical workflows. * **AI-R2**: high-impact decision support (operational, financial, safety-adjacent) with constrained tools. * **AI-R3**: critical workflows, safety/security/financial stability relevance, privileged tools or sensitive data access. * **AI-R4**: sovereign/supervisory reliance contexts, cross-border sensitivity, or systemic risk posture. T.1.7 **Obligation Attachment Record (OAR) requirements (mandatory).** When any AI TRG fires, NXOSI MUST generate an OAR that includes: * subject scope (model/endpoint/agent/tool/data scope), * risk class and reliance tier, * clocks (verification/remediation/retest/dispute), * required control families and enforcement points, * handling/disclosure defaults and evidence pack access policy pointers, * emergency-mode eligibility and constraints (if any). T.1.8 **Clocks for AI attachment (mandatory baseline).** Unless overridden by jurisdiction overlay, the profile MUST define default clocks: * **Verification clock:** time-to-produce baseline receipts after attachment (short for tool enablement). * **Remediation clock:** time-to-fix high-severity failures (short for data leakage / tool misuse). * **Retest clock:** recurring re-verification cadence, tightened under drift. * **Dispute clock:** challenge window for determinations affecting reliance. * **Emergency mode clock:** maximum duration for break-glass tool use or override. *** #### T.2 Required controls (tool allowlists, logging, human override, kill switch evidence) T.2.1 **Purpose.** This section defines the minimum control families for AI/agentic systems. Controls MUST be expressed as atomic, testable controls with clear inputs/outputs and MUST produce CRRs and PRs. T.2.2 **Control family A — Tool allowlists and scoped permissions (mandatory for AI-R2+).** T.2.2.1 **Allowlist definition.** Every agent MUST have an explicit tool allowlist bound to: * tool identifiers, * allowed actions/verbs, * allowed data scopes, * rate and spend limits (where applicable), * prohibited tool combinations (dangerous compositions). T.2.2.2 **Least privilege.** Tool permissions MUST be minimized and time-bounded. Default MUST be deny. Elevations MUST be governed and logged as CPAR. T.2.2.3 **Policy-bound tool invocation.** Tool calls MUST be mediated by policy such that: * each call is authorized against current policy version, * call context is time-bound and scope-bound, * denial and rationale are logged without leaking sensitive content. T.2.2.4 **Sensitive tool classes.** The profile MUST treat the following as “sensitive tools” requiring additional gates: filesystem access, credential vault access, database write, privileged admin APIs, external network access, messaging/broadcast, any action that can change production state. T.2.3 **Control family B — Prompt/output logging classes (mandatory for AI-R1+).** T.2.3.1 **Logging classes.** Prompts and outputs MUST be logged according to handling classes and lawful basis: * Public-safe summaries where permitted, * Controlled logs for operational/audit reliance, * Restricted logs for sensitive domains. T.2.3.2 **Minimal disclosure logging.** Where full prompt/output logging is prohibited, the system MUST still log: * hashed or redacted representations, * policy version and guardrail decisions, * tool invocation summaries and outcomes, * trace context sufficient for lineage. T.2.3.3 **Tamper-evidence.** Logging MUST be integrity protected and time bound for audit-grade tiers. T.2.4 **Control family C — Human override and dual control (mandatory for AI-R2+).** T.2.4.1 **Human-in-the-loop gating.** For defined high-impact actions, an agent MUST require explicit human approval captured as CPAR, including authority basis and handling election. T.2.4.2 **Separation of duties.** Approval roles MUST be separated from model maintainers where feasible and MUST follow SoD constraints defined in NXCP conformance. T.2.4.3 **Override logging.** Any override MUST create CPAR entries and MUST start a post-incident review workflow when invoked under break-glass. T.2.5 **Control family D — Kill switch evidence and emergency freeze (mandatory for AI-R2+; strict for AI-R3+).** T.2.5.1 **Kill switch capability.** A kill switch MUST exist to: * disable tool use, * disable or degrade model to safe mode, * route workflows to manual, * halt deployments or roll back. T.2.5.2 **Governance constraints.** Kill switch invocation MUST be: * restricted to authorized roles, * time-bounded, * logged as CPAR, * reviewed post-incident with correction workflow if misuse or failure occurs. T.2.5.3 **Proof of readiness.** The system MUST be able to produce receipts showing: * kill switch exists, * it is tested on cadence, * it works under degraded mode. T.2.6 **Control family E — Data access boundaries and RAG safety (mandatory for AI-R2+).** T.2.6.1 Retrieval scopes MUST be explicitly declared and governed (dataset scope, jurisdiction, retention rules). T.2.6.2 Retrieval MUST enforce least privilege and handling constraints (no cross-class leakage). T.2.6.3 Data lineage for retrieval corpora MUST be attested at required tiers (see T.3). T.2.7 **Control family F — Policy bypass and injection resistance (mandatory for AI-R2+).** T.2.7.1 Systems MUST detect and respond to prompt injection indicators where measurable. T.2.7.2 Tool invocation MUST require policy-mediated authorization independent of prompt content. T.2.7.3 Systems MUST log bypass attempts and generate drift/incident events that can trigger OAR clocks. T.2.8 **Control family G — Output safety constraints for high-impact use (mandatory for AI-R2+).** T.2.8.1 High-impact domains MUST enforce: * confidence declarations or refusal behavior, * provenance labeling where the system relies on retrieval or external tools, * forbidden outputs lists for regulated boundaries. T.2.8.2 The profile MUST define minimum fail-safe behavior on uncertainty spikes or safety layer degradation. *** #### T.3 Model/toolchain provenance and endpoint attestation requirements T.3.1 **Purpose.** AI governance fails without binding claims to the real environment that produced them. This section defines provenance and attestation obligations for models, pipelines, and endpoints. T.3.2 **Provenance objects (mandatory).** The system MUST maintain provenance artefacts for: * model identity (base model, fine-tune lineage, weights hash, training data declarations where permitted), * inference endpoint build and deployment pipeline (who built, what dependencies, what configs), * toolchain configuration (tools enabled, policy versions, safety layers), * retrieval corpora identity and scope (dataset IDs, versions, handling constraints). T.3.3 **Endpoint attestation (mandatory for AI-R2+).** Inference endpoints MUST be attested at deployment and periodically thereafter, binding: * the measured environment (platform, container image, runtime policy engine), * the model version hash and configuration, * the tool mediation layer identity, * safety and logging posture (enabled and active). T.3.4 **Attestation freshness windows (mandatory).** The profile MUST define freshness windows by risk class: * tighter for AI-R3/AI-R4, * may be looser for AI-R0/AI-R1,\ but MUST always be explicit and testable. T.3.5 **Attestation failure behavior (mandatory).** If required attestation is missing, stale, or fails appraisal: * the system MUST deny, degrade, or quarantine the relevant function per profile rules, * MUST emit normalized security events, * MUST open or update a docket and start remediation clocks. T.3.6 **Provenance + attestation binding (mandatory).** CRRs and PRs for AI controls MUST carry: * endpoint attestation references (or appraisal result), * model version hash binding, * tool allowlist hash binding, * policy/guardrail version binding, * retrieval corpus scope binding where relevant. T.3.7 **Constrained/offline environments.** Where endpoints run in constrained or sovereign/air-gapped environments: * delayed attestation MAY be used only if permitted by overlay and risk class, * cached endorsements MAY be used with explicit reliance limits, * degraded-mode receipts MUST declare constraints and required follow-up clocks. *** #### T.4 Drift detection and retest clocks (behavior/data/policy drift) T.4.1 **Purpose.** AI systems drift without code changes. NXOSI must treat drift as a first-class trigger for obligation tightening, retesting, and correction. T.4.2 **Drift categories (mandatory).** T.4.2.1 **Behavior drift.** Observable change in outputs, refusal rates, safety policy adherence, tool call patterns, or error distributions beyond thresholds. T.4.2.2 **Data drift.** Change in input distributions, domain content, retrieval corpus composition, or embedding/index characteristics. T.4.2.3 **Policy drift.** Change in prompt/system instruction class, tool policy, guardrail policies, or enforcement runtime posture. T.4.2.4 **Endpoint drift.** Change in runtime environment, dependencies, or configuration without approved change records. T.4.3 **Drift signals (mandatory minimum).** * tool invocation frequency and denied-call rate, * high-severity safety events frequency, * prompt injection indicators frequency, * model version/config changes, * retrieval corpus changes, * attestation freshness failures, * override usage frequency and duration. T.4.4 **Retest clock binding (mandatory).** Drift threshold crossing MUST: * trigger OAR updates or new OAR issuance, * start a retest clock, * open/update a docket with required checks, * optionally tighten tool allowlists or require step-up human approval until retest passes. T.4.5 **Drift under degraded operation.** When offline or partially observed: * drift detection MUST degrade gracefully and declare uncertainty, * the system MUST apply conservative obligation tightening when risk class requires it, * queued drift events MUST sync when connectivity restores, preserving time bounds. T.4.6 **Correctionability under drift.** If drift reveals that a control mapping or threshold was defective: * a correction object MUST be issued for the profile/overlay, * supersession MUST include migration notes, * reliance stability rules MUST be applied (status objects, dispute windows). *** #### T.5 Red-team and adversarial test vectors (prompt injection, tool misuse) T.5.1 **Purpose.** Conformance for AI profiles MUST include adversarial testing. This section defines mandatory vector classes and expected outcomes. T.5.2 **Vector class A — Prompt injection and instruction hijack (mandatory for AI-R2+).** * attempt to override system policies, * attempt to extract restricted data, * attempt to coerce tool invocation against policy, * attempt to bypass logging or safety constraints. **Expected outcomes:** refusal or safe degradation, policy-mediated tool denial, logged attempt, normalized incident event, and where thresholds are met, docket updates and retest clock start. T.5.3 **Vector class B — Tool misuse and privilege escalation (mandatory for AI-R2+).** * request privileged tool actions outside allowlist, * chain tool calls to approximate prohibited outcomes, * attempt indirect tool activation through retrieval content. **Expected outcomes:** deny with logged rationale, CPAR required for any elevation, and strict failure behavior for AI-R3+. T.5.4 **Vector class C — Data exfiltration and leakage (mandatory for AI-R2+).** * attempt to retrieve secrets from corpora, * attempt to reconstruct restricted content, * attempt to induce the system to reveal private identifiers. **Expected outcomes:** redaction/refusal, leakage detection signals, restricted handling enforcement, docket opened for remediation if leakage suspected. T.5.5 **Vector class D — Drift and regression tests (mandatory).** * simulate model version update, * simulate retrieval corpus update, * simulate policy update, * simulate tool enablement change. **Expected outcomes:** OAR issuance, verification clocks, correct binding of receipts to new versions, and status/supersession objects where changes affect reliance. T.5.6 **Vector class E — Override misuse (mandatory for AI-R3+).** * attempt unauthorized override, * attempt repeated break-glass invocation beyond limits. **Expected outcomes:** deny, incident event, sanctions ladder hooks, mandatory post-incident workflow on any successful invocation. *** #### T.6 AI profile conformance suite and acceptance gates T.6.1 **Purpose.** This section defines the conformance suite requirements and acceptance gates for claiming conformance to the AI Obligation Attachment Profile. T.6.2 **Conformance targets (mandatory).** * TRG predicate evaluation and correct OAR issuance, * SPP composition correctness (base + AI profile + overlays), * enforcement point behavior for AI controls (runtime + tool mediation; optionally CI/CD and deploy gates), * CRR and PR schema compliance and linkage integrity, * status semantics for changes and incidents, * drift detection signal emission and retest clock behavior, * handling compliance (no leakage). T.6.3 **Minimum required tests (mandatory).** T.6.3.1 **Gold vectors.** Demonstrate correct behavior under normal, non-adversarial deployment/tool enablement changes. T.6.3.2 **Negative tests.** Missing fields, invalid signatures, stale attestations, missing linkage IDs, unauthorized tool calls. T.6.3.3 **Adversarial tests.** Prompt injection, tool misuse, data leakage attempts, override misuse, poisoning via retrieval content. T.6.3.4 **Degraded-mode tests.** Offline verification bundles, delayed attestation, store-and-forward logging, and declared reliance limits. T.6.4 **Acceptance gates (DoD-style) (mandatory).**\ A deployment MAY claim conformance to this Annex only if it can produce: * signed conformance report covering the AI profile test suite, * receipts showing tool allowlists enforced and logged, * receipts showing human approval gates and CPAR logging where required, * receipts showing kill switch readiness and periodic test evidence, * demonstrable drift triggers that open/update dockets and start retest clocks, * verified endpoint attestation for required risk classes, * handling-aware logs and proof that restricted content is not exported. T.6.5 **Permitted claims and prohibited claims.** * Permitted: “Conforms to NXOSI AI Obligation Attachment Profile (Annex T) at declared risk classes and enforcement points.” * Prohibited: “Certified safe AI,” “regulator-approved,” or any implied endorsement beyond the declared reliance tier. T.6.6 **Interoperability expectation.** A conformant implementation MUST support cross-vendor verification of: * PRs and STO resolution for AI obligations, * OAR issuance semantics and clock bindings, * tool policy evidence as portable reliance objects,\ without requiring disclosure of restricted evidence content. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.therisk.global/organization/standardization/nexus-osi/annexes/annex-t.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.