Jitpass、コーディングエージェント向けにMacの開発者シークレットをTouch IDで保護

Why it matters

Coding agents can read the same local credential files as developers. Jitpass secures that endpoint without requiring teams to rebuild every command-line workflow.

Meni Tasa (@menitasa) は、開発者のMacに散在する認証情報のためのセキュリティ層を構築している: Jitpass、および jit の作成者である Jitpass はプレーンテキストのシークレットを見つけ、それらを暗号化されたローカルボルトに移動し、承認されたプロセスが必要とする場合にのみ各値をリリースする。

このプロジェクトは、コーディングエージェントが開発者のファイルやシェルへの広範なアクセス権を獲得するにつれて無視しづらくなった古いセキュリティ上の弱点に取り組んでいる。APIキーやクラウド認証情報は依然として .env ファイル、シェル履歴、AWS 設定、.npmrc ファイル、MCP サーバー設定などに残されている。開発者アカウントで実行される任意のプログラムは通常それらを読み取ることができる。AIエージェントはそれらの値をトランスクリプト、ログ、またはリモートモデルへのリクエストにコピーすることもできる。

Tasa の答えは、そこにあることを期待するツールを壊すことなく、ファイルから実際の認証情報を取り除くことだ。Jitpass は露出した値をデコイ、検閲、またはフックに置き換え、Touch ID のプロンプトの後に承認されたプロセスに本当のシークレットを注入する。公開リポジトリ は 2026年8月15日時点で活発に開発されており、GitHub 上で 587 件のコミットがリストされている。

Tasa は自身を 公的な経歴 の中で、ネットワーク、IT、セキュリティにまたがる10年以上の経験を持つサイバーセキュリティ運用のリーダーと説明している。彼はまた、攻撃者の手法や実用的な防御を扱う教育的取り組みである CyberBrief Project を創設した。その運用的な背景は jit の設計に表れている: このユーティリティは、すべてのシークレットが中央管理されたボールトに既に存在することを前提にするのではなく、実際の開発者が実際に認証情報を残す混沌とした場所を中心に構築されている。

ワークフローを変えずにファイルを置き換える

Jitpass はクリーンアップを主に3つのアクションに分ける。jit scan はユーザーのホームディレクトリを検索して露出した認証情報を見つけるが、ファイルを変更したりシークレットの値を出力したりはしない。jit migrate はサポートされている認証情報をボルトに移動し、元の場所を書き換える。jit run -- <command> は他のソフトウェアにはデコイを見せたまま、選択された値を1つのプロセスに提供する。

サポート対象 には .env ファイル、シェルの export と履歴、AWS と Terraform の認証情報、Kubernetes の設定、Docker レジストリのログイン、Google Cloud application-default credentials、.npmrc、.netrc、および MCP の設定が含まれる。Jitpass はまた GitHub CLI、Stripe、Vercel、Claude、Codex、Gemini、Cursor Agent などのコマンドラインツール用のラッパーを文書化している。

一部の統合は認証情報を直接リクエストできる。AWS はその credential_process メカニズムを使用でき、Docker は credential helper を使用できる。ファイルを読むことしか知らないツールは jit run の下で実行でき、そのプロセスの環境に必要な値を配置する。Jitpass は成功した読み取り、拒否された要求、アンロックをローカル監査ログに記録する。

ボルト自体は Mac 上にとどまる。jit の security architecture によれば、各シークレットは個別に暗号化されたファイルとして保存され、個別のデータキーが macOS のログイン Keychain に保持されるマスターキーでラップされる。Touch ID またはデバイスのパスコードがアクセスの門を管理する。Jitpass はボルトが同期しないこと、また製品にアカウントやテレメトリが不要であると述べている。

コーディングエージェントがより鋭いエンドポイントの問題を作った

Jitpass の最も時宜を得たユースケースは、開発者自身の権限で実行されるコーディングエージェントだ。オペレーティングシステムはそのエージェントを別のローカルプロセスとして扱う。もしそのプロセスが .env を開くと、ファイルは通常、開発者のアプリケーションに返されるのと同様に本番キーを返す。

Jitpass のエージェント設計 は、休止状態で利用可能な内容を変更する。エージェントがファイルを開くとデコイが返される。エージェントが gh や terraform のようなラップされたコマンドを呼び出すと、jit は承認後にその特定のコマンドに認証情報を提供できる。本当の値は、開発者がそれを出力するプロセスを明示的に許可した場合にはエージェントのトランスクリプトに入る可能性があり、これは jitpass が排除を主張するのではなく文書化している境界だ。

長時間稼働するエージェントはもう一つの問題を生む。画面がロックされた後に生体認証のプロンプトに答える人が誰もいないからだ。Jitpass は事前に開発者が承認する時間制限付きのプロセス許可をサポートする。jit grant --process claude --profile deploy --for 8h のようなコマンドは、特定のターミナルセッションから派生するプロセスに対して名前付きシークレットを認可できる。各使用は監査トレイルで可視化され、許可は期限切れになったり取り消したりできる。

このエンドポイント重視は、既存のシークレットベンダーによるより大きな取り組みのそばに jitpass を置く。1Password expanded runtime access は 2026年2月にローカルツール、CI システム、AI 支援開発のためのランタイムアクセスを拡張した。その Developer Watchtower はプレーンテキストの .env 認証情報を特定し、それらを 1Password Environments に移動できる。同社の Credential Broker は 6月に導入され、7月にパブリックプレビューに移行し、GitHub Actions のようなシステム向けのワークロードアイデンティティとスコープ付き認証情報配信をターゲットにしている。

Jitpass はより狭い切り口を追求している。まず一人の開発者の Mac に既に散在している認証情報から始め、それを露出させたコマンドやファイルフォーマットを維持しようとする。ローカルボルトとプロセスレベルのプロンプトは、セットアップや管理の表面積を減らす一方で、より大規模な製品が提供する共有コントロール、クロスプラットフォームサポート、組織全体のガバナンスを放棄している。

セキュリティ境界は意図的に狭く保たれる

Jitpass は、侵害されたユーザーアカウントを安全にするとは主張していない。ドキュメントには、プロセスが一度シークレットを受け取るとその後は何でもできると書かれている。ユーティリティはまた、いくつかの AWS ロールや SSO キャッシュなど、別のツールが下流で作成するすべてのトークンを管理するわけでもない。

シェル履歴から認証情報を移行することはローテーションというよりクリーンアップだ。古いコピーはバックアップ、リポジトリ、または開いたシェルのメモリに残っている可能性がある。Jitpass はユーザーにそれらの認証情報をローテーションするよう警告している。シークレットを含むファイルが以前にコミットされていた場合、古い値は Git 履歴に残る。

現行のビルドは Apple Silicon 上の macOS に限定されており、まだ開発中と説明されている。Intel Mac ユーザーはソースからコンパイルできる。コードは公開されているが、jit は従来の許容的なオープンソースライセンスではなく PolyForm Perimeter License を使用している。リポジトリは個人用および社内使用を許可し、他の商用利用に対してはより厳格な管理を保持している。

その限定された範囲は製品の最も明確な規律でもある。Tasa は開発者のラップトップを自身のシークレット管理境界として扱っており、ローカルファイル、生体認証による承認、アクセスを要求するプロセスを中心にコントロールを構築している。AI コーディングツールはその境界をより忙しくし、検査を困難にした。Jitpass は、開発者がその後も同じコマンドを打ち続けられる限り、その境界を保護するだろうと賭けている。