Agent Beacon：分散した AI agent の実行記録を audit 可能な local telemetry に残す

AI agent が command を実行し、file を変更し、CI を回すようになると、困るのは「できるか」だけではない。後から、その agent が何をしたのかを再構成できるかが重要になる。一つの session でどんな prompt があり、どの command がどの file を変え、なぜ approval が通ったのか。こうした情報は CLI、editor、browser、CI log に分かれがちだ。chat record だけでは audit しにくく、同じ machine の複数 agent の行動を比較するのも難しい。

今日見るのは Asymptote-Labs/agent-beacon。AI agent 向けの open-source telemetry layer で、agent が実際に動く場所で execution trace を集め、session、prompt、tool、command、file、approval、token などの event を統一 schema に整える。open-source mode では durable JSONL と read-only dashboard を default で local に残す。必要になれば、同じ log を自分で管理する SIEM、observability platform、object storage に forward できる。

GitHub repository、README、LICENSE、main branch の commit API、Releases API を 2026-09-15 18:04 Asia/Shanghai 時点で確認すると、Asymptote-Labs/agent-beacon は 448 stars、36 forks。主要 language は Go、license は MIT。repository は 2026-05-12 02:49:33 UTC に作成され、latest push は 2026-09-15 07:29:50 UTC。最新 main commit は 38aca147、commit time は 2026-09-15 07:29:50 UTC、title は Add trust command to brew installation (#508) で、Homebrew install guide の更新だ。最新 GitHub Release は v1.3.10、published at は 2026-09-12 17:49:58 UTC だ。

プロジェクト概要

項目	内容
リポジトリ	Asymptote-Labs/agent-beacon
位置づけ	local、browser、CI、cloud をまたぐ AI agent の統一 telemetry layer
Stars / Forks	448 / 36
主要 language	Go
ライセンス	MIT
作成日	2026-05-12 02:49:33 UTC
Latest push	2026-09-15 07:29:50 UTC
最新 commit	38aca147、`Add trust command to brew installation (#508)`
最新 Release	v1.3.10、2026-09-12 17:49:58 UTC
Install の入口	`brew trust asymptote-labs/tap && brew tap asymptote-labs/tap && brew install beacon`
開始の入口	`beacon endpoint install`、続いて `beacon endpoint dashboard`

解決するのは agent 行動の「パズル問題」

Agent Beacon の中心は、もう一つの chat UI を作ることではなく、observability の穴を埋めることだ。README の統一 event model には session、prompt、tool call、command、file change、approval、token が入る。24 の local agent runtime に加え、browser chat、CI、cloud agent、SDK instrumentation を扱う。このため「この変更は誰が、どの runtime で、どの tool を通して行ったのか」を調べるとき、四つも五つもある log を先に手で合わせなくてよい。

特に大事なのは default の境界だ。open-source mode では log は local JSONL に書かれ、dashboard も read-only の local UI で、account、API key、network は要らない。自分の machine 上の Codex、Claude Code、Cursor、ほかの agent が実際にどの操作をするかをまず知りたい人には、最初から prompt や command stream 全体を hosted platform に預けるより受け入れやすい。README は、同じ log を user control のもとで SIEM、logging platform、object storage に forward できるとも説明している。local-first は既存の observability stack と切り離すことを意味しない。

一台の開発 machine から確かめる

README にある macOS/Linux の入口は短い。Homebrew tap を install して beacon を入れ、beacon endpoint install で local runtime を endpoint に向け、dashboard で event を見る。

brew trust asymptote-labs/tap
brew tap asymptote-labs/tap
brew install beacon

beacon endpoint install
beacon endpoint dashboard

event は default で ~/.beacon/endpoint/logs/runtime.jsonl に入る。実際の試し方としては、まず production ではない開発 machine で、普段使う一種類の agent だけを接続する。明確な code-change と test workflow を数回動かし、session、command、file、approval が日常の調査に十分答えられるかを見直す。その後に event volume、field、retention を確認してから、JSONL を既存の security / observability pipeline に渡すのがよい。

Offline scan は replay 以外にも使える

project は beacon scan も提供し、open Threat Rules を local log に network なしで実行できる。AI agent の risk は model が間違えることだけではない。prompt injection の後に何の command が動いたか、ある tool がなぜ触るべきでない path に access したか、review step が bypass されなかったかも問題になる。構造化 event が context の安全性を自動判定するわけではないが、local detection と事後 analysis に terminal scrollback より安定した input を用意できる。

最新の v1.3.10 は Goose harness name と hooks event mapping の調整、CLI install と threat-rule 利用例などを含む。これは collection surface がまだ速く広がっていることも示す。runtime ごとの event の完全さは同じとは限らない。導入前には、実際に使う harness でどの field が取れるかを確かめ、support list だけで全ての command、file、token が出ると仮定しない方がよい。

使う前に data boundary を決める

local-first でも log が無害になるわけではない。prompt、command、file path、approval record には customer information、secret の手掛かり、internal project name が入る可能性がある。collection scope と retention を先に review し、JSONL への local access を制限し、team の security review を通した field だけを forward したい。複数 device や organization に広げるなら、MDM、SIEM connector、permission model も追加で評価する必要がある。single-machine quickstart をそのまま enterprise solution と見なすべきではない。

個人開発 machine の複数 agent に「行動の足跡を残し、戻って見られる」ことが欲しいなら、Agent Beacon は一台の test machine で先に動かす価値がある。単一 agent の簡単な run log だけが必要なら、今使っている harness の built-in record で足りるかもしれない。価値があるのは agent activity を audit、detection、forward ができる engineering data にし、孤立した chat record にしない点だ。

まとめ

Agent Beacon は「agent が実際に何をしたか」を各 tool の black box から出し、一つの event stream にする。local JSONL、read-only dashboard、offline rule scan、必要時の forwarding という組み合わせは、まず一台の開発 machine で observability baseline を作り、その後に team-level の security と telemetry に進むために合っている。

プロジェクト: https://github.com/Asymptote-Labs/agent-beacon