Cryptographic owner
An optional NIP-OA attestation proves that an owner key authorized an agent key under stated conditions.
Agent governance
Block Buzz AI agent governance
Add business ownership, human approval, and audit evidence before Block Buzz agents deploy, send, spend, or change external systems.
Updated Aug 2, 2026
Block Buzz gives agents signed identities and a shared workspace. To govern external actions, connect those identities to Contro1 business owners, policies, and human reviewers. The connector verifies a signed action event, binds the decision to that stored action, and either returns the decision or calls a configured guarded webhook.
Key takeaways
- Connect Buzz agent identities to Contro1 business owners, reviewer roles, approval rules, and cross-system evidence.
- Use the gate before high-impact external actions such as deploy, send, spend, delete, access change, and protected webhooks.
- The developer signs the proposed action as a Buzz event and routes that signed submission through the connector instead of calling the destination directly.
- The human sees the action, target, environment, material parameters, policy reason, and deadline before deciding.
What is Block Buzz, and where does governance fit?
Block Buzz is an open-source, self-hostable workspace where humans and AI agents collaborate through channels, workflows, repositories, and signed Nostr events. Each agent can use its own cryptographic key instead of acting through a developer account or shared bot credential.
Buzz identifies who signed an event and controls participation inside its workspace. Governance adds the organizational decision that comes next: whether that agent may deploy, send, spend, delete, or change an external system, and which person or role must approve.
The connector is currently an integration preview. Automated tests pass, but it remains experimental until the live Buzz relay and Contro1 callback/restart matrix has completed.
Buzz README at the connector's verified commit · Contro1 agent identity and traceability
Does Buzz have agent permissions?
Yes, inside Buzz. Its documented model uses community and channel membership: a channel member can read and write the content available to that channel. That permission does not automatically authorize the same agent to deploy production code, send a customer message, spend company funds, or modify another external system.
Contro1 and the connector add a separate action boundary for those external side effects. The three layers complement one another, but they are not interchangeable.
| Layer | Current responsibility | What it does not imply |
|---|---|---|
| Buzz | Agent-native workspace, cryptographic identities, signed events, community and channel membership, and documented CLI and relay interfaces. | A valid Buzz signature does not grant authority to deploy, spend, modify an external system, or approve on behalf of a business role. |
| Contro1 | Agent registry, configured scope enforcement, human routing, roles, quorum, SLA and escalation, callbacks, and audit evidence. | Contro1 does not rotate a Buzz key, manage Buzz membership, or automatically discover every Buzz identity through its public agent API. |
| Connector | Verifies the signed Buzz action, resolves the identity binding, applies policy, creates review requests, binds decisions to stored action data, and optionally calls a configured guarded webhook. | The connector cannot govern an action that bypasses its gate or uses a destination credential held directly by the agent. |
Is a Buzz cryptographic owner the same as a business owner?
Buzz supports an optional NIP-OA owner attestation. When present and valid, it proves that one owner key authorized an agent key under the attestation's conditions. The event remains authored by the agent key. When the attestation is absent, the connector records the owner as unverified instead of inventing one.
A business owner is an organizational concept: the function accountable for the agent's operation and outcomes. A technical maintainer or cryptographic owner should not automatically become the finance, security, release, or customer-data approver.
Business owner
The accountable team or person responsible for the agent's business purpose, decisions, and operating scope.
Eligible reviewer
A role such as finance, security, or release management that is allowed to decide a specific action.
Buzz NIP-OA specification at the verified commit · Buzz authentication configuration at the verified commit
How does a Buzz action reach human review?
A Buzz workflow or tool adapter submits the proposed action as a signed Buzz event and receives pending immediately. The connector continues independently, so a human review does not hold the Buzz channel turn open.
-
1. Verify
Confirm the Buzz source
Verify the signed event and its bound organizational identity.
-
2. Classify
Apply the action policy
Stop, log, or send the action for human review.
-
3. Review
Route to accountable people
Use the required roles, quorum, deadline, and escalation path.
-
4. Match
Verify the approved action
Reload the stored action and confirm that it still matches.
-
5. Execute
Return or perform the approved outcome
Return the decision, or use the configured webhook to perform it.
How is approval bound to the exact action?
The developer places the target resource, environment, material parameters, and stable action ID inside a Buzz event and signs it. The connector verifies the event and derives the proposal only from that signed content, so a caller cannot attach different unsigned parameters later.
The connector stores the action and its digest before requesting review. A stable action ID identifies one proposed side effect across retries and must not be regenerated from the current time.
- Stable identity: relay origin, signed Buzz event ID, and action ID identify one proposed side effect across retries.
- Material action: type, resource, environment, and parameters are included in the stored digest.
- One request: retries reuse the original nonce, expiry, digest, gate, and Contro1 request.
- Final check: the connector reloads and re-hashes the stored proposal before the final decision outcome or configured execution.
Read the Contro1 Requests API documentation · Learn when AI agents should require approval
How do I add human approval before a Buzz agent deploys, sends, or spends?
Route the signed action through the connector instead of calling the destination directly. The connector applies your policy and sends review actions to eligible people. By default it returns the action-bound decision without executing; configure the fixed guarded webhook when the connector should perform the approved side effect.
Production releases
Bind review to the service, environment, release digest, and material deployment parameters.
Customer-facing communication
Review the destination, message or content reference, customer context, and policy reason before sending.
Purchases and refunds
Route higher amounts, new beneficiaries, refunds, or budget changes to finance and business owners.
Destructive or privileged actions
Require review for deletion, access changes, production configuration, and protected webhooks.
Approval infrastructure for AI agents · Human-in-the-loop approvals guide
How do I audit Buzz agent actions across systems?
The useful audit story is correlation, not copying every private Buzz conversation into another database. A governed action can connect the source Buzz event, normalized identity binding, policy result, Contro1 request, explicit human decision, stored action digest, and external execution result.
Contro1 can HMAC-sign callbacks and request evidence when the organization signing secret is configured. The connector adds the stored action digest and gate state, plus the execution status and external reference when an executor is configured.
The connector does not copy full Buzz conversations or automatically publish a custom receipt event. If your Buzz adapter posts a result, keep it to the decision status, request ID, shortened digest, execution state, and an authorized evidence reference.
Contro1 audit records and cases · Contro1 webhooks · What to log for AI agents in production
Can Contro1 block every Buzz action?
No. Contro1 can block protected requests and executions that pass through the connector. It cannot revoke a Buzz key, remove channel membership, or stop a direct external call that bypasses the gate. This boundary is why production credentials belong in the guarded executor rather than in the agent process.
| Situation | What is protected |
|---|---|
| Signed action sent through the connector | The connector verifies the event, resolves the bound agent, applies policy, stores the action, and enforces the resulting gate state. |
| Action sent to the configured webhook executor | The connector sends only the stored approved action to one fixed HTTPS endpoint and signs the request with HMAC. |
| Agent calls the destination directly | Not protected. The destination credential and network path must be kept away from the agent if the gate is meant to be mandatory. |
| Buzz channels, membership, and keys | Still controlled by Buzz. Contro1 does not replace Buzz workspace permissions or revoke its cryptographic identities. |
How do I start connecting Block Buzz to Contro1?
Start in decision-only mode with one harmless signed action and one policy. Bind the Buzz identity, send one review request, and confirm that approval returns an action-bound decision with execution_status not_executed.
The standalone repository ships the contro1-buzz CLI. Use doctor, bind, sign, gate, and status for the first test. Add serve for an HTTP adapter, and configure the fixed HTTPS webhook executor only when you are ready for the connector to perform the action.
- Bind one Buzz relay identity explicitly to one Contro1 agent record.
- Sign one harmless action and confirm the connector derives its parameters from the verified event content.
- Require an explicit human decision and inspect the final gate state and evidence.
- Retry the same signed submission and confirm it reuses the same gate and Contro1 request.
- Keep the real destination credential in the guarded webhook, not in the Buzz agent.
Open the Contro1 Buzz connector repository · Read the Contro1 CLI documentation
Frequently asked questions
Is the Contro1 connector for Block Buzz production-validated?
Not yet. Automated tests cover the connector behavior, but the live matrix against a real Buzz relay and Contro1 organization, including callbacks and restart recovery, has not completed. Treat it as an integration preview until that evidence is published.
What is Block Buzz?
Block Buzz is an open-source, self-hostable workspace where humans and AI agents collaborate using separate cryptographic identities and signed Nostr events. Its workspace and channel controls are distinct from authorization to perform side effects in external systems.
Does Buzz have agent permissions?
Yes. Buzz uses community and channel membership to control who can read and write workspace content. Authority to deploy, send, spend, delete, or modify another system is separate and must be enforced at that external action boundary.
Does Contro1 replace Buzz or Nostr identity?
No. Buzz remains the workspace and signed-event identity layer. The connector links a normalized Buzz relay origin and public key to a Contro1 organizational agent record.
Does the connector control every action a Buzz agent performs?
No. It controls only actions routed through its gate, proxy, CI job, or guarded executor. It cannot intercept direct external calls or arbitrary Buzz activity that bypasses that boundary.
How can I require approval before a Buzz agent deploys?
Sign the deployment action and route it through the connector instead of calling the deployment system directly. The connector requests review and returns an action-bound decision. Decision-only does not execute; configure the fixed guarded webhook when the connector should perform the approved deployment.
How do I audit Buzz agent actions across other systems?
Use the connector gate ID and correlation fields to join the source Buzz event, Contro1 agent and request, policy result, human decision, action digest, execution attempt, and external reference without copying the full Buzz conversation.
Is a Buzz NIP-OA owner the agent's business owner?
Not necessarily. NIP-OA is an optional cryptographic attestation between keys. A business owner is the organizational function accountable for the agent and should be assigned through the appropriate Contro1 administration process.
Is this a native Buzz ACP integration?
No. The connector is a separate bridge process. A Buzz or ACP adapter submits a proposal, receives pending immediately, releases the channel turn, and reads the final gate state later. The connector does not publish a custom Buzz reply event.
Does the connector read every Buzz message?
No. The connector reads only the source event and identity facts needed for an explicit binding or action gate. It does not continuously copy complete conversations.
Where can I find the Contro1 Buzz connector?
The public contro1-buzz-connector repository contains the TypeScript bridge, signed-action CLI, SQLite gate storage, policy examples, execution-mode documentation, tests, and security guidance.
Related resources
Agent identity, traceability & signed evidence
Give every agent a verified identity, scope its authority (least agency), reconstruct any run end-to-end (tools, sub-agents, retrieved context), and export HMAC-signed evidence.
Requests API reference for AI agent approvals
Learn how to create, inspect, and cancel Contro1 requests for approvals, clarifications, and escalations.
Audit records and cases for autonomous agent actions
Use Contro1 audit records to log actions that agents are authorized to run autonomously, and correlation_id to connect requests and logs into one case timeline.
Approval infrastructure for AI agents
A practical guide to approval infrastructure for AI agents: tool gates, permissions, audit, routing, and HITL that preserve autonomy without adding popups everywhere.
When should AI agents require approval?
A practical framework for deciding which AI agent actions need human approval - with concrete examples across support, finance, and ops.
What to log for AI agents in production
Track the events, decisions, and operational signals that matter when running AI agents in production.
What is human-in-the-loop for AI agents?
Learn when AI agents should require human approval, what actions should stay gated, and how to design HITL for production workflows.
Connect Block Buzz to Contro1
Give Block Buzz agents human approvals, role-based routing, safe retries, and a complete audit trail before high-impact actions run.
System of Record for AI Agents: Why Every Enterprise Needs One
Your ERP is the system of record for money and your CRM for customers. AI agents now take real business actions with no system of record at all. Here is what one must capture and how to stand it up fast.
How to choose the owner of an AI agent
A short practical guide for assigning an AI agent owner: who should be accountable, when a VP or department head should own it, and how to record fallback ownership.