Skip to content

Agents and permissions

Agents should enter KB-1 through the same service boundary humans use for vault operations. For local agents, that boundary is the daemon’s MCP endpoint. For Cloud-enabled agent workflows, that boundary is the Cloud MCP worker, which authenticates the user, records the approved integration, and routes to the selected org daemon.

  • Local agents connect to http://127.0.0.1:7382/mcp or another explicitly chosen daemon URL.
  • Cloud MCP agents connect to the deployment’s Cloud MCP URL only after that worker has been enabled for the deployment.
  • list_vaults discovers available vault ids.
  • Cloud MCP also requires list_orgs and an explicit org on daemon-backed tool calls.
  • Every data tool requires vaultId.
  • Local daemon mutations are audited as mcp_client; Cloud MCP mutations are attributed to the approved integration and user.
  • The local MCP endpoint does not currently enforce per-agent roles.

If an agent can reach the daemon MCP endpoint, treat it as able to read and write reachable vaults. Use client-side approval controls and careful prompts until per-agent policy is added.

For the full team experience, Cloud owns user identity, org membership, signed entry, routing, and presence. Cloud MCP uses that identity layer to approve integrations and attribute their tool activity. The local daemon remains the universal path for local-only and self-hosted operators; Cloud MCP is deployment-gated until your Cloud environment exposes the worker URL.

Agent activity is distinct from human presence. Cloud can show a short-lived agent activity record after a tool action, but the active-now strip remains a human WebSocket roster.

  1. Start with read-only prompts.
  2. Have the agent call list_vaults.
  3. Require explicit vaultId in every write prompt.
  4. Use scratch notes for smoke tests.
  5. For edits, require read_note baseline plus edit_note.
  6. Clean up scratch notes or move them to trash.