セキュリティ

以下の内容はすべて、デーモン自身のソースと、API の生成元である spec/mcpd.spec.json から書き起こしたものです。ある制御が存在しない場合、このページはそれをそのまま書きます。質問票に答える段階であなたに見つけさせることはしません。

mcpd が保存するもの

mcpd は、あなたのエージェントの会話の本文を保存します。それがこの製品の目的であり、審査もそこから始めるべきです。種類が model_generation のスパンは input と output を持ちます。モデルに送られたプロンプトそのものと、返ってきたテキストそのものです。多くの利用者にとって、これは手元にある最も機微なデータです。

6 つのシグナルのうち、自由記述が保存されるフィールドは次のとおりです。

シグナル	保存される内容
スパン	`input`、`output`、`attributes`、`metadata`、およびエラーメッセージ
ログ	メッセージと、構造化された `fields`
メトリクス	`labels`
スコア	`reason` と `metadata`
フィードバック	自由記述の `comment` と `metadata`
観点ノート	文そのものである `text`

ペイロードに加えて、どのシグナルも、実行をシステムの他の部分と結びつける相関フィールドを持ちます。プロジェクト、環境、サービス名とバージョン、セッション、スレッド、ユーザー、リソース、実行、リクエスト、実験、リリースです。user_id は、秘匿化を切らないかぎり取り込み時にハッシュ化されます。それ以外は送られたまま保存されるので、どれかに個人を示す値を入れたなら、そのフィールドは個人を特定しうるものとして扱ってください。

トークン数とコストの値は取り込み時に計算され、実行とともに保存されます。モデル呼び出しに関する情報をプロバイダーから取得することはありません。

どこに書き込まれるか

バックエンドは 1 つで、起動時に選びます。既定は ./mcpd.db にある組み込みの SQLite ファイルで、--data で指定します。全文検索インデックスも同じファイルにあるため、バックアップも保護も 1 つのファイルで済みます。--postgres-url または --clickhouse-url を指定すると、あなたが運用するデータベースにデータが入ります。

永続実行は、有効なときは、トレースのストアが何であっても、1 つ目のファイルの隣にある 2 つ目の SQLite ファイルに入ります。このファイルは、すべての実行の入力、状態、出力、相関と、すべてのステップの入力、出力、エラーを、送られたとおりに保持します。秘匿化されず、user_id もハッシュ化されません。あとのステップがそれを読み返すので、書き換えた値は実行の動きを変えてしまうからです。実行がトレースのストアに書くスパンは、ほかのスパンと同じように秘匿化されます。実行のファイルは、トレースのストアと同じか、それ以上に保護してください。保持期間と個人単位の消去はどちらも、終わった実行についてこのファイルに及びます。実行を参照してください。

mcpd は書き込む内容を暗号化しません。保存時の暗号化は、組み込みストアではボリュームの役目、他の 2 つではデータベースの役目です。

マシンの外に出るもの

既定の設定では、何も出ません。デーモンが外部へリクエストを出す箇所はちょうど 4 つで、そのどれもが設定するまでオフです。更新確認も、利用状況の送信も、いかなるテレメトリーもありません。

送信先	送られるもの	有効になる条件
ストレージバックエンド	mcpd が保存するものすべてが、あなた自身の接続を通って送られます。	`--postgres-url` または `--clickhouse-url` を設定したとき。既定のストアはローカルファイルなので、ネットワークをまったく必要としません。
転送	保存されたすべてのスパンが、OTLP JSON として `{endpoint}/v1/traces` に再送出されます。ペイロードも含みます。`input` と `output` は `input.value` と `output.value` 属性として出ていき、それぞれ 32 KiB で打ち切られます。すでに秘匿化された値は秘匿化されたままで、ハッシュ化された `user_id` はハッシュのまま転送されます。	`--forward-endpoint`、または設定ファイルの `forward` ブロックを設定したとき。
モニターと目標の Webhook	決まった形の JSON 本文です。モニターまたは目標の id と名前、プロジェクト、条件、監視の対象、しきい値、測定値、サンプル数、 1 行の詳細、タイムスタンプ。プロンプトや補完は入りません。	設定ファイルのモニターまたは目標が `webhook` を指定しているとき。
ジャッジモデル	判定基準と、実行の質問およびその回答が、それぞれ 4,000 文字で打ち切られて `{endpoint}/chat/completions` に POST されます。保存されたプロンプトと補完をモデルプロバイダーに送る経路は、これだけです。	設定ファイルの `judge` ブロックがエンドポイント、モデル、少なくとも 1 つの判定基準を指定し、呼び出し側がそのスコアラーを名前で要求したとき。

バイナリが / で配信するインターフェースは、バイナリの中に組み込まれています。そのフォント、スタイル、スクリプトは同じオリジンから来ており、サードパーティへのリクエストは出しません。

キーとスコープ

認証は API キーです。アカウントもセッションもログインもありません。キーは Authorization: Bearer … として、または X-Mcpd-Key ヘッダーで渡します。比較の前に両側とも SHA-256 でハッシュ化されるため、設定されたキーの長さも、最初に食い違った文字の位置も、処理時間からは分かりません。

スコープは 6 つあり、与える到達範囲の順に並べると次のとおりです。

スコープ	許可されること	独立したスコープである理由
`ingest`	シグナルの書き込み。読み取りは一切なし。	このキーは、スパンを送出するすべてのコンテナに置かれます。サードパーティのコードを動かしているコンテナも含みます。そこに、保存済みのプロンプトをすべて開く力まで持たせるわけにはいきません。
`read`	保存されたシグナルの読み取り。	プロンプトがあるのは、読み取りの側です。
`write`	保存されたデータの変更。スコア、フィードバック、データセット、実験、確認応答。	これらのハンドラーのいくつかは、処理の途中でペイロードを読みます。本番の実行をデータセットに取り込む操作は、その実行の入力と出力を読むので、スパンを送出するより広い行為です。
`execute`	実行の開始、キャンセル、シグナル送信と、実行へのイベントの発行。	実行を開始するとお金がかかり、あなたのシステムに手が届きます。スコアを記録できるキーが、仕事を起動することまでできるべきではありません。
`worker`	ステップの取得と、その結果の報告。	ステップ本体を動かすプロセスの中にあるキーです。ステップを取得すると、そのステップの入力と、それより前のすべてのステップの出力が返るので、このキーはペイロードを読みます。実行の開始や保存データの変更までできるべきではありません。
`admin`	データの破棄と、監査ログの読み取り。	削除は、読み取りとは別のことです。

どのエンドポイントがどのスコープを要求するかは、仕様の中でエンドポイントごとに宣言され、生成された HTTP API リファレンスに掲載されます。「このエンドポイントには何が必要か」への答えは、ドキュメントごとに 1 つずつではなく、1 つだけです。

フォールバックと、すでに配ったキーにとっての意味

write のリストが未設定なら ingest のリストに、 admin のリストが未設定なら read のリストにフォールバックします。execute と worker のリストが未設定なら write のリストにフォールバックし、それも未設定なら ingest のリストに行き着きます。これは、狭いほうのスコープができる前に設定された全デプロイで、アップグレードがアクセスを取り上げてしまわないようにするためのものです。また admin キーは execute と worker にも使えるので、運用者は実行を手で動かせます。これらを合わせると、ingest キーと read キーだけを持つデーモンでは、次のことを意味します。

ingest キーは、スコアとフィードバックの付与、実行の開始、ステップの取得もできます。
read キーは、トレースの削除もでき、admin へのフォールバックを通じて、実行の開始とステップの取得もできます。

つまり --admin-key を設定するまで、read キーは削除キーでもあります。そして --execute-key、--worker-key、 --admin-key を設定するまで、どちらのキーも実行の面に届きます。キーを渡すときは、その前提で渡してください。範囲が勝手に狭まることはありません。スコープごとにフラグがあり、--ingest-key、 --read-key、--write-key、 --admin-key、--execute-key、 --worker-key がそれぞれリストを取ります。どれも設定ファイルでプロジェクトごとに設定することもできます。

キーが 1 つも無ければ、すべてのスコープが開いています

この既定は意図したものです。ノート PC での最初の実行に資格情報を要求するべきではありません。同時にこれは、露出したインスタンスについて最も危険な一点でもあります。そのためデーモンは、ループバック以外のアドレスにバインドしたとき、届くべきでない相手に開いている面ごとに、起動時に警告をログに出します。それぞれの警告は、その面と、それを閉じるフラグを名指しします。ポートを公開する前に mcpd config を実行してください。その呼び出しが解決した設定を表示して、終了します。出力にはスコープごとに 1 行あり、そのスコープがどのリストにフォールバックしたかも書かれます。admin auth key required (read keys) という行は、 read キーがまだ削除できることを伝えています。 Docker と Kubernetes にその出力があります。

到達可能になる前に閉じておく

mcpd --ingest-key "$INGEST" --read-key "$READ"

プロジェクトはテナントの境界です

トップレベルで設定したキーは、すべてのプロジェクトに対する権限を持ちます。代わりに、設定ファイルの projects ブロックの中で名前を付けたプロジェクトの下に並べたキーは、そのプロジェクトだけに対する権限を持ち、各プロジェクトはスコープごとに自分のリストを持ちます。1 つのキーを複数のプロジェクトの下に書くこともできます。プラットフォームチームが、サーバー全体を握らずに自分の運用範囲をまたぐキーを持つのは、この方法です。

書き込み経路では、確認はリクエスト単位ではなくシグナル単位です。

1 つのバッチが複数のプロジェクトを指定できます。キーが届かないプロジェクトを指定したシグナルは破棄され、理由とともに拒否分としてレスポンスに報告されます。誤ったプロジェクトを向いている一群のサービスは、すでに読んでいるレスポンスから見つけられます。バッチの残りは保存されます。

読み取り経路では、プロジェクトを指定するすべてのエンドポイントが、それをキーの権限と照合します。トレース、スパン、ログ、メトリクス、スコア、フィードバック、分析、データセット、実験、監査ログです。データセットの中の項目はデータセットの id で指定するため、デーモンはそのデータセットを所有するプロジェクトを引いてから、キーをそれと照合します。そのプロジェクトを開けないキーは、そこから取り込まれた事例も読めません。存在しない id は、キーが届かない id とまったく同じ形で拒否されるので、このエンドポイントを使ってどの id が存在するかを試すことはできません。3 つのエンドポイントはプロジェクトを取らず、どのプロジェクトに限定されていようと、read スコープを持つキーなら到達できます。プロジェクトの一覧、スコアラーのカタログ、ストレージの機能セット（GET /v1/api/capabilities）です。プロジェクトの一覧はキーの権限で絞り込まれるので、プロジェクトに限定されたキーには、届くプロジェクトだけが見えます。共有インスタンスでは、プロジェクト名はしばしばチーム名や顧客名です。モニターの状態と目標の状態もこの一覧にありましたが、いまはキーのプロジェクト権限で絞り込みます。もともとそうあるべきものでした。モニターは監視するプロジェクトを名前で持ち、投稿先の webhook を抱えているからです。 API が返すのはその webhook のホスト名だけです。webhook の URL はそれ自体が資格情報であることが多いからです。

拒否は、2 つの問題のどちらであるかを伝えます

キーが無い、または認識されない場合は 401 です。認識されたキーだが、このエンドポイントまたはこのプロジェクトが受け付けない場合は 403 です。この区別は運用のためのものです。401 なら資格情報の打ち間違いを探しに行くことになり、403 なら資格情報は正しく、間違っているのは権限のほうだと分かります。

4 種類の拒否

$ curl -sw "%{http_code} " "$MCPD/v1/api/traces?project=acme"401  this endpoint needs an API key; send it as `Authorization: Bearer <key>`$ curl … -H "authorization: Bearer $TYPO"401  that key is not one this daemon knows$ curl … -H "authorization: Bearer $INGEST"403  that key is not valid for reading$ curl … -H "authorization: Bearer $BILLING_READ"403  that key does not reach the project "acme"

最後のメッセージは、そのプロジェクトが存在してもしなくても同じ文言です。どのプロジェクト名が実在するかを確かめられること自体が小さな漏洩であり、共有のデーモンでは、その名前はあなたの顧客の名前です。

監査ログ

保存されたペイロードを mcpd の外へ渡す操作は記録されます。削除もすべて記録されるので、「この実行を誰が読んだか」という問いには答えがあります。 1 行には、いつ、どのキーが、どの操作を、どのプロジェクトで、どのトレースまたはデータセットを指定して行い、リクエストが処理されたか拒否されたかが入ります。GET /v1/api/audit が新しい順に読み出し、 admin スコープを要求します。

記録される操作は 18 個です。get_trace、list_spans、 list_logs、list_feedback、 list_dataset_items、capture_into_dataset、 read_trace_aspect_notes、get_theme、get_theme_flow、list_theme_history、list_theme_examples、 delete_trace、erase_subject、そして永続実行についての 5 つである list_runs、get_run、 list_run_events、get_step_cause、 cancel_run。境界はリクエストではなくペイロードにあります。トレースの一覧は、名前、時間、トークン数、コストの射影を返すだけでプロンプトも補完も含まないため、記録されません。そのうちの 1 つのトレースを開く操作は記録されます。テキストがあるのは、そこだからです。永続実行の一覧は記録されます。一覧のどの実行も、送られたとおりの入力、出力、状態を持つからです。実行の読み取りが拒否された場合は、その実行を所有するプロジェクトのもとで記録されます。

ワーカーの呼び出しは記録されません。ステップの取得、開始の宣言、ハートビート、complete、fail です。リースは確かにステップの入力と、その前のステップの出力を持ちますが、ワーカーのループは 1 分間に何度も取得するので、取得ごとに 1 行を書けば、人が行った読み取りが埋もれてしまいます。 worker キーは、それが処理する実行のすべてのペイロードを読むキーとして扱ってください。実行の開始も記録されません。保持されている冪等キーで再び送ると、そのキーが開始した実行が返るので、execute キーは、それが開始する実行を読めるキーとして扱ってください。

審査する人が知っておくべき性質が 5 つあります。

キーそのものは書き残されません。主体として記録されるのは、キーの SHA-256 ダイジェストを切り詰めたものです。これはキーどうしを区別しますが、キーを検証できる材料は残しません。開いたデーモンにキー無しで届いたリクエストは anonymous として記録されます。
人物の情報は、あなたのイングレスから来るか、まったく来ないかのどちらかです。mcpd にユーザーアカウントはないので、1 行がそれ単体で示すのは、操作を行ったキーであって、人ではありません。 subject フィールドは、--trusted-identity-header と --trusted-proxy-cidr の両方を設定したときに識別情報を持ち、そうでなければ空です。空が既定です。mcpd がその識別情報を自分で確立することはありません。あなたが指定したアドレスが主張した内容を記録するだけです。
拒否も記録されます。行は 403 を返す前に書かれます。他チームのプロジェクトに対する拒否された試みこそ、監査ログが存在する理由だからです。ログを読むこと自体は記録されません。ペイロードが一度も読まれないまま行が増えるだけで、その行は admin キーの持ち主がすでに知っていること以外を何も伝えないからです。
どのキーかを記録し、任意で誰かも記録します。キーは切り詰めたダイジェストとして保存され、キーそのものは保存されないので、このログに資格情報がたまることはありません。これは「admin キーがこれを削除した」には答えますが、「どの人が削除したか」には答えません。mcpd に ID プロバイダーが無いからです。2 つ目の答えが欲しいなら、あなたのイングレスがすでに付けているヘッダーと、それを付けてよいアドレスを渡してください。 --trusted-identity-header x-forwarded-user と --trusted-proxy-cidr 10.42.0.0/16 です。両方そろって初めて機能します。ヘッダーはポートに届く者なら誰でも送れる文字列なので、mcpd はあなたが指定したアドレスからのみ読みます。それ以外の場所からのリクエストは通常どおり処理され、その行には subject が入りません。推測するより、そのほうが正直だからです。どちらのフラグも設定しなければ subject は一度も記録されず、それが既定です。
保持期間はこれを削りません。保持期間の処理は、スパン、ログ、メトリクス、トレース、スコア、フィードバック、観点ノート、終わった永続実行を削除します。監査ログは残します。記述の対象であるデータと一緒に期限切れになるログでは、削除されたデータを誰が読んだかを言えないからです。
記述の対象であるリクエストを失敗させることはありません。 書けなかった行はログに出され、/metrics の mcpd_audit_write_failures_total として数えられ、読み取りはそのまま返ります。読み取り経路を止めうる監査ログは、それが防ぐ問題より重い負債です。リクエストが失敗することに頼らず、そのカウンターを監視してください。

キーが守らないもの

インターフェース。/ のマークアップは、ポートに到達できる誰にでも配信されます。その裏側のデータは違います。インターフェースが出すリクエストはすべてクエリ API を通り、同じキーに突き当たります。デーモンにログイン画面はありません。
プローブと /metrics。意図的に認証をかけていません。kubelet もスクレイパーもキーを持てないからです。返すのは状態、バージョン、稼働時間、ストレージバックエンドの名前とカウンターだけで、ペイロードは決して返しません。
オリジン。クエリ API とプローブは Access-Control-Allow-Origin: * を返すので、どのオリジンのブラウザーページからでも呼び出せます。mcpd は Cookie も暗黙の資格情報も使わないため、そうしたページも結局はキーを持つ必要があります。緩いオリジンポリシーが、キーを渡してくれるわけではありません。

秘匿化ができること、できないこと

秘匿化は既定で有効で、書き込みの前、取り込みパイプラインの 3 段目で走ります。ルールに一致した値は、データベースに一度も届きません。これは後から削除された値とは別の保証であり、監査人が尋ねるのは、まさにその違いです。一方で、そのバイト列がネットワークを渡ること自体は防げません。ルールが走る時点で、それはすでにネットワークを渡ったあとです。そのために SDK は MCPD_CAPTURE_PAYLOADS=false を持っており、スパンがキューに入る前に input と output を落とし、それ以外はスパンに残します。

Ingest pipeline

Decode

OTLP or native, gzip or plain
Sample

Decided once, at the root
Redact

Before anything is written
Price

From the configured price book
Store

One transaction per batch

Redaction is stage three, not a cleanup job. A value that a rule matches never reaches storage at all.

ルールは、小文字の部分文字列の集合とモードの組です。キーの名前を小文字にしたものがそのいずれかを含むとき、一致します。一致した値はマスク、部分マスク、鍵付きダイジェストによるハッシュ化、または破棄のいずれかになります。一致したキーがオブジェクトを持つ場合、その配下は子のキー名にかかわらずすべて秘匿化され、JSON の数値として送られた秘密も、文字列として送られた場合と同じに扱われます。ルールの全表はマスキングと保持にあります。

次に限界です。審査で必ず尋ねられ、どれだけ設定しても消えないものです。 ルールが一致するのはフィールド名であって、値の形ではありません。 利用者が文章の途中に貼り付けた API キーが、content や question という名前のフィールドで届いた場合、パイプラインの何にも一致しません。フィールド名に問題がないので、値はそのまま丸ごと保存されます。

したがって秘匿化が止めるのは、1 つの具体的なことだけです。

資格情報や識別子が、構造化された形で取り込まれることを止めます。資格情報が、それが何であるかを表す名前のフィールドで届く場合です。
自由記述を走査することはなく、内容の分類器でもありません。
秘密をその形やエントロピーから検出することはありません。
スパンの名前やログレコードのメッセージには手を触れません。それらはペイロードではなく、グルーピングに使う識別子であり、書き換えるとグルーピングが壊れるからです。スパンの名前を顧客のメールアドレスから組み立てないでください。
実行ストアには手を触れません。永続実行のペイロードはその作業状態であり、送られたとおりに保持されます。秘匿化されるのは、実行がトレースのストアに書くスパンだけです。

形に対して働く制御が 1 つだけあります。ただし予防ではなく、事後の検出です。組み込みの no_leaked_secret スコアラーは、回答に資格情報らしいトークンを含む実行の点数を下げます。判断は、既知の接頭辞か、大文字と小文字が混じった長い英数字の連なりによります。採点するのは、すでに保存された実行です。何も削除せず、プロンプトは読まず、あなたが要求したときにだけ走ります。秘匿化の 2 段目ではなく、これが起きたと知るための手段として扱ってください。

ルールに一致したかどうかに関係なく、2 つの上限がかかります。128 KiB を超える単一の文字列は、文字境界で目印を付けて切り詰められ、走査は深さ 32 で止まります。どちらも、暴走した 1 つのドキュメントがデータベースの大きさを決めたり、CPU を占有したりできないようにするためのものです。

--no-redact はパイプライン全体を止めます。これが妥当なのは、上流ですでに秘匿化されている場合だけです。秘匿化が識別子をハッシュ化する場面では、--redact-key を設定してください。組み込みの鍵は公開されたソースの中の定数であり、識別子は狭い空間から来るため、鍵なしのダイジェストは候補を当ててみることで復元できます。

保持期間と消去

--retention-days は、その日数より古いシグナルを削除します。指定しなければ何も削除されません。これが正しい既定です。先月のトレースを黙って捨てる道具では、そのことに気づくのが、いちばん困るときになります。

この処理はデーモンの中で 1 時間ごとのタイマーで走り、利用者のリクエストの中では決して走りません。対象は projects ブロックに書かれたすべてのプロジェクトで、各プロジェクトは自分で retention_days を設定していればその値を、していなければ全体の値を使います。既定のプロジェクトも対象です。どこにも期間の設定がないプロジェクトは、まったく削られません。

1 人の個人についての請求には、 DELETE /v1/api/subjects/{user_id}?project=… を使います。そのプロジェクトでその人に紐づけて記録されたすべての実行を、付随するスパン、ログ、メトリクス、スコア、フィードバックとともに削除し、シグナルごとの件数を返します。識別子は照合の前に同じ鍵でハッシュ化されるので、あなたが自分で何かをハッシュ化しなくても、ハッシュ化済みの識別子に対して機能します。またレスポンスは、保存されている識別子のうち、リクエストが照合できない形のものが何件あったかを伝えます。1 人ではなく 1 つの実行を削除するには DELETE /v1/api/traces/{trace_id} を使い、その実行と、付随するすべてを 1 つのトランザクションで削除します。どちらも admin スコープを要求し、どちらも監査ログに記録されます。マスキングと保持が、消去の請求と、それが約束できること、できないことを順に説明します。

mcpd がやらないこと

以下のどれも、このビルドには存在しません。ここに並べているのは、審査が後からこれらを見つけるより、ここで読んでもらうほうが良い結果だからです。

mcpd に無いもの	代わりにすること
TLS 終端。mcpd は平文の HTTP を話します。プロンプトと補完は、その経路を丸ごと通ります。	TLS はイングレスかメッシュで終端し、デーモンのポートを信頼できないネットワークに出さないでください。
SSO。ID プロバイダーとの連携はなく、OIDC も SAML もログイン画面もありません。	インターフェースは、すでに運用している認証プロキシの後ろに置いてください。人物の識別は、そのプロキシが確立したものがすべてです。
SCIM。ユーザーやグループのプロビジョニングはありません。mcpd にユーザーアカウントという概念が無いからです。	プロビジョニングはプロキシ側で行ってください。mcpd の中での単位はキーであり、リストに足すか、リストから外すかです。
6 つのスコープを超えるロール。認可はスコープと、プロジェクトのリストです。エンドポイントごとのロールもグループもありません。	キーとプロジェクトで分けてください。ある区別が重要なら、それをプロジェクトにしてください。
人物が誰であるかを確定すること。監査ログは subject を記録できますが、mcpd が呼び出し元は誰かを突き止めることはありません。あなたのイングレスが主張した内容を、あなたが指定したアドレスからのみ記録します。	`--trusted-identity-header` と `--trusted-proxy-cidr` を設定し、プロキシがすでに付けているヘッダーが監査の行まで届くようにしてください。設定しない場合、行が示すのは操作を行ったキーだけなので、チームごとにキーを発行すれば、ダイジェストが指す範囲が狭まります。
キーのライフサイクル。キーは起動時に読まれるリストです。有効期限も、ローテーションの予定も、キーごとの割り当てもありません。存在する上限はプロジェクト単位です。`--quota-per-minute` が、どのキーから送られたかに関係なく、1 つのプロジェクトが 1 分間に保存できるシグナル数を制限します。	チームや一群のサービスごとに 1 つずつ、複数のキーを設定してください。そうすれば 1 つを失効させる作業は、スパンを送出するすべてを再デプロイすることではなく、編集と再起動で済みます。ある一群に独自の上限が必要なら、それを独立したプロジェクトにしてください。
保存時の暗号化。mcpd が書くのは、平文のファイルか平文の行です。	ボリュームを暗号化するか、暗号化するデータベースを使ってください。

報告するとき

脆弱性の疑いは、公開の issue ではなく、件名に "Security" を入れて [email protected] に送ってください。リポジトリの SECURITY.md に、対象の範囲と、良い報告に含まれるものが書かれています。誰かが自分で公開した、認証なしのインスタンスは、発見ではなく文書化された既定の動作です。設定済みのキーをすり抜けたもの、設定済みの秘匿化ルールをすり抜けたもの、プロジェクトの境界を越えたものは、発見です。

次に

ルールの表、4 つのモード、鍵付きハッシュ：マスキングと保持。
ポートが到達可能になる前に設定すべきこと：Docker と Kubernetes。
すべてのフラグと環境変数：設定。
コードから、またはエージェントから、デプロイ済みのインスタンスに接続する：導入。