per-agent send allow-list via hyperhive.allowedRecipients
new NixOS option in harness-base.nix: hyperhive.allowedRecipients = [ 'alice' 'manager' ]; # whitelist hyperhive.allowedRecipients = [ ]; # default = unrestricted module writes the list as JSON to /etc/hyperhive/send-allow .json at activation. AgentServer::send reads the file before issuing the broker request; if the list is non-empty and `to` isn't on it, the tool returns a claude-readable refusal string without touching the broker. the manager is always implicitly permitted regardless of the list — otherwise a misconfigured allow-list could strand a sub-agent without an escalation path. enforcement is in the in-container MCP server (not on the host's per-agent socket) because the agent's nix config is the trust boundary anyway — the operator audits agent.nix at deploy time, the activation-time /etc/hyperhive/send-allow .json is r/o under /nix/store, so the agent can't tamper at runtime without going through a new approval. agent prompt mentions the option + tells claude to route through the manager when refused. retires the matching TODO under Permissions / policy.
This commit is contained in:
parent
d1c69b134a
commit
67e4242b9f
4 changed files with 78 additions and 12 deletions
|
|
@ -3,7 +3,7 @@ You are hyperhive agent `{label}` in a multi-agent system. The operator (recipie
|
|||
Tools (hyperhive surface):
|
||||
|
||||
- `mcp__hyperhive__recv(wait_seconds?)` — drain one more message from your inbox (returns `(empty)` if nothing pending). Without `wait_seconds` (or with `0`) it returns immediately — a cheap "anything pending?" peek you can sprinkle between tool calls. To **wait** for work when you have nothing else useful to do this turn, call with a long wait (e.g. `wait_seconds: 180`, the max) — incoming messages wake you instantly, otherwise the call returns empty at the timeout. That's strictly better than a fixed `sleep` shell command: lower latency on new work, no busy-loop.
|
||||
- `mcp__hyperhive__send(to, body)` — message a peer (by their name) or the operator (recipient `operator`, surfaces in the dashboard).
|
||||
- `mcp__hyperhive__send(to, body)` — message a peer (by their name) or the operator (recipient `operator`, surfaces in the dashboard). Some agents have a per-agent allow-list (`hyperhive.allowedRecipients` in their `agent.nix`) — if so the tool refuses recipients outside the list with a clear error; route through the manager (`send(to: "manager", …)`) which is always reachable.
|
||||
- (some agents only) **extra MCP tools** surfaced as `mcp__<server>__<tool>` — these are agent-specific (matrix client, scraper, db connector, etc.) declared in your `agent.nix` under `hyperhive.extraMcpServers`. Treat them as first-class tools alongside the hyperhive surface; the operator already auto-approved them at deploy time.
|
||||
- `mcp__hyperhive__ask_operator(question, options?, multi?, ttl_seconds?)` — surface a question to the human operator on the dashboard. Returns immediately with a question id — do NOT wait inline. When the operator answers, a system message with event `operator_answered { id, question, answer }` lands in your inbox; handle it on a future turn. Use this for clarifications, permission for risky actions, or choice between options. `options` is advisory: a short fixed-choice list when applicable, otherwise leave empty for free text. `multi: true` lets the operator pick multiple (checkboxes), answer comes back comma-joined. `ttl_seconds` auto-cancels with answer `[expired]` when the decision becomes moot.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue