AlterがAIエージェントに「自分の鍵」を渡す、共有APIキー時代の終焉
Launch HN: Alter (YC S25) – Access control for multi-user agents
YC S25のAlterは、複数のAIエージェントが同じ過剰な権限のAPIキーを共有する現状を、エージェントごとのIDとスコープ付きグラントで置き換える。SDK1回の呼び出しで認証・認可・監査を処理し、140の連携先に対応。デフォルト拒否のポリシーと人間の承認、即時の失効、SIEMへの監査ログ送信を備え、顧客のセキュリティ審査に応えられる基盤を目指す。
エージェントにはあなたの鍵ではなく、エージェント自身の鍵を渡そう。
HNでの議論
16- mauvehed
あのウェブサイトは文字通りバイブコーディングされたテンプレートだよ…どうやってアプリ自体を信頼できるっていうんだ？
- 911viper
ここでsouvik1997と同じ流れに乗ると：リーク問題は共有セッションよりも共有ルームの方が悪化する。複数のプリンシパル（人間とそれぞれのエージェント）が1つのチャネルに座ると、トランスクリプトが特権境界になる。エージェントが高特権のターンで読んだものは、そのルームの以降のすべてのターンのコンテキストに残る。
まさにそれを構築する際にぶつかった問題は、人間とボットが対等なルームでは、トークンをエージェントにスコープするのではなく、(エージェント, ルーム)のペアにスコープし、その上で派生アーティファクトをどうするかを決めなければならないということだ。ツール出力、ファイルハンドル、エージェントが書き戻すメモリブロブはすべてセッションを超えて存続し、次のセッションに再生される。
それで、派生状態はどう扱っているの？エージェントメモリは、それを供給したセッションの権限の交差を持つ新しいプリンシパルなのか、それとも単に継承して、モデルが古いコンテキストに基づいて行動しないことに頼っているのか？
- souvik1997
かっこいいね！
マルチユーザーエージェントのセキュリティで、あまり探求されていないと思う側面の一つは、高特権セッションのコンテキストが低特権セッションに「リーク」する可能性だ。例えば、会社のCEOがあなたの共有openclawエージェントを使い、エージェントが機密データ（例えば投資家へのメール）をメモリに書き込むとする。私の理解では、これはAlterでは保護されていない。そして、契約者が同じエージェントを使い、同じメモリを読める。この種のマルチユーザーユースケースには、より良いエージェントハーネスが必要だと思う。openclawやclaude codeのような標準的なものは、単にそのために設計されていない。ぜひ意見を聞きたい！