LLMガバナンスマトリクス — なぜあなたのAIのセキュリティはツリー構造から始まるのか
公開日: 04 May 2026
何ヶ月も、エージェントのガバナンスルールを積み重ねてきました。ファイル EAGER、LAZYなチェックリスト、6段階のセッション終了プロトコル。 しかし、未解決の質問が残っていた: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."
このプロンプトには3つの問題があります:
-
LLMの善意に依存している。 十分に大きいモデルで
複雑なバグを解決することは、命令を回避するのに十分大きい 200kトークンのコンテキストに埋もれたセキュリティ
-
それは文脈依存であり、構造的ではありません。プロンプトを変えて、LLMを変えて
セッションを変更する — そしてルールが消える。
-
それはスケールしない。* 新しいファイルタイプごとに、新しいレベルごとに
機密保持には新しい条項が必要です。あなたのプロンプトは 誰も全てを読まない規制テキスト
|
システムのセキュリティは、決して、私たちが命令に依存してはならない 忘れたり、回避したり、あるいは読み込まないこともあります。彼女は何かに依存しなければなりません。 明示的に望まない限り越えられない障壁 |
私の回答:4×4の行列
私がワークスペースで実装したソリューションは、ゾーン × マトリックス LLMへのアクセス権**. 彼女はLLMに慎重であることを求めない。彼女は 構造的に不可能な軽率さ
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 220
title LLMガバナンスマトリックス — ゾーン × アクセス権
package "ワークスペース" {
rectangle "根
(円 0)
━━━━━━
Brain dump
自由思考
[LLM禁止]" as Z0 #FFB3B3
rectangle "configuration/
(円 1)
━━━━━━
シークレット, トークン
プライベートインフラ
[禁止 LLM]" as Z1 #FFB3B3
rectangle "office/
(サークル 2)
━━━━━━
編集データ
記事、構図
[フィルタード Vision]" as Z2 #FFF3B3
rectangle "foundry/private/
(サークル 3)
━━━━━━
クローズドソースコード
[データセット プライベート]" as Z3 #B3D9FF
rectangle "foundry/public/
(サークル 3)
━━━━━━
オープンソースコード
Apache 2.0
[フリーアクセス]" as Z4 #B3FFB3
}
Z0 -[hidden]-> Z1
Z1 -[hidden]-> Z2
Z2 -[hidden]-> Z3
Z3 -[hidden]-> Z4
@enduml
五つのゾーン(空間的次元 — RGPD)
ワークスペースの各ゾーンには、ファイルを置くことができる場所を決定するGDPRレベルがあります。 ルーティングされる:
�ゾーン |
RGPDレベル |
内容 |
公共のRAGアクセス権 |
根 |
0 — 親密 |
ブレインダンプ、LLM との会話 |
禁止— 決してインデックスされない |
|
1 — 制限された所有者 |
シークレット, トークン, APIキー |
禁止— 決してインデックスされない |
|
2 — 制限された協働 |
編集データ, フレーミング, 研修 |
フィルタリングされた視覚のみ |
|
3 — 条件付きオープン |
クローズドソースのコード、非公開のSaaS |
禁止— 専用のプライベートデータセット |
|
4 — ネイティブなオーディエンス |
Apache 2.0コード、公開されたプラグイン |
自由— 完全インデックス |
ルールはシンプルです : ファイルのパスがLLMがそれにできることを決定します。 メタデータを維持する必要はなく、フロントマターにタグを追加する必要もありません, 各コミットで手動分類は行われません。ファイルは`OSS/? それは公開されています。それは中に`configuration/? それは触れられない。
認識論的分類(第二次元)
空間的次元は*どこ*へルートするかを示す。しかし、もう一つの軸があり、それが垂直である: quoi ルータ。認可されたゾーン内の一部のファイルには情報が含まれています そのまま薄めてはいけない:
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 240
title ダブルカスケード — 空間フィルター + 認識フィルター
start
:Le LLM rencontre un fichier;
if (Zone physique ?) then (Cercle 0-1)
:ACCÈS BLOQUÉ\n(secret, brain dump);
stop
elseif (Zone CSS/)
:DROIT D'ACCÈS PRIVÉ\n→ dataset fine-tuning;
:Filtre épistémique\nVision/Opinion;
if (Classification ?) then (VISION)
:Dataset privé\n→ entraînement autorisé;
else (OPINION)
:CONFINÉ\n→ pas d'entraînement;
endif
elseif (Zone office/)
:DROIT D'ACCÈS FILTRÉ\n→ accès conditionnel;
:Filtre épistémique\nVision/Opinion/Stratégie;
if (Classification ?) then (VISION)
:DILUTION COMPLÈTE\n→ docs racine + blog;
elseif (STRATÉGIE)
:DILUTION RESTREINTE\n→ docs racine seulement;
else (OPINION)
:CONFINEMENT\n→ office/ uniquement;
endif
else (Zone OSS/)
:ACCÈS LIBRE\n→ indexation complète;
endif
stop
@enduml
エピステミックな分類グリッド、私の統治の規則2bisに刻まれた エージェント :
| ステータス | 定義 | LLM シグナル | 宛先 | | VISION | 安定したアーキテクチャ、テスト済みのパターン | 宣言型言語、セッション/テスト参照 | 完全希釈 + ブログ | | 戦略 | ビジネスポジショニング、価格設定 | 市場用語、競争 | ルートドキュメントのみ | | OPINION | 推測、未検証の仮説 | 仮説的な言語、直感 | 隔離 円0 |
2つの次元 — 物理的領域 × 認識論的分類 — の組み合わせ 形作る完全なマトリックス:
@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 →パブリックな knowledge graph へのアクセスは禁止されています。 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/
}
タスクは テスト可能。あなたは、確認するテストを書くことができます:
@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 tests, 380 PASS. plantuml-gradleと同様に、セキュリティはテストされています 期待されていなかった。
なぜこれがマニフェストで、単なるスペックではないのか
このドキュメントはアーキテクチャ仕様であり、それが定義するためです:
-
いくつかのサイズ(空間的, 認識的)
-
いくつかの決定論的なルール(ゾーン → アクセス権)
-
Un タスク契約(型付きGradle、テスト可能)
-
一つ参照実装( 私のワークスペース )
でもそれはまた一つマニフェストなぜなら彼は議論に立場を取るから より大きい : LLMのデータへのアクセスをどのように管理するか?
業界の答えは、プロンプトエンジニアリング + ガードレールです
ポストホックな分類器。私の回答は:ファイルを整理する 良いフォルダー。** 残りは自動的です。
|
このマニフェストは「LLMは整合されるべきだ」とは言わない。それは「整合」と言う。 LLM が あなたの セキュリティ ルール に 対する こと は 、 あなた の システム の 結果 で あ る ファイル、あなたのプロンプトではありません。 |
完全なカスケード — ブレインダンプからブログ記事へ
フルサイクルを示すために、このマトリックスのアイデアがどのように生まれたかをご紹介します そして希釈された:
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
これはセッション中の観察として始まった ("hé, le RAG ne sait pas 「edster がクローズドソースである」ということがアーキテクチャの仕様になった。 1セッション未満で公開されました。これが STIMULUS パターンが動いている様子です。
�賛成/反対
| このアプローチ (空間オントロジー + マトリクス) | クラシックアプローチ(プロンプト+ガードレール) |
|---|---|
メカニクス — ファイルシステムがアクセスをブロックし、LLMではありません |
Déclarative — プロンプトは LLM に慎重であるよう求める |
Testable — Gradleタスクの契約は380+テストで検証されています |
テスト不能 — "LLMはルールを守ったか?" はオープンな質問です |
LLMに依存しない — モデルを変更し、フォルダはそのまま |
LLMに依存している — 各モデルはプロンプトを異なるように解釈する |
スケーラブル — 新しいデータ型 = 新しいフォルダー, コード変更なし |
非スケーラブル — 新しいデータ型 = 新しいプロンプト句, 新しい回帰リスク |
監査可能 — ファイルシステムは監査証跡です |
監査不能 — プロンプトには履歴がなく、差分もなく、責任もない |
Contrainte : 初期の組織的な規律が必要です |
Contrainte : プロンプトの作成における規律を毎回のセッションで求める |
結論 : ファイルを整理し、プロンプトは整理しない
私が説明したLLMガバナンスマトリックスは製品ではありません。 これはアーキテクチャ仕様— そしてそれが理由で彼女は 公開可能な。
それを頑健にしているのは、LLMに何も求めないからです。彼女は 彼に 信じない。彼女は自分の整合性と理解に頼っていない。 フランス語、あるいはその善意。ファイルシステムに基づいています — 最も低く、最も安定し、最もテストされた、スタック全体の層。
私が私のLLMに「全部インデックスできる」と言うとき`OSS/, 何も `configuration/, et office/「ビジョン」と分類されている場合のみ" — これは指示ではありません。これは*フィルター*— Kotlinで実装されています 380のテストで検証済み、LLMがデータを見る前に実行。
これは、誰かに「この引き出しを見ないで」と言うことの違いです。 そして、鍵付き引き出しを閉じる。私が構築してきたエージェントガバナンスは 数か月が鍵です。マトリックスは家具の設計図です。
関連記事
31 May 2026
14 May 2026