阅读时间 : 14 minutes

几个月来,我一直堆叠代理治理规则。一些文件 EAGER,LAZY 检查清单,六步骤会话结束协议。 然而,仍然有一个问题悬而未决:LLM 如何知道它 对文件有什么权利?

答案不在提示中。它在文件系统中。

这是使响应可用的架构规范 — la LLM治理矩阵.

问题:提示工程是一座沙堡

当你给LLM一个文件时,你就是在给它一切。内容,是的 — 但也缺乏防护措施。LLM 不知道此文件是否包含 一个秘密,一种推测性的意见,或者闭源代码。它将对其进行索引。 总结、引用、将其与其他数据混合 — 以及可能 将其发布到公开的嵌入或用户响应中。

经典的游行,就是提示 :

"Tu es un assistant sécurisé. Ne divulgue jamais d'informations confidentielles.
Si tu détectes un secret, ignore-le. Si tu détectes une opinion, ne la répète pas."

这个提示有三个问题:

  1. *它依赖于LLM的善意。*一个足够大的模型用于

解决复杂的错误足以绕过一条指令 埋没在200k tokens上下文中的安全

  1. 它是语境性的,不是结构性的。 改变提示,改变语言模型,

更改会话 — 规则就消失了。

  1. 它无法扩展。 每一种新文件类型,每一个新层级

保密性要求新条款。您的提示变成一个 没有人会完整阅读的法规文本。

系统的安全永远不应依赖于一条指令,我们 可能忘记、绕过或不加载。它必须依赖于一个 除非明确愿意,否则无法跨越的障碍。

我的回答:4×4矩阵

我实现的解决方案在我的工作区是一个 矩阵 区域 × LLM的访问权限。它不要求LLM保持谨慎。它使 结构上不可能的鲁莽。

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 220

title 治理矩阵 LLM — 区域 × 访问权限
package "Workspace" {

  rectangle "RACINE\n(圈 0)\n━━━━━━\n脑力倾泻\n自由思考\n[INTERDIT LLM]" as Z0 #FFB3B3
  rectangle "configuration/\n(圈 1)\n━━━━━━\n机密,令牌\n私有基础设施\n[INTERDIT LLM]" as Z1 #FFB3B3
  rectangle "office/\n(圈 2)\n━━━━━━\n编辑数据\n文章,框架\n[FILTRÉ Vision]" as Z2 #FFF3B3
  rectangle "foundry/private/\n(圈 3)\n━━━━━━\n闭源代码\n[DATASET PRIVÉ]" as Z3 #B3D9FF
  rectangle "foundry/public/\n(圈 3)\n━━━━━━\n开源代码\nApache 2.0\n[ACCÈS LIBRE]" as Z4 #B3FFB3

}

Z0 -[hidden]-> Z1
Z1 -[hidden]-> Z2
Z2 -[hidden]-> Z3
Z3 -[hidden]-> Z4

@enduml

五个区域(空间维度 — 通用数据保护条例)

工作区的每个区域都有一个GDPR级别,它决定*哪里*文件可以 被路由:

区域 GDPR 级别 内容 公共 RAG 访问权

根

0 — 亲密

脑转储,LLM 对话

禁止— 从未被索引

configuration/

1 — 受限的所有者

秘密、令牌、API 密钥

禁止— 从未被索引

office/

2 — 受限协作

编辑数据、构图、培训

已过滤— 仅限视觉

foundry/private/

3 — 条件打开

闭源代码,非公开 SaaS

禁止— 私有数据集专用

foundry/public/

4 — 原生受众

Apache 2.0 代码,已发布的插件

自由— 完整索引

规则很简单:文件路径决定了 LLM 可以对其做什么。 无需维护元数据,无需在 frontmatter 中添加标签, 不需要每次提交都进行手动分类。文件位于`OSS/? 它是公开的。它在`configuration/? 他是不可触碰的。

认识论分类(第二维度)

空间维度告诉 哪里 路由。但还有第二个轴,垂直于此: quoi 路由器。 某些文件在授权区域内包含信息 不应当以原样稀释的:

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 240

title La Double Cascade — 空间过滤器 + 认知过滤器
start

:LLM 遇到一个文件;

if (Zone physique ?) then (Cercle 0-1)
  :ACCÈS BLOQUÉ\n(秘密,脑内倾倒);
  stop
elseif (Zone CSS/)
  :DROIT D'ACCÈS PRIVÉ\n→ 数据集微调;
  :认知过滤器\nVision/Opinion;
  if (Classification ?) then (VISION)
    :私有数据集\n→ 授权训练;
  else (OPINION)
    :CONFINÉ\n→ 没有训练;
  endif
elseif (Zone office/)
  :DROIT D'ACCÈS FILTRÉ\n→ 条件访问;
  :认知过滤器\nVision/Opinion/Stratégie;
  if (Classification ?) then (VISION)
    :DILUTION COMPL和\n→ 根文档 + 博客;
  elseif (STRATÉGIE)
    :DILUTION RESTREINTE\n→ 仅根文档;
  else (OPINION)
    :CONFINEMENT\n→ office/仅限;
  endif
else (Zone OSS/)
  :ACCÈS LIBRE\n→ 完整索引;
endif

stop

@enduml

认识论分类网格,刻在我的治理规则2bis中 代理 :

| 状态 | 定义 | Signal LLM | 目的地 | | VISION | 稳定的架构,经过测试的模式 | 声明式语言,会话/测试引用 | 完整稀释 + 博客 | | 战略 | 业务定位, 定价 | 市场词汇, 竞争 | 仅根文档 | | OPINION | 推测,未验证的假设 | 假设性语言,直觉 | 限制圈0 |

两个维度的组合 — 物理区域 × 认识论分类 — 形成完整矩阵:

@startuml
skinparam backgroundColor #FEFEFE

title 完整矩阵 — 区域 × 分类
salt
{
{T
+ Zone | VISION | STRATÉGIE | OPINION
+ Racine (0) | ✗ Interdit | ✗ Interdit | ✗ Interdit
+ configuration/ (1) | ✗ Interdit | ✗ Interdit | ✗ Interdit
+ office/ (2) | ✓ Docs + Blog | ✓ Docs seulement | ✗ Confiné
+ CSS/ (3) | ✓ Dataset privé | ✓ Dataset privé | ✗ Confiné
+ OSS/ (4) | ✓ Public libre | ✓ Public libre | ✓ Public libre
}
}

@enduml

LLM如何消费此矩阵

矩阵不是LLM读取的文档。这是一个 约束 隐式 编码在上下文合成向量中(EPIC 9 — 进行中 实现).

以下是LLM在每次会话中接收到的内容:

VECTEUR COMPOSITE DE CONTEXTE
├── RAG pgvector → OSS/ + office/Vision
│   (similarité sémantique sur contenu publiable)
├── Knowledge Graph graphify → OSS/
│   (relations exactes entre artéfacts publics)
├── Knowledge Graph privé → CSS/
│   (relations entre code closed source — jamais exporté)
├── Métadonnées de zone → chaque fichier taggé par zone physique
│   (le LLM sait s'il est dans office/ ou OSS/)
└── Historique des décisions → WORKSPACE_VISION.adoc
    (contexte temporel des arbitrages)

具体来说,当LLM告诉我:

Je vais indexer le contenu de edster/ pour enrichir le knowledge graph...

区域元数据在LLM还未完成句子之前就做出了回应: edster/`在`CSS/, 等级 3 →禁止访问公开知识图谱。 RAG 没有看到它。图没有接触它。用户回答不 他不引用它。

空间本体论充当一个Unix权限用于LLM。 您不会要求一个过程保持谨慎`/etc/shadow`— 您拒绝他读取权限。同样的原则。

实现 : 类型化的 Gradle 任务

矩阵不是一种哲学。这是代码。以下是任务合同 Gradle 实现它:

abstract class ZoneAwareIndexer @Inject constructor(
    private val rootDir: DirectoryProperty,
    private val configServer: ConfigServerProperty  // → configuration/
) : DefaultTask() {

    @Input
    val zoneFilter: SetProperty<Zone> = project.objects.setProperty(Zone::class.java)

    @OutputFile
    val ragIndex: RegularFileProperty = project.objects.fileProperty()

    @TaskAction
    fun index() {
        val allowedPaths = zoneFilter.get().flatMap { it.resolve(rootDir.get()) }
        val forbiddenPaths = Zone.RESTRICTED.resolve(rootDir.get())
                            + Zone.INTIMATE.resolve(rootDir.get())
        // Le RAG ne voit jamais configuration/ ni la racine
        // CSS/ alimente un index privé, pas celui-ci
        // office/ est filtré par le classifieur Vision/Opinion
    }
}

enum class Zone {
    INTIMATE,      // Cercle 0 — racine
    RESTRICTED,    // Cercle 1 — configuration/
    EDITORIAL,     // Cercle 2 — office/
    CLOSED_SOURCE, // Cercle 3 — foundry/private/
    OPEN_SOURCE    // Cercle 3 — foundry/public/
}

此任务是 testable。您可以编写一个测试来验证:

@Test
fun `le RAG n'indexe jamais configuration`() {
    val index = ZoneAwareIndexer(rootDir, configServer)
    index.zoneFilter.set(setOf(Zone.OPEN_SOURCE, Zone.EDITORIAL))
    index.index()

    assertThat(index.ragIndex).doesNotContain("configuration/")
}

@Test
fun `le code closed source est exclu du RAG public`() {
    val index = ZoneAwareIndexer(rootDir, configServer)
    index.zoneFilter.set(setOf(Zone.OPEN_SOURCE))  // OSS only

    assertThat(index.ragIndex).doesNotContain("edster")
}

380 个测试,380 个通过。与 plantuml-gradle 类似 — 安全性已进行测试, 未被期待的。

为什么这是一份宣言,而不仅仅是一个规范

此文档是一种架构规范,因为它定义:

  • 一些尺寸(空间的, 认识论的)

  • 一些确定性规则(区域 → 访问权)

  • Un 任务合同(Gradle 已类型化,可测试)

  • 一个参考实现(我的工作区)

但这也是一个宣言因为他在一场辩论中表明立场 更大: 如何管理LLM对数据的访问?

行业的回应,是提示工程 + 防护栏
事后分类器。 我的答案是: 把你的文件放在 良好的文件。 剩余的是自动的。

这个宣言并没有说 "LLM 必须对齐"。它说: "对齐"。 您的LLM在您的安全规则上的应用是您系统的后果 文件,不是你的提示。

完整的瀑布 — 从 Brain Dump 到博客文章

为了说明完整的循环,以下是这种矩阵概念的产生过程 并且被稀释了:

Session 4 mai 2026 — Feedback global du workspace
  │
  ├→ Le LLM identifie : "la dualité public/privé est invisible"
  │   → Classifié VISION (constat architectural vérifiable)
  │
  ├→ PICTURE_ME_ROLLIN_MATRICE_4X4.adoc — STIMULUS (Cercle 0)
  │   → Brain dump structuré, classification VISION confirmée
  │
  ├→ DILUTION → WORKSPACE_AS_PRODUCT.adoc (section Matrice 4×4)
  │   → La spec vit dans les documents racine
  │
  ├→ DILUTION → WORKSPACE_ORGANIZATION.adoc (OSS/CSS)
  │   → La granularisation est documentée
  │
  └→ ARTICLE 0117 (ce document) → cheroliv.com
      → La VISION est publiée

(“嘿, RAG不知道 que edster est closed source" 已成为一种架构规范。 已在不到一次会议的时间内发布。这就是 STIMULUS 模式正在发挥作用。

优点/缺点

这种方法 (空间本体 + 矩阵) 经典方法(Prompt + Guardrails)

机械 — 文件系统阻止了访问,而不是LLM

声明性 — 提示要求LLM保持谨慎

Testable — Gradle任务契约经过380+个测试验证

不可测试 — "LLM 是否遵守了规则?" 是一个开放性问题

独立于LLM——切换模型,文件夹保持不变

依赖于LLM — 每个模型以不同的方式解释提示

Scalable — 新数据类型 = 新文件夹,零代码更改

非可伸缩 — 新数据类型 = 新提示子句,新回归风险

可审计 — 文件系统是审计追踪

不可审计 — 该提示没有历史记录,没有 diff,也没有责备

约束 : 需要初始的组织纪律

约束 : 每次会话都需要提示词编写的纪律

结论:整理你的文件,而不是你的提示词

我刚刚描述的LLM治理矩阵不是一个产品。 这是一个架构规范— 而且这就是她是 可发布的。

使其健壮的是,它对LLM没有任何要求。它没有 不值得信任。它并不依赖于其对齐,其理解。 法语,或其善意。它基于文件系统 — 最底层、最稳定、经测试最多的那一层,是整个栈中的那一层。

当我对我的LLM说"您可以将所有内容索引在`OSS/, 里什么也没有 `configuration/, et `office/`仅当它被归类为 Vision 时 这不是一条指令。这是一个 过滤器 — 实现于 Kotlin, 通过 380 次测试验证,在 LLM 查看数据之前执行。

这就是告诉某人“不要看这个抽屉”的区别 并关闭钥匙抽屉。我一直在构建的代理治理 月份是关键。矩阵是家具的蓝图。

相关文章