Team conversation is an authority boundary
Putting an AI agent in a community channel looks simple: watch for a mention, send the text to a model, and post the answer. The security problem begins when the message is allowed to decide more than the request.
A message can claim a user identity, name a workflow, mention another channel, or instruct the agent to take a consequential action. None of those claims should become authority merely because they arrived inside a signed event.
Punk’s Buzz Bridge separates conversation from authorization. It accepts verified ordinary Buzz kind-9 mentions into a tenant-scoped durable inbox, but derives the execution identity from a server-owned managed mapping. Event content and caller-supplied Punk identity headers do not select the tenant, app, agent, subject, workflow, role, or allowed actions.
That makes Buzz a human collaboration surface while Punk remains the governed runtime underneath it.
Managed mappings define who may ask for what
An operator begins with an existing Buzz community and relay. Punk does not create or host the community. The operator creates a dedicated service signer, admits its public key to Buzz, and stores the signer secret in Punk’s credential vault using the buzz-nostr provider.
Only after that provisioning boundary does Punk expose Buzz settings to a tenant-wide administrator. The operator can map:
- one expected community host and relay;
- a public service-signer identity;
- Buzz channels to Punk agents and workflows;
- actor public keys to stable Punk subjects;
- channel memberships to roles and exact allowed actions.
Mappings are immutable, versioned, and audited. Updates create a new version instead of overwriting the evidence that governed an earlier run. Signer rotation, disconnect, and revocation follow the same append-only model.
The mapping API accepts public keys and credential references, not private signer material. It rejects unknown fields, malformed identities, overlapping channel ownership, unbounded values, and secret-shaped fields. Current credentials must belong to the same tenant.
Signed messages still receive narrow permissions
A valid signature proves that a particular key created an event. It does not prove that the key may invoke every workflow or approve every action.
When Punk receives a mention, it checks the expected community, channel, actor, membership, role, action set, and mapping version. A member may have workflow.invoke without having execution_action.decide. An approver may be allowed to decide one governed action without gaining tenant-wide administration.
This distinction limits privilege escalation through conversation. The words “approve this payment” do not grant approval authority. Punk must match the signer and referenced request to the current mapping and exact allowed action.
Permission scope also becomes part of reuse safety. A route qualified for one channel and membership scope should not automatically serve another channel with different authority, even inside the same tenant.
Durable queues make the conversation inspectable
Accepted events enter a durable inbox before agent work begins. Punk records relay-event identity for deduplication, links the event to the selected workflow and run, and processes it through isolated Buzz workers.
The reply path is durable too. Terminal results enter an outbox and are signed and published by a separate publisher boundary. A successful conversation should produce one terminal reply linked to the exact Punk run rather than a stream of generic accepted or queued messages.
This design creates observable states between “message received” and “reply posted.” An operator can see queued work, oldest items, dead letters, last receipt time, last successful publication time, and bounded links to the workflow, run, receipt, and evidence.
Queue movement is not presented as proof that a relay subscriber or worker process is healthy. Explicit process health still requires a concrete deployment handshake. The dashboard reports unsupported health claims as not reported instead of inferring them from recent traffic.
Approval pauses at the consequential action
Some workflows contain a managed connector action that should not execute solely because a channel member invoked the workflow.
Punk can pause the workflow at that exact node, persist a bounded checkpoint, and publish a signed approval request. A valid decision must come from an authorized actor and reference the exact published request event. Approval and one deduplicated resume job are committed together.
Before dispatch, Punk revalidates the workflow graph, mapping version, deciding principal, membership scope, connector grant, policy, manifest, schema, action, and canonical arguments. The workflow resumes from the checkpoint rather than replaying earlier steps.
If Punk cannot determine whether a remote write completed after dispatch, it records reconciliation required and does not blindly retry the action. This is a safer claim than pretending a distributed chat-to-connector path is exactly once.
The result is a human approval loop that is visible inside the community but bound to runtime evidence outside the message text.
The operator dashboard exposes evidence, not secrets
The Buzz operator view is tenant-scoped and, for app-pinned callers, app-scoped. It can show community and channel mappings, public agent identity, queue counts, timestamps, recent event status, and bounded run or receipt references.
It does not return intake secrets, private signing keys, vault credentials, lease tokens, stored message content, raw event tags, reply content, unrestricted worker errors, or another tenant’s records. Detailed errors remain in restricted operational logs.
Administrators can request a bounded retry for a dead-lettered inbox event, but the retry itself is an audited action. Revoked mappings remain terminal and cannot be silently reconnected under the old identity.
This follows the same principle described in Why Every AI Agent Shortcut Needs an Explanation: the useful operator view is not the largest possible data dump. It is the smallest evidence set that explains what happened and what can safely happen next.
Chorus can reason without gaining chat authority
A Buzz-mapped workflow may use Punk Chorus for harder analysis. Chorus can gather evidence, route reasoning, apply verifiers, and produce a receipt, but it does not receive extra channel or connector authority because the reasoning route is more capable.
The managed mapping still defines who invoked the workflow. Punk policy still governs side effects. A human approval is still required where configured. The Buzz publisher still controls the signed terminal reply.
Separating reasoning quality from execution authority is essential. A stronger answer model should improve the work, not expand what the conversation is allowed to do.
A practical Buzz acceptance sequence
Start with one channel, one agent, one workflow, and one actor membership. Use an app-pinned Punk key in observe mode. Send one signed ordinary kind-9 mention and confirm one durable inbox record, no duplicate on replay, and no unreviewed external action.
Then start the isolated workers and confirm the run, workflow, receipt, and terminal reply remain correlated in the operator view. Exercise one denied actor, one dead-letter retry, one approval decision, and one signer or scope change.
Only move the app key to optimize mode after the identity, policy, response, and failure evidence has been reviewed. A governed community agent is ready when both successful work and denied authority are explainable.
Questions readers ask
Does Punk create or host the Buzz community?
No. Operators deploy or obtain the Buzz community and relay, create and admit a dedicated service signer, then store that signer in Punk’s credential vault and connect the existing community.
Can a Buzz message choose its own Punk identity or permissions?
No. Punk derives tenant, app, agent, subject, channel membership, workflow, role, and allowed actions from the current server-owned mapping. Message content and caller-supplied identity headers cannot replace that authority.
How are consequential Buzz workflow actions approved?
Punk can pause at the exact managed action, publish a bounded approval request, verify a signed decision tied to that request, revalidate current authority, and resume from the checkpoint without replaying the workflow from the beginning.