Connections, credentials, and permissions

Scope

A Connection is a named relationship to an external capability. A key is a credential used by a connection. Projects receive permission to use the connection rather than unrestricted access to the installation's keys.

Existing foundation

The recorded Connections implementation includes account-owned keys, connection metadata, grants, resource bindings and revocation. Shared dashboard gates protect HTTP and WebSocket management. Provider execution is not globally enabled. OAuth, general MCP execution, media and channels still require adapters.

Decisions

Use server-derived account and immutable resource identity on both HTTP and WebSocket paths.
Reuse stable key names and the existing vault; do not dump /env into a worker.
A stored grant is insufficient when a resource, credential or connection has been removed or replaced.
Local keyless MCP requires an explicit no-credential mode. Never create dummy vault entries to satisfy the current required credential field.
Scope privileges by capability and permitted tools. Provider-specific resource restrictions may also be necessary.
Revocation prevents subsequent admission; external effects already started cannot be promised reversible.

Configuration experience

Chat can offer “Connect a service” or “Add project configuration.” The manual panel uses the same backend operation. Distinguish configured, ready, unavailable and revoked states. Tokens belong in a protected input flow, never ordinary chat messages or activity logs.

Implementation tasks

ID	Deliverable	Status
CONN-MCP-01 / MCP-P02	Keyless MCP binding with backward-compatible credential rules	Pending
CONN-MCP-02 / MCP-P03	Current-policy authorization on every MCP operation	Pending
CONN-ADAPTER-01	Provider-specific OAuth/BYOK lifecycle adapters	Future work

Acceptance evidence required

Wrong-account and wrong-project calls fail before upstream access. Existing credential-backed providers still reject missing credentials. Replacing a project or server does not inherit access. Revocation takes effect for later calls in an already running session. Existing management tests are historical evidence; they do not prove operational MCP enforcement.

Related areas

Agent Mate overview — A guide to the separate designs and how they fit together.
Architecture and runtime integration — How Agent Mate uses the existing runtime without depending on dashboard lifetime.
Execution, recovery, and progress tracking — Independent tasks, cancellation, uncertain outcomes and durable progress.
Project-scoped MCP for Agent Mate — The existing seven-task MCP plan: grants, bridge integration, revocation and acceptance.

Durable task identity — implementation progress

The Connections backend now stores an immutable account, host, task and verified project association. It survives registry reopening and checks current project ownership. Revocation prevents an old task from being reactivated. MCP permission lookup uses that stored project identity and current connection grants.

Seven focused tests passed: persistence, wrong account/host/task, permanent revocation, replaced projects and removed policy accounts, unverified selectors, project reassignment, and current MCP grants/credential authority. The full Connections regression suite passed 32 tests. These tests use temporary SQLite databases and synthetic project directories.

Not deployed. Authenticated transport wiring and OS worker isolation remain pending. The API requires trusted service context; an untrusted host or account string is not authentication. No live project MCP access was enabled.