MCP permissions and safety

Authorization starts with a knowledge base

Each connection binds an Agent name, a stable client fingerprint, a secret shown once, and the knowledge bases you explicitly approve. Initial pairing grants read access only.

Project observations, AI-derived records, notes, highlights or annotations, and file operations use separate permissions. Granting one write capability never grants another implicitly.

High-impact operations require per-operation approval

Notes, highlight or annotation batches, and file operations use a two-phase flow:

1. The Agent submits a complete plan but does not execute it.
2. Weave shows the operation type, target, and content.
3. The user approves or rejects it.
4. Approval creates a short-lived, one-time token bound to the complete plan.
5. The Agent can execute only an operation that exactly matches the approved plan.

Content changes, citation-version conflicts, revoked grants, expiry, token reuse, or payload changes all fail closed. If any item in a highlight or annotation batch is invalid, the entire batch rolls back.

Revocation and credentials

After a client is revoked in a knowledge base MCP panel, the Runtime rejects further calls immediately. When the client has no remaining grants, its local credential is removed as well.

A pairing secret cannot be recovered. If it is lost or suspected to be exposed, revoke the old connection and pair again.

Where data goes

The MCP bridge and Weave Runtime communicate locally. After an Agent receives tool output, however, it may send that content to its model provider. Before connecting, verify:

• Whether the Agent and model service may process the material;
• Whether training, logging, or telemetry is enabled;
• Whether team data policy permits the use;
• Whether only the knowledge bases required for the task are granted.

Document content is always treated as untrusted data. Text inside a source cannot expand MCP permissions, switch knowledge bases, or bypass confirmation.