Obsigna - AI agent の行動に検証可能な receipt を残す
AI agent は、filesystem、email、database、CI、internal tools に触れる場面が増えています。すると問題はかなり具体的になります。ある tool call は誰のために実行されたのか、何をしたのか、結果はどうだったのか、前後の記録とつながっているのか、あとから record が書き換えられていないことを確認できるのか。
今日紹介する agent-receipts/obsigna は、この領域を扱う project です。Agent Receipts protocol を中心に、signed receipt と chained records で AI agent の action を記述し、daemon、MCP proxy、Claude Code / agent runtime hook、CLI、Go / TypeScript / Python SDK を提供しています。大きな observability platform を置き換えるものではなく、agent behavior audit のための structured and verifiable layer と見る方が近いです。
公開時点の GitHub data では、約 20 stars、4 forks。主な言語は Go で、repository には Python と TypeScript SDK も含まれます。Repository は 2026-04-02 に作成され、最近の update は 2026-06-16。Main repository の license は Apache-2.0、protocol specification directory は MIT license です。Latest GitHub release は obsigna v0.25.0 で、公開日は 2026-06-13 です。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| Repository | agent-receipts/obsigna |
| 位置づけ | AI agent action の signed receipt と audit chain toolset |
| Stars | 約 20 |
| Forks | 約 4 |
| 主な言語 | Go |
| License | Apache-2.0。Protocol specification は MIT |
| Latest version | obsigna v0.25.0 |
”agent が何をしたか” を receipt にする
多くの agent log は plain text です。Tool name、parameters、output、timestamp は残ります。Debug には役立ちますが、security team、compliance process、downstream service に渡すには足りないことがあります。Record format は安定しているのか、action type は分類できるのか、record は署名されているのか、前後の event は audit chain として追えるのか。
Agent Receipts の approach は、ひとつの action を structured receipt として書くことです。Receipt には issuer、principal、action、outcome、sequence、chain id などを含め、signature と hash chain で検証可能な record にします。これは agent を絶対に信頼できる存在にする仕組みではありません。むしろ、あとから確認する対象をはっきりさせるためのものです。どの record、どの key、どの chain、どの action type、どの outcome なのかを分けて見られます。
Obsigna はこの protocol の reference implementation です。Repository には protocol spec と JSON schema だけでなく、application に embed できる SDK、agent runtime 周辺の tooling もあります。Engineering team にとっては、spec を読むだけより試しやすい。まず local で数件の receipt を作り、daemon や MCP proxy を real workflow に接続するか判断できます。
Tool layer が明確に分かれている
Obsigna repository の components は役割が分かれています。
obsigna-daemon は signing key を agent process の外に置き、daemon が key と audit chain を持つための component です。この design は重要です。Signing key が agent process 内にある場合、prompt injection や arbitrary code execution の影響を受けた agent は receipt を偽造できる可能性があります。Daemon がすべての threat を解くわけではありませんが、key custody を business code から切り離せます。
obsigna-mcp は MCP stdio proxy です。既存の MCP server を wrap し、tool call の周囲に signed receipt、policy hook、risk scoring を追加できます。すでに MCP を中心に agent tooling を組んでいる team には自然な接続点です。すべての tool server を改修する前に、proxy layer で tool call を記録できます。
obsigna-hook は Claude Code のような tool-use hook を持つ runtime 向けです。README の例では PostToolUse hook で tool call を自動記録し、CLI で audit chain を表示、検証します。この route は individual developer や small team が試すのに向いています。最初から platform 全体を作る必要はありません。
最後に obsigna CLI と Go / TypeScript / Python SDK があります。CLI は receipt database の browsing、show、verify に使えます。SDK は application が自分で receipt を作成し、署名するためのものです。Custom agent runtime、internal task runner、security gateway を持つ team では、proxy より SDK の方が柔軟です。
見るべき点は “signature” だけではない
Log に signature を付けること自体は新しくありません。Obsigna で見るべきなのは、agent scenario に必要な複数の dimension をまとめて model 化している点です。
まず、action type が単なる free text ではありません。README の example では filesystem.file.read のような action type、risk level、outcome status、chain sequence などが見えます。Classification が安定すれば、あとから action type を軸に policy、alert、audit query を作れます。Log string を keyword search するより扱いやすいです。
次に、deployment ごとの trust model を認めています。README の SDK quick start は、key を agent process 内に置く場合、その process で code execution できる人は receipt を偽造できる、と明記しています。Compromised agent に備えるには daemon-mediated path を使うべき、という境界も示しています。この明確さは、“signed log” を万能の security feature として売るより信頼できます。
さらに、MCP を first-class entry point として扱っています。今の agent tools は MCP 経由で公開されることが多いです。すべての MCP tool call が proxy layer で receipt を残せるなら、team は “agent がどの tool を呼んだか” を debug log から audit data に近づけられます。Email、ticket、cloud resource、production database に関わる tool では、この種の record は早い段階で必要になります。
向いている場面
Obsigna は low-risk workflow から試すのが良さそうです。
ひとつ目は local coding agent や internal agent runner です。まず file read、command execution、code edit、PR operation などを記録し、receipt が実際の workflow を表現できるかを見る。そのあと sensitive tools に広げるか決められます。
ふたつ目は、すでに MCP を使っている team です。MCP proxy で重要な server を 1 つか 2 つ wrap します。Issue tracker、deployment helper、database read-only tool などが候補です。Signed receipt が “どの agent call が何をしたか” の説明に役立つか観察できます。
三つ目は、agent platform、agent gateway、internal security audit を作っている team です。Tool ごとに private log format を増やすより、public protocol と cross-language SDK を評価し、receipt を event boundary として扱えるか検討できます。
一方で、これは full compliance platform ではありません。Repository が提供するのは protocol、tools、reference implementation であり、permission system、SIEM、approval flow、long-term archive、organization-level reporting のすべてではありません。Real deployment では key management、database permission、receipt retention、privacy field redaction、existing security system への連携を別途考える必要があります。
まとめ
agent-receipts/obsigna の方向性は実用的です。AI agent の capability が強くなるほど、重要な action は “console log” ではなく “verifiable record” として扱う必要が出てきます。Obsigna は receipt format、signature、chain structure、daemon、MCP proxy、多言語 SDK に分けて、この問題を試せる engineering components にしています。
特に良いのは、trust boundary を曖昧にしない点です。In-process SDK は素早い embed に向いていますが、compromised agent process に備えるなら daemon-mediated path が必要です。MCP proxy は低侵襲に接続できますが、より大きな policy and permission system の代わりにはなりません。AI agent を実際の toolchain に接続し始めている team にとって、Obsigna は早めに観察しておきたい小さな project です。