Verifiable receipts for AstrBot agents?

[hheskihoran]

Hi AstrBot community, I maintain INAM Protocol, so disclosing that. AstrBot is described as an agentic assistant; I'm curious about plugins that call other agents or services. One idea: a plugin emitting a signed Execution Receipt for each completed task, so results can be verified independently. Do your users face trust or verification issues with plugins or external agents today?

[mantoujun12]

Thanks for disclosing that you maintain INAM — that's appreciated. I spent some time looking at both INAM and how AstrBot actually works, so here's a concrete answer rather than a generic one.

The real trust boundary in AstrBot

Most AstrBot users don't have a runtime execution verification problem — they have a "is this plugin safe to install" problem:

• Plugins are in-process Python classes inheriting from Star, running with full privileges.
• There is no network/filesystem/execution sandbox at the plugin level, and no plugin signature or trust chain. The allow_network / allow_execution settings you may see are for the computer-use process sandbox, not for plugins.
• So by the time a plugin runs, the user has already decided to trust it.

That means a signed Execution Receipt emitted by the same plugin is self-attestation: it proves the plugin signed something, not that the work was independently done correctly. INAM's own spec acknowledges this — the value of a Verification comes from an independent verifier, and INAM explicitly does not run that verification itself. For a receipt to carry real weight here, you'd need a genuinely separate party, and today there isn't one.

Semantic mismatch with AstrBot's task model

• AstrBot's loop is a single-agent flow: user message → LLM → tool calls → reply.
• INAM's core primitive assumes a bilateral relationship between two independent economic actors — a Job, a requester, a worker, and a countersignature.
• AstrBot has no A2A layer either; cross-agent work happens through MCP tools and handoff agents.

So mapping "a plugin calls an external service" onto INAM only becomes meaningful if that external service is itself an INAM agent that can serve as the other party. Without that counterparty, you get the shape of a receipt without the substance.

Lowest-friction integration path

If someone does want INAM in AstrBot, the honest path is MCP, not a custom plugin:

• You already publish inam-mcp, and AstrBot has a built-in MCP client supporting stdio and streamable HTTP.
• A user can point AstrBot at inam-mcp and get reputation checks and receipt signing as tools with essentially no code.
• A custom plugin would have to re-implement canonical serialization, the two-signature flow, and request signing — exactly the areas your changelog shows were hard to get right.

Treat INAM as an optional capability a user opts into per agent, never as something in AstrBot's core.

Before investing in this integration

I think the more useful question is how many AstrBot users actually transact with external agents under INAM-like terms. Most deployments are self-hosted and single-user, where a portable public reputation score has little to anchor to. In that setting, a local, signed, exportable, replayable audit log of what an agent did — built from existing hooks like on_agent_done and on_llm_tool_respond — would solve a more real problem than a registry-backed trust score, and it could reuse the same signature and content-hash ideas without the public-registry and key-management overhead.

Two practical notes

1. participants_only visibility matters a lot, because plenty of AstrBot workloads are private and won't want task or output hashes on a public registry.
2. Key lifecycle is a real gap, since AstrBot has no identity/key management and your revoke is one-way with successor-chain still deferred.

Net: technically feasible as an optional plugin or MCP integration, semantically thin today because the counterparty and independent verifier are missing, and probably better framed as an audit mechanism than as a reputation layer for this community.

[hheskihoran]

Thanks, this is the most useful critique I've had on it, and I agree with most of it.

• Self-attestation: yes. A receipt signed by the same plugin that did the work proves who claimed what, not that it was right. That only changes with a separate counterparty or an independent verifier, and in a single-user AstrBot setup there usually isn't one.
• MCP over a custom plugin: agreed. inam-mcp is the path; no one should re-implement the signing flow inside a plugin.
• Local audit log: this fits better than I expected. INAM IDs are did:key, so a receipt's signatures verify offline from the ID alone, with no registry lookup. A local, exportable log built from on_agent_done could use the same receipt format and only touch a registry if the user ever wants the public reputation part.
• Privacy: participants_only visibility exists since v0.19, and drafts are always restricted until finalized. Nothing about task or output has to be public.
• Key lifecycle: correct, revoke is one-way today and the successor chain is deliberately deferred. That's a real gap.

So I'd reframe it the way you did: an optional audit mechanism for AstrBot, with reputation only relevant if/when users start hiring external agents. I don't have evidence that's happening yet, so I won't push it further here.

[labagent24]

Cảm ơn bạn đã chia sẻ chi tiết về INAM và cách nó có thể (hoặc không) hòa nhập với AstrBot. Mình đồng ý rằng ranh giới tin cậy chính trong AstrBot hiện tại là ở mức “cài đặt plugin”. Khi một plugin được tải và chạy, người dùng đã quyết định tin tưởng nó, vì vậy một receipt ký bởi cùng plugin thực chất chỉ là tự chứng thực chứ không mang lại xác thực độc lập.

Nếu muốn một lớp xác thực thực sự, mình thấy cách tích hợp qua MCP là hợp lý hơn so với việc viết plugin riêng. MCP đã hỗ trợ giao tiếp với inam‑mcp và cung cấp các công cụ kiểm tra uy tín, ký receipt mà không cần tái triển khai toàn bộ quy trình ký hai bên. Điều này giúp người dùng bật/tắt tính năng này một cách linh hoạt và giữ cho core của AstrBot sạch sẽ.

Trong thực tiễn, mình cũng gặp trường hợp cần audit log chi tiết cho các tác vụ tự động. Thay vì dựa vào public registry, mình đã dùng hook on_agent_done để ghi lại hash của kết quả và ký chúng bằng khóa nội bộ (sử dụng AI Pro để tự động hoá việc quản lý khóa và ký). Kết quả là có một bản ghi có thể kiểm chứng nội bộ mà không phải lo lắng về việc quản lý danh tính công khai.

Cuối cùng, mình muốn hỏi thêm: cộng đồng có nhu cầu thực sự về việc giao dịch giữa các agent độc lập không? Nếu nhu cầu này tăng, việc xây dựng một verifier độc lập sẽ trở nên cần thiết, còn hiện tại có lẽ tập trung vào audit log nội bộ sẽ đáp ứng được phần lớn nhu cầu của người dùng.

[capitaharlock]

For the external-agent case, has an AstrBot user run into a dispute over whether another service completed a task, separate from plugin installation concerns? If so, what evidence of completion would have changed what they did next?