トークン・APIキー
トークンやAPIキーは、パスワードと同じ役割を持つ文字列です。仕組みを理解すると、「見せてはいけない」の範囲と理由が具体的に分かります。
文字列を持っていること自体が本人確認
多くのシステムは、利用者が誰かを毎回パスワードで確認する代わりに、確認が済んだ証として文字列（トークン）を発行します。以降はその文字列を提示するだけで、本人確認が済んだものとして扱われます。
つまりトークンやAPIキーは「その文字列を持っている者が本人である」という前提で成り立ちます。文字列が漏れた時点でこの前提は崩れ、拾った誰もがその持ち主として振る舞えます。有料APIのキーなら、他人の利用があなたの請求になります。データを読み書きできるキーなら、そのキーの権限の範囲すべてが読み書きされた前提で対応することになります。
漏れる経路
漏れ方には型があります。最も多いのはコードに直接書いてcommit（変更を履歴として記録する操作。バージョン管理）することで、後から消しても履歴から読み取れます。ブラウザで動くコードへの埋め込みは、開発者ツールを開けば誰でも読めるため、公開したのと同じです。ログやエラーメッセージへの出力は、エラー通知や収集サービスへ転送されて意図しない場所に残ります。そして、チャット、スクリーンショット、画面共有への映り込みは、コードの外側で起きる漏洩です。
環境変数で分離する理由
環境変数は、コードの外側、実行環境ごとに設定する値です。コードには「環境変数から読み込む」という処理だけを書き、値そのものを含めません。これにより、コードを共有・公開しても鍵は含まれず、開発環境と本番環境で別の鍵を使い分けられます（環境の分離）。
このAPIキーはコードに書かず、環境変数から読み込む形にして
公開してよいキーと秘密のキー
サービスによっては、ブラウザに埋め込む前提の公開可能なキー（publishable keyなど）と、サーバーの中だけで使う秘密のキーを分けて発行します。どちらか分からないキーは、秘密のキーとして扱います。
このキーはブラウザに置いてよい種類か、サーバー専用か調べて
権限を絞る
多くのサービスは、読み取り専用や特定の操作だけ、のように権限を絞ったキーを発行できます。全権限のキーを一つ発行して使い回すと、漏れた時の被害が最大になります。用途ごとにキーを分け、必要な権限だけを与えます。
漏れたと分かったら
該当のキーを無効化し、新しいキーを発行して差し替えます。無効化が最優先で、原因調査やコードの修正はその後です。無効化するまでの間、漏れたキーは有効なまま使われ続けられます。
過去のcommitも含めて、このリポジトリに秘密情報が残っていないか調べて