要約 / ポイント
17,000のAIツールにおける静かなる侵害
インテリジェントオートメーションの先駆者として称賛されるAI agentsは、深く不穏な秘密を抱えています。それは、機密データを公然と露出させる広範なセキュリティ上の欠陥です。研究者たちは、17,000を超えるAI agentスキルの徹底的な監査を完了し、エコシステム全体にわたる驚くべき広範囲な脆弱性を発見しました。彼らの調査結果は明白です。これらのツールのうち520が、日常的な操作中に重要な秘密を積極的に漏洩しており、これらのシステムへの信頼を根本的に損なっています。
これは理論上の懸念や些細な不具合ではありませんでした。これらのagentスキルは、現実の、非常に機密性の高い情報をブロードキャストしていました。露出したデータには以下が含まれます。 - API keys - OAuth tokens - Database passwords
このような情報漏洩は、バックエンドシステム、ユーザーアカウント、および独自のデータベースへの不正アクセスを許し、企業および個人のデータ整合性に対して即座かつ深刻な脅威をもたらします。この急速に発展するテクノロジー分野において、この意図しない露出の規模は前例がなく、システム的な見落としを示唆しています。
決定的なことに、これらの漏洩は悪意のあるハッキング試行や高度なジェイルブレイクに起因するものではありませんでした。機密データの露出は、agentが設計された機能を実行する際の完全に通常の利用中に発生しました。これは、外部からの攻撃ではなく、AI agentフレームワーク自体における根本的なアーキテクチャ上の見落としを示しており、この問題を従来のセキュリティ監査だけでは検出が困難な、陰湿なものにしています。
これは、現代のAI agentsのコアアーキテクチャに特有の、新しい種類の脆弱性を表しています。デバッグ出力が一時的なコンソールに単純に表示される従来のソフトウェア開発とは異なり、AI agentフレームワークはしばしば標準出力を捕捉し、それをモデルの永続的なcontext windowに直接供給します。一時的な開発者向けの洞察を意図した単純なdebug printは、AIにとって永続的で検索可能な記憶となるのです。
agentはこれらの秘密を効果的に「記憶」し、それらをプロンプトで引き出す方法を知っている人なら誰でもアクセスできるようにします。開発者が無害で一時的なログエントリだと考えていたものは、agentの運用メモリと不可分に結びついた永続的なセキュリティ上の負債へと変貌します。このメカニズムは、AIデプロイメントのセキュリティ状況を根本的に再構築し、無害な内部デバッグプラクティスを、巧妙なデータ抜き取りと広範な侵害のための重要な経路に変えてしまいます。
開発者が繰り返し犯す73%の過ち
データ漏洩の驚くべき73%は、驚くほどありふれた原因、すなわち単純なdebug print statementsに起因していました。開発者は、実行を追跡したり変数を検査したりするために、日常的に`print`や`console.log`コマンドを挿入しますが、これは従来のアプリケーションでは通常無害な習慣です。
しかし、AI agentsの複雑な世界では、この一般的な慣行が重大な脆弱性へと変貌します。agentフレームワークは標準出力を捕捉し、それをモデルのcontext windowに直接渡します。これは、一見無害なデバッグ行が単なるログではなくなり、AIがそれを積極的に記憶し、後で繰り返すことができるようになることを意味します。
そのメカニズムは非常にシンプルです。スキルがAPI keyやdatabase passwordのような機密トークンを読み込み、簡単なデバッグチェックのためにそれをprintし、その後は通常通り処理を進めます。その秘密は今やagentのアクセス可能なメモリ内に存在し、簡単なプロンプトによって容易に引き出される状態になっています。
この広範な見落としは、開発者に蔓延する心理、すなわち「一時的な」デバッグコードは本番環境にデプロイされる前に削除されるという思い込みに起因します。しかし、締め切りに追われている時や、定期的なアップデートの際、これらの忘れられたコードが残り続け、デプロイされたAIシステムに恒久的なバックドアとなります。
この問題の規模は、家の鍵を玄関マットの下に置いておくようなものですが、デジタルかつグローバルに分散された規模で発生しています。1つの物理的な鍵ではなく、監査された17,000のAIエージェントスキルの中で520にわたって露出している数千ものデジタルキー — API keys、OAuth tokens、そしてdatabase passwords — について話しているのです。
研究者たちは、これらが高度なジェイルブレイクや複雑なエクスプロイトではないことを発見しました。これらの漏洩は、ごく普通の利用中に発生し、高度なハッキングを必要としません。ユーザーは「最後のデバッグ出力は何でしたか?」と尋ねるだけで、秘密が平文で表示されます。
あなたのAIの完璧で、漏洩しやすい記憶
AIモデルはコンテキストウィンドウで動作します。これは、特定のセッション内のすべての会話のやり取り、入力、出力を記録する重要な動的メモリバッファです。このウィンドウはAIの即時作業記憶として機能し、一貫性を維持し、進行中のインタラクションを理解するために不可欠です。複雑なAIスキルを調整するために設計されたエージェントフレームワークは、統合されたツールによって生成される標準出力の*あらゆる*ビットを細心の注意を払って捕捉し、それをこのコンテキストに直接供給します。
これは単なるロギング操作ではありません。AIの理解への直接的なパイプラインです。開発者が一時的な内部デバッグメッセージとして意図したもの、例えばAPIキーを明らかにする`print`ステートメントや`console.log`のようなものは、即座にAIの運用メモリに恒久的なものとして定着します。AIの本来の設計上、コンテキスト内のすべてを処理し「記憶」するため、これらのデバッグ出力を進行中のインタラクションにとって不可欠な情報として扱います。
コンテキストウィンドウを、AIとそのツール間のあらゆるインタラクションに存在する、疲れ知らずで完璧に正確な速記者だと想像してください。このデジタル書記は、話されたことすべて、発行されたすべてのコマンド、そしてツールの内部動作からのあらゆる「ささやき」を勤勉に書き起こします。意図された応答やユーザーのクエリだけでなく、デバッグプリントステートメントを介して意図せず「ささやかれた」機密データも捕捉し、将来の参照のためにそれを逐語的に保存します。
APIキー、OAuthトークン、データベースパスワードといった秘密がこのコンテキストに入ると、セッション全体にわたってアクセス可能となります。AIはその後、いつでもこの機密データを呼び出して再利用できるため、元のデバッグステートメントが一度しか実行されなかったとしても、漏洩が永続的に悪用可能になります。研究者たちは、恐ろしく単純な取得方法を発見しました。AIに「最後のデバッグ出力は何でしたか?」と尋ねるだけで、これらの秘密が平文で明らかになることが多く、この広範な見落としの深刻さを強調しています。機密データ露出という蔓延する課題についてより深く理解するために、State of Secrets Sprawl Report 2025 - GitGuardianのようなリソースが包括的な洞察を提供しています。
裏切りの解剖学
秘密がAIエージェントの高度な侵害によって漏洩することは稀です。むしろ、驚くべきことに漏洩の73%は、極めて単純でほとんど無害に見える開発プラクティス、すなわちデバッグプリントステートメントに起因しています。この一般的な見落としは、一時的な診断出力を恒久的なAIの知識に変え、致命的で容易に回避可能な脆弱性を生み出します。この「裏切りの解剖学」を理解することで、エージェント自身のコードがどのように機密データを危険にさらすかが明らかになります。漏洩した秘密のライフサイクルは、予測可能な3段階のシーケンスに従います。
外部サービス、例えばサードパーティの決済ゲートウェイや独自のデータストアと連携するためにAPIキーを必要とするPythonベースのAIエージェントスキルを考えてみましょう。開発者は通常、このような機密性の高い認証情報をソース管理から除外し、安全なデプロイメントを確保するために、環境変数からロードします。`api_key = os.getenv('API_KEY')`のような行は、システムの環境からキーを効果的に取得するもので、標準的で安全な最初のステップです。
この安全な取得の直後に、致命的なエラーが発生することがよくあります。開発中やテスト中に、キーが正しくロードされたかを確認したり、APIコールの認証をデバッグしたりするために、開発者は一見無害な`print(f'Using key: {api_key}')`ステートメントを追加するかもしれません。この行は、実際のシークレットを完全なプレーンテキストで標準出力に出力します。これは、従来のプログラミングにおける迅速な診断チェックのための一般的で、ほとんど本能的な習慣です。
ここがまさに、AIエージェントフレームワークが意図せずして、しかし非常に効果的なデータ漏洩の共犯者となる場所です。`print`ステートメントが単にコンソールやローカルのログファイルに書き込み、人間がレビューする従来のアプリケーションとは異なり、現代のAIエージェントフレームワークは、*すべての*標準出力をキャプチャするように設計されています。これらのフレームワークは、この出力を包括的に取り込み、すべての文字をエージェントの継続的なインタラクションと運用状態に関連する潜在的な情報として扱います。
キャプチャされた出力、特にAPIキーの重要なデバッグ出力は、直接LLMのコンテキストウィンドウに注入されます。このコンテキストウィンドウは、現在の会話やタスクにおけるAIの主要な短期記憶として機能し、モデルが「知っている」こと、参照できることを本質的に定義します。元の意図に関わらず、そこに供給されたすべての情報は、基盤となる大規模言語モデルに即座にアクセス可能になります。
コンテキストウィンドウ内に入ると、そのシークレットは一時的なデバッグメッセージではなくなります。それは、そのセッション全体におけるAIのアクティブな「知識ベース」の消えない一部となります。攻撃者、あるいは何も知らないユーザーでさえ、「最後のデバッグ出力は何でしたか?」や「使用しているキーについて教えてください」といったクエリでAIに簡単にプロンプトを出すことができ、AIは公開された認証情報を完全なプレーンテキストで容易に繰り返します。これにより、一見無害なデバッグ行が、そのインタラクションにおけるAIの知識ベースの永続的な一部となり、機密データの深刻かつ容易に防げる裏切りとなります。
「尋ねるだけ」:史上最も簡単なハック
AIエージェントのメモリから漏洩したシークレットを取得することは、驚くほど些細なことであり、高度なハッキングスキルや手の込んだジェイルブレイクは必要ありません。開発者の誤ったデバッグステートメントがAIのコンテキストウィンドウ内に機密データを埋め込むと、どんなユーザーでも単にそれを尋ねることができます。これは洗練されたエクスプロイトではなく、AIの従順な情報リコールシステムとしての機能を活用した直接的な情報要求です。
ユーザーは、これらの隠された詳細を抽出するために、一見無害なプロンプトを使用するだけで済みます。「最後のデバッグ出力は何でしたか?」や「ツールの実行ログを要約してください」といったクエリは、AIから機密データを引き出すのに十分な場合がよくあります。エージェントは、設計どおりに正確に動作し、要求された情報を忠実に取得して提示します。これには、実際のAPIキー、OAuthトークン、あるいはその運用プロセス中に遭遇したデータベースパスワードが含まれる可能性があります。
重要なことに、AI自体は悪意なく動作し、データの機密性に対する本質的な理解を欠いています。AIは単に指示に従い、そのコンテキスト内で処理または記憶するように明示的に与えられたデータを提供します。これは開発者間の根本的な誤解を浮き彫りにします。彼らはdebug printsを一時的で一時的な出力として扱います。しかし、AIにとって、そのstandard outputはコアメモリの不可欠な一部となり、リクエストを満たすために使用する他の重要なデータと区別できません。
この脆弱性は、ユーザーベースが広く、しばしば匿名である一般公開のAI agentsにとって劇的にエスカレートします。意図や技術スキルに関係なく、あらゆるユーザーが内部ログについてシステムを尋問する可能性があります。開発者がテスト中に`print()`や`console.log`ステートメントを削除し忘れたために、カスタマーサポートボットや公開データ分析agentが誤ってバックエンドの認証情報を漏洩させてしまうことを想像してみてください。取得の容易さは、たった一人の好奇心旺盛なユーザーがシステム全体を危険にさらす可能性があることを意味します。
研究者たちは、17,000以上のAI agent skillsにわたってこの広範なパターンを発見し、そのうち520は通常の利用中に明らかに秘密を漏洩していました。これらの重要な漏洩の73%以上は、開発者が削除を怠った単純なdebug printsに起因していました。この広範な見落としは、開発者の便宜であるべきものを重大なセキュリティ上の欠陥に変え、機密データを尋ね方を知っている誰にでも利用可能にします。この「ハック」の単純さは、これらのagentsに依存するシステムのセキュリティを根本的に損ないます。
READMEから破滅へのパイプライン
即時のデバッグステートメントを超えて、より陰湿な脆弱性が潜んでいます。それはcross-model leaksです。これらの秘密はAIの出力内にプレーンテキストで現れるのではなく、一見無害なagentの応答と外部のプロジェクトドキュメントを組み合わせたときに現れます。これにより、単純な観察では検出が著しく困難になります。
ある操作の後に一見ランダムなIDまたはGUIDを出力するAI agent toolを考えてみましょう。この識別子は、明らかな機密データが付随することなく、モデルのcontext windowに入る可能性があります。それ自体では、その文字列は無害に見え、即座に悪用される経路を提供しません。
しかし、攻撃者がその出力をプロジェクトの公開README、API documentation、あるいは内部Wikiと相互参照すると、その秘密は非常に明白になります。例えば、その「ランダムな」IDは、一時的なセッショントークン、または別の場所に文書化された事前共有秘密と組み合わされて有効なAPI keyを形成するクライアントIDとして明示的に記述されている場合があります。
この、無害に見える出力から完全に明らかにされた秘密へのパイプラインは、従来のセキュリティ思考における重大な欠陥を浮き彫りにします。開発者は、コードだけでなく、付随するすべてのドキュメントを含む包括的なセキュリティレビューを実施する必要があります。これらの脆弱性の広範な影響については、[AI Secret Leaks in Public Code Repos: Warning to Developers | Wiz Blog]のような洞察を探求してください。
コードとドキュメントの相互作用を無視することは、データ流出のための広範な開かれた経路を残します。AIは見たものを記憶します。ドキュメントは、攻撃者が無害な出力を実行可能な秘密に翻訳するためのRosetta Stoneを提供します。
あなたの古い習慣が今や負債となる理由
AIエージェントの時代において、古い開発者の習慣は重大なセキュリティリスクをもたらしています。何十年もの間、エンジニアはデバッグの基礎として詳細なロギングに依存してきました。従来のモノリシックまたはマイクロサービスアプリケーションでは、`print`ステートメントや`console.log`は出力をプライベートな内部ログファイルに送っていました。これらのログへのアクセスは厳しく管理され、多くの場合、セキュアなシステムと監視ツールを通じて許可された担当者に限定されていました。これらのログは、エンドユーザーや公共のインターネットから安全に隔離された、貴重な診断ツールとして機能していました。
AI agentシステムは、この確立されたセキュリティ境界を根本的に破壊します。AI modelのcontext windowは、本番コードの出力と開発者の一時的なデバッグステートメントを区別しません。ログが一時的であるか安全に保存される従来のアプリケーションとは異なり、agent frameworkの標準出力はキャプチャされ、modelのcontextに直接渡されます。これは、AIがあらゆる情報を積極的に「記憶」し、繰り返すことができることを意味し、プライベートなメモを潜在的な公開情報に変えてしまいます。
研究者たちは厳しい現実を明らかにしました。監査された17,000のToolsから漏洩した520の実際のsecretsのうち、73%以上が、一見無害に見えるこれらの`print`ステートメントに直接起因していました。かつては内部診断だったものが、今やAIのアクティブメモリの一部となり、agentと対話する誰でも呼び出すことができるようになります。スキルがtokenをロードし、デバッグのためにそれをプリントし、そのsecretがagentのcontext windowに残るというこのメカニズムは、深刻な脆弱性を浮き彫りにしています。
これは、開発者のメンタルモデルに深い変化を要求します。長年のソフトウェア開発で染み付いたログのプライバシーに対する暗黙の信頼は、AI agentsを構築する際には適用されません。開発者は、迅速な検査のために機密データをプリントするという反射的な習慣を捨て、そのような出力が公開モデルに直接供給されることを理解しなければなりません。一時的なデバッグ行は無害であるという仮定は、すぐに負債となります。
結果として、かつては迅速なデバッグのためのベストプラクティスと見なされていた、広範で編集されていないロギングは、急速に重大なアンチパターンへと進化しました。以前のパラダイムでデバッグ性を高めていたまさにその手法が、今や明白な脆弱性を生み出しています。プリントされるすべての行、ログに記録されるすべての一時変数には、API keys、OAuth tokens、database passwordsなどの重要なデータを漏洩させる即座の可能性があります。これは、AI engineersの全世代にとって「安全なデバッグ」の意味を再定義し、すべてのロギング戦略の即時かつ緊急な再評価を強いるものです。
コードを強化する:3つのステップで修正
- 開発者は、ロギングの慣行を根本的に見直し、厳格な新しい黄金律を採用する必要があります:決してsecretsをプリントしないこと。17,000を超えるAI agent skillsの監査により、secretsが漏洩したインシデントの73%以上が、`print`ステートメントや`console.log`のような単純なデバッグプリントに直接起因していることが明らかになりました。これらの出力は単なる一時的なコンソールメッセージではありません。AI modelのcontext windowがそれらを即座にキャプチャし、永続的なメモリの一部とし、要求に応じて簡単に取得できるようにします。代わりに、堅牢な編集機能を提供する専用のセキュアロガーを使用してください。これらのツールは、API keys、OAuth tokens、database passwordsなどの機密データがログストリーム、AI modelのcontext、または外部システムに到達する前に、自動的に識別してマスクします。このプロアクティブなアプローチにより、コードの最初の行から意図しない漏洩を防ぎます。
- 次に、開発ライフサイクル全体を通じて、自動化されたシークレットスキャンを早期かつ頻繁に実装します。pre-publish および pre-commit スキャンを、継続的インテグレーション/継続的デプロイメント (CI/CD) パイプラインおよびバージョン管理ワークフローに直接統合します。この重要なステップにより、認証情報がローカルマシンから離れる前、またはリモートリポジトリにプッシュされる前に、誤って含まれるのを捕捉します。GitGuardian や TruffleHog のようなツールは、ハードコードされたAPIキー、トークン、データベース認証情報、その他の機密情報について、コードベース全体、コミット履歴、および構成を自律的にスキャンすることに優れています。これらは潜在的な漏洩を検出し、デプロイ前に修正を強制し、人為的ミスに対する不可欠な自動安全網を提供し、研究者が特定したまさにその脆弱性から保護します。
- 最後に、ソースコードとドキュメントの両方を包括的に組み合わせたレビューを義務付けることで、コードレビュープロセスを向上させます。すべてのプルリクエストとピアレビューにおいて、コードとREADMEを一緒にレビューすることを必須とします。この慣行は、コードの実装詳細と並行してREADMEの記述的コンテキストを読んだときに初めて、シークレットの真の重要性、あるいはその存在自体が明らかになるという種類の脆弱性である、陰湿な「クロスモデル」漏洩に直接対処します。この全体的なアプローチがなければ、レビュー担当者がパズルの1つのピースしか調べていないため、AIのコンテキストにシークレットが残り続けるという、重大な脆弱性が明白な場所に隠れたままになる可能性があります。この統合されたレビューは、より徹底したセキュリティ体制を保証します。
print文を超えて
監査された17,000のAIエージェントスキルで研究者が発見した漏洩の73%以上が`print`および`console.log`ステートメントによるものでしたが、脅威の状況は単純なデバッグ出力にとどまりません。開発者は、他のベクトルも積極的に機密情報を漏洩させるため、AIのコンテキストウィンドウに入るすべてのデータポイントを精査する必要があります。静かな侵害は多面的であり、包括的なセキュリティ体制が求められます。
例えば、冗長なエラーメッセージは、しばしば見過ごされがちな重大なリスクをもたらします。完全なスタックトレースは、データベース接続文字列、認証トークン、APIエンドポイント、あるいはシークレットの場所を示唆する環境変数名など、複雑な内部動作を一般的に公開します。開発者は、トラブルシューティングのためにこれらの包括的な詳細をキャプチャするようにロギングを頻繁に構成しますが、意図せずAIモデルの永続メモリにアクセス可能にしてしまいます。この慣行は、従来のアプリケーションのデバッグには役立ちますが、AIエージェントシステムでは重大な脆弱性となります。
サニタイズされていないユーザー入力は、もう一つの陰湿な脆弱性を表します。悪意のあるアクターは、冗長なロギングやエラー条件をトリガーするように特別に設計された入力を作成し、システムを騙して内部状態や構成の詳細を出力させることを目的とします。この形式のプロンプトインジェクションは、AIの即時応答を操作するだけでなく、ロギングパイプライン自体を武器化し、隠されるべき情報を抽出することができます。特定のモジュールをクラッシュさせ、その後のエラーログでロードされたシークレットを明らかにするように設計された入力を想像してみてください。
さらに、サードパーティライブラリと依存関係は、複雑さと潜在的な侵害の全く新しい層をもたらします。これらの外部コンポーネントは、徹底的なセキュリティ監査なしに統合されることが多く、独自のロギングメカニズムを採用していることが頻繁にあり、それが厳格なセキュリティ標準に準拠していない場合があります。無害に見える依存関係が、開発者の知らないうちに機密データをログに記録し、無意識のうちにAIのコンテキストに渡してしまう可能性があります。このサプライチェーンリスクは、厳重に保護されたファーストパーティコードであっても、その依存関係が同様に堅牢でない場合、脆弱なままであることを意味します。AIコーディングツール自体がどのように情報漏洩に寄与するかを含む、これらの蔓延する問題の詳細については、AIコーディングツールに潜む次なる秘密漏洩 - DevOps.comをお読みください。AIエージェントの保護には、表面的な修正を超え、深いアーキテクチャの認識と継続的な警戒へと移行する、ホリスティックなアプローチが求められます。
ハッキング不可能なAIエージェントの構築
AIエージェントの時代は、セキュリティパラダイムの完全な再評価を要求します。従来のソフトウェア開発において無害なデバッグと見なされていたものが、今や重大な脆弱性を引き起こしています。これは、監査された17,000のツールの中から、研究者が520のAIエージェントスキルが秘密を漏洩していることを発見したことからも明らかです。我々は、事後的な修正を超え、根本からプロアクティブでセキュリティ第一の哲学を受け入れる必要があります。
将来のAIエージェントフレームワークは、出力を後回しにすることはできません。自動出力サニタイズを備えたフレームワークを想像してみてください。機密情報がモデルのコンテキストウィンドウに入る前に動的に編集するものです。実装には、組み込みの秘密検出と難読化が含まれる可能性があり、これにより、単純なデバッグプリントが本質的に安全になり、それに起因する漏洩の73%を排除できます。
開発者は、デフォルトで安全なコーディングプラクティスを強制する堅牢な統合ツールを必要としています。これは、必須の秘密管理APIやコンテキスト認識型ロギングユーティリティなど、標準化されたセキュリティ機能をコアのAIエージェントSDK内に直接組み込むことを要求します。そのような機能は、安全なハンドリングの複雑さを抽象化し、開発者が重要なAPIキーやデータベースパスワードを誤って公開することがないようにします。
開発者教育における根本的な転換も同様に重要です。大学のカリキュラムやブートキャンプは、高度な選択科目としてではなく、初日からAI固有のセキュリティ原則を統合する必要があります。トレーニングでは、AIコンテキストウィンドウの固有のリスクと、一見無害に見えるデバッグステートメントの重大な影響を強調すべきです。AIの「メモリ」が永続的な攻撃対象であることを理解することが最も重要です。
この課題は、個々の開発者や特定のフレームワークを超越します。真にハッキング不可能なAIエージェントエコシステムを構築するには、業界全体での協力が必要です。フレームワーク作成者、ツールベンダー、オープンソース貢献者は、新しいセキュリティ標準、共有されたベストプラクティス、および堅牢な検証メカニズムについて協力する必要があります。
この進化する状況において、すべての開発者が重要な責任を負っています。秘密をプリントアウトするのを、今すぐやめてください。ログの編集を採用し、公開前スキャンを実行し、`readme`とコードを一緒に綿密にレビューしてください。セキュリティ・バイ・デザインへの統一されたコミットメントを通じてのみ、人工知能の信頼できる回復力のある未来を築くことができます。
よくある質問
AIエージェントの秘密漏洩とは何ですか?
AIエージェントの秘密漏洩は、APIキー、パスワード、トークンなどの機密情報が、エージェントの通常の操作を通じて意図せず公開されるときに発生します。多くの場合、AIモデルのコンテキストウィンドウに捕捉されることによってです。
デバッグプリントはなぜAIエージェントで漏洩を引き起こすのですか?
AIエージェントフレームワークでは、標準出力(「print」や「console.log」から)が情報としてAIのコンテキストウィンドウに直接供給されることがよくあります。開発者がデバッグのために秘密情報を出力すると、AIはそれを「記憶」し、後でユーザーに繰り返す可能性があります。
私のAIエージェントが秘密情報を漏洩するのを防ぐにはどうすればよいですか?
標準出力に秘密情報を絶対に出力しないでください。編集機能を備えたセキュアなロギングを使用し、コード内の秘密情報について公開前の自動スキャンを実行し、潜在的な漏洩箇所を特定するために常にコードとドキュメントを一緒にレビューしてください。