AI Context Supply Chain / Provenance / Poisoning Defense Architecture

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_CONTEXT_SUPPLY_CHAIN_PROVENANCE_POISONING_DEFENSE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Batch 160 foundation note for AI context supply chain, provenance, poisoning defense, and financial retail product architecture. Core question: how do prompts, system instructions, RAG documents, embeddings, metadata, tool outputs, memory, user profiles, policy snippets, and workflow state become a governed context supply chain with provenance, quality, permissions, poisoning defense, and change control? Important note: this document is a learning artifact. It is not legal advice, compliance advice, audit opinion, model validation, security certification, regulatory interpretation, or production approval. Formal decisions require review by accountable business, risk, compliance, legal, privacy, security, model risk, data governance, architecture, operations, and audit roles. Access date for source anchors: 2026-06-30.

---

核心导读

很多 AI 事故会被描述为“模型幻觉”或“RAG 召回错了”。在金融零售企业里，更深层的问题通常是 context supply chain failure：过期政策仍在向量索引里、用户上传文档夹带 indirect prompt injection、CRM 自由文本被当作权威事实、工具输出没有 freshness 和 schema 校验、一次性例外被写入长期 memory、低权威外部资料压过内部批准政策。

Context 不是 prompt 附件，而是决定模型行为的供应链。它包括：

system instruction
+ developer instruction
+ prompt template
+ user request
+ workflow state
+ retrieved documents
+ retrieved metadata
+ embeddings and index configuration
+ user profile
+ case history
+ memory
+ tool observations
+ policy snippets
+ examples
+ output schema
+ runtime policy decisions

成熟系统必须把每个 context object 当作有来源、权限、质量、版本、变更、运行时轨迹和攻击面的产品资产。核心心智模型是：

source authority
-> provenance and lineage
-> permission and purpose enforcement
-> context quality SLO
-> poisoning / injection defense
-> runtime context trace
-> incident impact query
-> controlled release and rollback

本文不再从基础需求分析角色拆分出发，而是围绕 AI + 产品 + 架构的系统理解：如果产品承诺“答案可信、合规、可解释、可纠正”，架构必须能证明哪些 context shaped the behavior、为什么可以被信任、谁允许使用、是否新鲜、是否被污染、如何回滚。

---

Source Anchors

These anchors are used as architecture and product design references. They do not create a complete control catalog by themselves.

Source-use discipline:

• Treat official sources as anchors for language and evidence design, not as copy-paste requirements.
• Record source authority, access date, internal owner, applicability, affected workflow and change trigger.
• Separate formal policy, system-of-record data, vendor documentation, user-provided content, model output and analyst commentary.
• When a source changes, refresh affected context assets, indexes, eval cases, release gates and user-facing trust claims.

---

1. 问题定义

1.1 Context supply chain failure 的本质

企业 AI 质量与安全并不只取决于一个 prompt。模型真正看到的是由多种资产临时组装而成的上下文：政策文档、知识库片段、用户资料、案例状态、工具返回、历史记忆、系统指令、输出 schema、runtime policy decision。任何一个环节都可能引入错误、越权、过期、冲突或攻击。

典型失败包括：

• retired credit policy snippet remains in the vector index；
• user profile attribute is joined without permission or purpose；
• uploaded customer PDF includes indirect prompt injection and is treated as instruction；
• downstream tool observation is stale, partial, or outside its data contract；
• memory write turns a one-time exception into a persistent future instruction；
• low-authority AML article outranks the approved internal typology pack；
• branch relationship manager copilot uses unaudited CRM notes to draft advice-like language。

这些问题不能靠“prompt 写清楚一点”解决，因为错误发生在 context 的来源、权限、转换、索引、排序、组装、工具、记忆和 trace 链路中。

1.2 Context 是产品表面

Context 决定：

• AI 知道什么；
• AI 被允许知道什么；
• 哪个 source 被认为权威；
• 哪个 policy 或 workflow state 生效；
• 哪个 tool 可以被调用；
• 哪个 memory 会被带入未来；
• 哪个客户、员工或监管 claim 会被生成；
• output 是否能被解释、挑战、纠正和信任。

因此，context supply chain 的产品问题是：用户、运营人员、风险团队或审计人员看到的 AI 行为，是否能被追溯到批准的 source、正确的 permission、足够新的 index、可解释的 tool observation、受控的 memory policy 和完整的 runtime trace。

1.3 不可信上下文的独特风险

金融零售场景中，context 风险有几个特点：

---

2. 架构模型与核心原理

2.1 Context Supply Chain Logical Model

Context sources
  policy repository | knowledge base | customer profile | case system | tool API | user upload | memory store
        |
Source authority registry
  owner | trust tier | approved use | effective date | jurisdiction | permissions | quality SLO
        |
Ingestion and transformation
  parse | classify | redact | chunk | embed | index | sign | approve
        |
Context retrieval and assembly
  intent | workflow state | entitlement | source selection | rerank | conflict detection | context budget
        |
Runtime enforcement
  instruction hierarchy | untrusted label | policy engine | tool gateway | memory write policy | output schema
        |
Evidence and learning
  trace | provenance graph | eval result | incident record | correction | release update

每一步都需要 owner、contract、release identity、quality signal 和 incident path。否则 context 会成为一条不可见的行为供应链。

2.2 Controlled Transformation Chain

source registration
  -> source verification
  -> ingestion and classification
  -> chunking / structuring
  -> embedding / indexing
  -> metadata enrichment
  -> permission binding
  -> retrieval and reranking
  -> context composition
  -> prompt assembly
  -> model invocation
  -> tool observation incorporation
  -> memory write decision
  -> output citation and trace
  -> feedback and correction loop

核心问题不是“模型能否回答”，而是：

Which context claims are we making to the user, and can we prove the chain that supports them?

2.3 Control Planes

2.4 Context Trust Tiers

Key design principle:

Retrieved content can support facts, but it cannot alter instruction hierarchy, permissions, tool authority or memory write rules.

2.5 Context Asset Taxonomy

2.6 Context Object Schema

Every material context asset should have a machine-readable record.

{
  "context_object_id": "ctx-credit-policy-hardship-2026q2-v4",
  "asset_class": "policy_snippet",
  "title": "Credit Card Hardship Treatment Policy",
  "source_authority": "approved_internal_policy",
  "context_trust_tier": "T1",
  "owner": "Collections Policy Owner",
  "approved_use": ["collections_agent_assist", "branch_rm_copilot_internal"],
  "prohibited_use": ["autonomous_fee_waiver", "final_credit_decision"],
  "jurisdiction": ["US"],
  "effective_from": "2026-04-01",
  "effective_to": "2026-09-30",
  "permission_scope": {
    "roles": ["collections_agent", "collections_supervisor"],
    "purpose": ["hardship_assistance"],
    "customer_context_required": true
  },
  "quality_contract": {
    "freshness_slo_hours": 4,
    "citation_required": true,
    "conflict_policy": "higher_authority_source_wins"
  },
  "provenance_claim": {
    "derived_from": "policy-repo://collections/hardship/2026Q2",
    "ingestion_run_id": "ingest-20260630-042",
    "index_version": "collections-policy-index-2026q2-v11",
    "checksum": "sha256:7f15..."
  },
  "change_control": {
    "release_id": "ctx-release-2026.06.30",
    "approval_record": "AI-CONTEXT-CHANGE-2026-0630-017",
    "rollback_target": "ctx-credit-policy-hardship-2026q2-v3"
  }
}

2.7 Provenance Model

A provenance claim is a compact statement that tells a reviewer what can be trusted:

This context object was derived from approved source X, transformed by activity Y, approved by owner Z, released in version R, and used in trace T under permission decision P.

W3C PROV concepts map naturally to the context chain:

2.8 Lineage Graph

Policy Source v14
  -> ingest activity `ingest-20260629-009`
  -> chunk set `chunk-card-fee-v14`
  -> embedding job `embed-card-fee-ada3-20260629`
  -> index snapshot `index-card-policy-v22`
  -> retrieval run `retr-88172`
  -> prompt assembly `prompt-asm-88172`
  -> model invocation `model-call-88172`
  -> answer `out-88172`

For every material answer, the institution should know:

• which source version was used;
• which chunking and embedding configuration transformed it;
• which index and reranker selected it;
• which permission filter allowed it;
• which prompt template included it;
• which model and tool observations combined with it;
• which output cited it;
• which release gate approved that combination.

Embedding and index lineage deserve explicit governance because behavior can change without source text changing.

---

3. 关键机制

3.1 Context Ingestion Gate

Before a context source enters production retrieval or prompt assembly, it should pass an ingestion gate:

3.2 Context Release Gate

Context changes can change behavior as much as model upgrades.

3.3 Change Classification

3.4 Context Drift

Context drift occurs when the meaning, relevance, authority, or permission of context changes over time.

3.5 Permission Enforcement

Writing “do not reveal restricted data” in a prompt is not access control. Permission must be enforced before context enters retrieval, prompt assembly, tool invocation, or memory read.

user identity
  -> role and entitlement
  -> workflow purpose
  -> customer relationship
  -> data classification
  -> source permission tags
  -> retrieval-time policy enforcement
  -> context assembly

3.6 Memory Write Policy

3.7 Tool Observation Validation

Tool outputs need validation before they are included as context:

---

4. 证据与控制

4.1 Poisoning and Prompt Injection Defense

Defense principles:

4.2 Indirect Injection Example

Scenario: a customer uploads a PDF during a card dispute.

4.3 Context Quality SLO

Context quality must be managed as an operational reliability problem. If a regulated AI answer depends on source freshness, citation support, permission filtering, and conflict handling, those properties need SLOs.

Context recall measures whether the retrieval and assembly pipeline brought the necessary context into the model's working set. It is different from model answer accuracy.

context recall = required authoritative evidence retrieved / required authoritative evidence available

4.4 Quality Dashboard

4.5 Runtime Context Trace

Runtime context trace should answer:

• What context entered the model?
• Who or what allowed it?
• Which source and index versions were used?
• Which context objects were treated as authority versus evidence?
• Which tool observations were included and validated?
• Which memory records were read or written?
• Which conflicts, injection flags or stale-source warnings occurred?
• Which output claims cite which context?

OpenTelemetry-inspired span model:

Context manifest attached to runtime trace:

{
  "trace_id": "trc-card-policy-88421",
  "context_release_id": "ctx-release-2026.06.30",
  "context_manifest_hash": "sha256:49ac...",
  "objects": [
    {
      "context_object_id": "ctx-card-fee-policy-v14-sec-3.2",
      "trust_tier": "T1",
      "source_authority": "approved_internal_policy",
      "index_version": "card-policy-index-v22",
      "permission_decision": "allowed",
      "use": "citation"
    },
    {
      "context_object_id": "ctx-customer-upload-complaint-492",
      "trust_tier": "T4",
      "source_authority": "customer_claim",
      "permission_decision": "allowed_case_bound",
      "use": "evidence_only",
      "injection_flag": true
    }
  ]
}

4.6 OpenLineage-Inspired Events

4.7 Incident Response

Response workflow:

detect signal
  -> classify affected context object and severity
  -> freeze evidence and version set
  -> query impact by context object, source, index, trace and output
  -> contain: disable source, purge chunk, rollback index, block tool, suppress memory, force human review
  -> evaluate customer, operational, regulatory and model-risk impact
  -> repair source, metadata, permission, index, prompt, eval and release gate
  -> rerun regression and context quality tests
  -> update incident record, owner actions and context release

Impact queries:

---

5. 金融零售 / AI 产品场景

5.1 Policy RAG for Customer Service

Trust implication: customers trust the answer because it cites current policy and does not expose internal-only remediation logic.

5.2 AML Typology Knowledge

Trust implication: investigators get faster analysis without turning external articles or model summaries into SAR authority.

5.3 KYC Evidence Documents

Trust implication: the AI can suggest missing evidence but cannot make a final onboarding rejection without human review.

5.4 Credit Policy Snippets

Trust implication: credit staff receive consistent policy support without the AI becoming the credit decision owner.

5.5 Regulatory Reporting Instructions

Trust implication: finance and risk teams can reconstruct the evidence behind narrative drafts.

5.6 Collections Hardship Scripts

Trust implication: agents receive consistent support while vulnerable customer controls remain visible.

5.7 Branch Relationship Manager Copilot

Trust implication: the copilot helps prepare conversations without covertly crossing into advice, credit decisioning, or unauthorized data use.

5.8 Scenario-to-Control Map

---

6. 反模式

---

7. 最终心智模型

Context is the hidden operating system of enterprise AI.

No source authority -> citation laundering.
No provenance -> no audit replay.
No permission enforcement -> data leakage.
No index lineage -> no incident scoping.
No quality SLO -> stale and missing evidence.
No memory policy -> persistent corruption.
No runtime trace -> no accountability.
No release gate -> uncontrolled behavior change.

成熟问题不是“我们写了什么 prompt”，而是：

Which context objects shaped this AI behavior,
why were they trusted,
who allowed them,
how fresh were they,
what changed,
and how would we know if they were poisoned?

最终模型可以压缩成六个判断：

• Authority before relevance：先判断来源是否有权回答，再做语义召回和排序。
• Permission before prompt：访问控制必须发生在 retrieval、tool、memory 之前，不靠模型自律。
• Evidence before fluency：输出流畅不代表有足够证据；material claim 需要 source、citation、support score 和 conflict handling。
• Lineage before rollback：没有 source/chunk/index/prompt/tool/memory lineage，就无法定位影响面。
• SLO before trust：可信不是形容词，而是 freshness、authority precision、citation support、permission success、trace completeness 等指标的持续表现。
• Incident readiness before scale：任何进入生产的 context supply chain 都要能冻结版本、查询影响、回滚索引、压制 memory、修复 release gate 并重跑 regression。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。