Research summary
Highly sensitive project context cannot be protected by a single redaction pass at the edge. This note presents a control-plane model for classifying, minimizing, routing, retaining, using, and auditing AI context across its full lifecycle. Our objective is not to promise that any model understands secrets safely; it is to ensure that the system never needs to send, store, or expose more context than an authorized task requires.
1. Scope and design position
The system handles code, documents, credentials, customer records, tool output, retrieval results, and generated text that may carry different sensitivity levels. We use explicit classification and purpose binding rather than relying on a vague “private mode.” The default question is not whether a useful file can be included, but whether its minimum necessary representation is authorized for this task, route, model, tool, and retention period.
2. Context control plane
The control plane sits before model routing and alongside tool execution. It combines asset classification, purpose and tenant binding, minimization, approved-route selection, retention policy, and minimal audit evidence. The data plane then receives only the selected, authorized context.
敏感上下文策略探索器
选择数据级别与目标路径,查看公开策略语义;不展示生产地址、密钥、阈值或供应商配置。
The public model deliberately excludes secret matchers, policy thresholds, encryption topology, and detection rules. Publishing a control boundary should improve reviewability, not create an instruction manual for bypassing it.
3. Receive, construct, execute, return, end
At receipt, context receives a classification and source scope. Construction assembles a task-specific, minimized view rather than passing a complete project snapshot. Execution chooses a permitted local or remote route and applies model, tool, and budget policy. Return processing removes or blocks disallowed output and gives the client a typed result. End-of-run processing expires transient material, records only permitted evidence, and applies any requested deletion or retention schedule.
Each transition can fail closed. A classification gap, route mismatch, revoked authorization, or unavailable local capability should yield a clear constrained outcome—not a silent fallback to a broader audience.
4. Cache, logs, tools, and MCP
Caching is treated as reuse of sensitive material, not merely as performance infrastructure. High-sensitivity bodies are excluded from shared reuse by default; policy, authorization, source version, and purpose changes invalidate any permitted derivative. Logs avoid bodies by default and preserve correlation, policy version, route class, and outcome only to the degree permitted. Tools and MCP servers receive scoped parameters and credentials, never an implicit grant based on model-generated text.
5. Classification, modes, and verification
We evaluate the architecture with a classification matrix, route/mode controls, and verification metrics such as body-bearing-log detection, sensitive reuse rejection, scope denial, and output-period interruption. A metric is meaningful only alongside a policy version and workload context.
| 级别 | 可进入形式 | 默认去向 | 缓存与日志 | 人工控制 |
|---|---|---|---|---|
| 公开/一般内部 | 任务相关原始或派生内容 | 批准常规路径 | 按产品策略,正文/诊断分离 | 常规授权 |
| 机密 | 最小字段、摘要、受控检索 | 范围受限模型与工具 | 避免完整复用;脱敏诊断 | 项目级授权 |
| 高度敏感 | 去标识化/裁剪派生内容;必要时引用 | 默认隔离路径 | 不缓存正文、不落调试日志、不在报错回显 | 所有者与安全审批例外 |
6. Assurance boundary and conclusion
This architecture reduces unnecessary exposure and creates evidence for review; it does not make an unsafe source safe, guarantee that every classifier is perfect, or remove the need for application-level authorization. The operational promise is narrower and more useful: sensitive context is deliberately minimized, route-bound, lifetime-bound, tool-scoped, and auditable, with safe refusal when the system cannot establish those conditions.
