Adapter: map native agent responder policy to registered VM agents

[100yenadmin]

Parent: #36
Related: #41
Backend prerequisite: dashboard#727

Outcome

Reuse the native Agents edit/advanced experience so an authorized company admin can manage the supported Who can talk to this agent equivalent for an already-registered VM agent. Hermes retains all runtime and private-agent authority.

Thin-adapter contract

• Extend the existing native responder-policy surface; do not build a separate VM administration screen.
• Select rooms from Hive's native room state and human authors from the server-provided active company directory.
• The server resolves selected authors to active same-company public identities; it stores room IDs only as bounded narrowing selectors because Supabase is not the native room authority.
• Reconcile the exact revisioned policy to the existing VM-side buzz-acp room/author allowlists and require bridge acknowledgement before showing it as applied.
• buzz-acp must intersect configured room selectors with rooms the exact agent can currently see/join through native relay membership. A stale or foreign room ID must never broaden access.
• Use native room membership and relay admission as additional gates; the adapter may narrow access but never broaden it.
• Keep DM behavior truthful and unchanged unless native remote-agent DM support is separately proven.

Acceptance

• The native Agent edit surface displays the current allowed rooms and human authors for a registered VM agent.
• Only a company admin may change the policy.
• The exact registered agent, tenant, and selected human authors are resolved server-side.
• Room selectors come from native Hive state and are intersected with the agent's live native memberships on the VM.
• The VM bridge acknowledges the applied revision before Hive reports success.
• Removing a room or author stops new invocations within the bounded revocation window.
• Stale revisions, ambiguous ownership, cross-company authors, and unregistered agents fail closed.
• No operation edits Hermes instructions, model, memory, tools, provider, credentials, profile, or private key.
• Focused policy/reconciliation tests, exact-head CI, and independent tenant/security review pass.

Non-goals

• A Supabase room registry, collaboration broker, new agent-policy product, or general VM administration.
• Content retrieval, channel memory, employee-file access, or cross-channel search.
• Creating, copying, or configuring Hermes profiles.
• Enabling arbitrary public users or inventing new DM authority.

Proof boundary

UI state and catalog writes are not runtime proof. The beta canary must show one allowed and one denied author in an approved native member room, a non-member room failing closed, plus bounded revocation without cross-company discovery.

[100yenadmin]

Owner decision — channel-scoped company agents

For the first managed release, company general agents are channel collaborators, not employee-computer assistants.

• An agent may receive and search content from a channel only while both the agent and requesting human are authorized members of that channel.
• Membership in a private channel grants access to that private channel, but does not make its content globally retrievable from public or unrelated channels.
• The default retrieval scope is the current channel plus explicitly company-safe shared knowledge.
• Any cross-channel search must verify, for every source channel, that both the requester and agent currently have access, and must preserve source attribution.
• Channel-derived summaries, embeddings, and memory remain tagged to that channel. Removal revokes new reads/search immediately and makes that channel namespace unavailable to the agent.
• General agents receive no employee filesystem, shell, browser profile, personal Hermes profile, email, or Workbench access.
• The admin surface manages allowed channels and authors only; it does not grant local-machine or Hermes-internal authority.

This preserves useful participation in private project rooms without allowing private-room information to bleed into general or another employee's context.

[100yenadmin]

Guarded-beta dependency and release disposition

Accepted follow-up for the Guarded Business Beta.

Implement only after:

1. External dependency: classify the existing Benjamin/ATRIS employee VM #45 establishes the employee-VM/company ownership model.
2. Security: isolate company-agent profiles and channel-scoped retrieval #46 proves profile, credential, memory, and channel-retrieval isolation.
3. Adapter: discover registered company VM agents in native Agents #41 registers stable organization-owned company-agent identities.

This issue then adds the administrative policy surface and applied-revision
acknowledgement. It does not create profiles, invent a new memory authority,
broaden company-agent DMs, or grant employee-computer access.