HN🔥 68
💬 27

AIエージェントのセキュリティに革命を:APIキーを.envに直書きしない「Kontext CLI」が登場

mc-serious
約2か月前

ディスカッション (11件)

0
mc-seriousOP👍 68
約2か月前

AIコーディングエージェントにGitHubやStripe、データベースなどの権限を与える際、長寿命なAPIキーを.envファイルやチャット画面にコピペしていませんか?私たちは、その「祈りながら実行する」しかない現状を打破するためにKontext CLIを開発しました。現在の課題は単なる秘密情報の散乱だけでなく、アクセス履歴が追えないことにあります。誰がどのエージェントを起動し、何にアクセスしたのか、そもそもそのアクセスは許可されるべきだったのかがブラックボックス化しています。認証情報をプロセスに直渡しすると、ポリシー適用や監査、安全なキーローテーションが不可能になります。自律型エージェントがセッションごとに何百回もAPIを叩く現代において、キーそのものが認証情報となってしまうのは根本的な欠陥です。Kontextのアプローチは違います。プロジェクトに必要な権限を.env.kontextファイルに宣言するだけです。GITHUB_TOKEN={{kontext:github}}STRIPE_KEY={{kontext:stripe}}LINEAR_TOKEN={{kontext:linear}}次に kontext start --agent claude を実行します。CLIはOIDC経由で認証を行い、プレースホルダを短寿命のアクセストークンに交換(OAuth対応の場合)するか、静的キーをエージェントのランタイム環境に直接注入します。いずれの場合も、シークレットはメモリ内のみで保持され、ディスクには一切書き込まれません。すべてのツールコールは監査のためにストリーミングされます。これはSTS(Security Token Service)に近い仕組みですが、さらに安全です。バックエンドがアップストリームのシークレットを厳重に管理し、CLIにはセッション単位の短寿命トークンしか渡さないため、長期的なリスクを排除できます。インストールは brew install kontext-dev/tap/kontext で完了します。Go言語製でオーバーヘッドは約5ms、ConnectRPCを採用し、認証情報はシステムキーリングに安全に保存されます。現在Claude Codeに対応しており、Codexサポートも近日予定しています。現在、AIエージェントの認証情報をどう管理していますか?単にenv変数をチャットに貼り付ける以上の「スマートな方法」があればぜひ教えてください。GitHub: https://github.com/kontext-dev/kontext-cli 公式サイト: https://kontext.security

1
amjd
約2か月前

ローンチおめでとう!OneCLI1と比べて、こっちの主なメリットは何?

3
airstrike
約2か月前

すごく良いし、まさに必要とされてたものだね!
実はちょうどRustでこれを書き始めようとしてたところだったんだ…

4
sarahroehm
約2か月前

ついに文脈依存の認証(Contextual Authorization)に焦点を当てたソリューションが出てきたか。エージェントがクレデンシャルを要求した時にその推論過程を評価して、意図がユーザーの許可範囲内と合致する場合のみ発行するっていう。開発者向けでセルフサーブだし、ローンチおめでとう!!

5
0xOsprey
約2か月前

ああ、自分のNanoClawでめちゃくちゃ必要としてたやつだ。ナイスワーク!

6
sjdv1982
約2か月前

もしkontextがClaudeと同じユーザー権限で実行されてたらどうなるの?理論上はkontextのプロセスをインスペクトして、メモリからキーを抜き取れるんじゃない?

7
measurablefunc
約2か月前

eBPFを使えば実現できるはず。ネットワークI/Oを監視して、リクエストをその場で書き換えて適切なトークンや署名を付与するんだ。エージェントにはプレースホルダーのトークンだけ渡しておけばいい。そうすれば通常のライブラリは期待通り動作するし、別の抽象化レイヤーを気にせず秘密情報や署名を扱える。先行事例としてこれがあるよ: https://riptides.io/blog/when-ebpf-isnt-enough-why-we-went-with-a-kernel-module/

8
zimbatm
約2か月前

キーチェーンっていうのは本来こうあるべきだよね。シークレットそのものを返すんじゃなくて、新しいトークンを発行したりリクエストに署名したりするっていう。
これ、開発環境とかリモートサーバーでコマンドを実行する時みたいな普通の用途でも必要だね。
OIDC非対応のサービスへのサポートは追加する予定?それともこれは仕様上の制限として残る感じかな?

9
e12e
約2か月前

静的なAPIキーについては、バックエンドが直接エージェントのランタイム環境にクレデンシャルを注入します。

それだと、エージェントがAPIキーを永続化したり流出させたり、あるいは環境変数から読み取ったりするのを何が防ぐの?

10
james-clef
約2か月前

すごくクールなプロジェクトだね。エージェントにクレデンシャルを提供して、そのプロセス全体を標準化するのは価値ある仕事だと思う。ちょっと質問なんだけど、OSSと有料版の境界線はどこ?OSSのCLIが有料サービスのクライアントになるのかな?あと、カストディモデルはどうなってる?このサービスは自分の全クレデンシャルを保存するの?