Boundary Checked
後から読める
後から読める
境界。
Boundary Receipt は、Agent が何を見てよかったか、何が拒否されたか、 何がまだ未接続かを記録します。判断は記憶から組み立て直すのではなく、 後から読み返してレビューできる形で残ります。
BOUNDARY RECEIPT
サンプル
agentsupport-copilot
data_pathcrm.customers → agent
use_casedraft reply
purposesupport_response
name, ticket_idallowed
order_historyallowed
payment_cardblocked
export to emailblocked
internal_notesunknown
BOUNDARY CHECKED
例示サンプルです。Check-in の Receipt は 1 つの経路について下した判断を 記録するもので、改ざん検知可能な本番の監査ログではありません。
記録するもの
許可、拒否、未接続 — そしてその理由。
3 つの正直な状態。未接続を隠すのではなく、名前を付けて 判断できるようにするためのものです。
許可 / Allowed
対象内
この申告された目的のために、Agent が見て、組み合わせてよい field と source。
拒否 / Blocked
対象外
この経路で Agent が見ても、組み合わせても、出力してもいけないもの — とその理由。
未接続 / Unknown
まだ判断していない
実在するが、まだ判断されていない経路。黙って許可せず、表に出します。
自分たちへの境界チェック
Receipt が主張すること — そして主張しないこと。
あなたの Agent に適用するのと同じ規律を、自分たちの言葉にも適用します。
主張すること
- + 1 つの経路について、何が許可され、拒否され、未接続のまま残ったかを記録する
- + 境界を解決する根拠になった、申告された目的を明記する
- + 会社が後から読んでレビューできる判断として残す
- + Assembly と出力のどこに本当の露出があるかを示す
主張しないこと
- − コンプライアンス認証ではない (SOC 2 / ISO / GDPR / AI Act)
- − 改ざん検知可能な本番の監査ではない — それは enforcement であって、check-in ではない
- − Agent がデータを決して漏らさないと約束するものではない
- − 申告された目的はラベルであって、認可ではない
Aegis Gateway は、協力しない Agent に対して境界を強制し記録する、計画中の runtime の入口です。最初の公開 offer は助言型の Boundary Check-in — 強制ではなく、マッピングです。
最初の Boundary Receipt を見る。
1 つの Agent、1 つのデータ経路、1 つのユースケースで Boundary Check-in を行う。