Every native MCP connection belongs to one tenant and one user. OAuth token lookup uses the connection's tenant, user, and server identity together. DeepSpace cannot select a token belonging to another user or use a tenant-wide Google or GitHub token.

Conversation and DeepSpace endpoints verify that the referenced object belongs to the current tenant and that the current user may operate it. These checks are repeated in the runtime immediately before remote execution; frontend context is never treated as proof of authorization.

• Users sign in and consent directly at Google, GitHub, or the approved provider.
• Passwords remain with the provider and are never submitted to AverQel.
• PKCE verifier data and signed OAuth state are held in encrypted, single-use transaction storage.
• Access tokens, refresh tokens, and client secrets are encrypted and never serialized into frontend DTOs.
• Verified granted scope names and safe account identity may be returned to the owning user.
• Disconnect removes the local credential record and attempts provider revocation where the provider supports it.
• OAuth secrets are excluded from logs, prompts, MCP events, inspector payloads, and marketplace metadata.

Always allow means the tool may run without a per-call approval only when every connection, scope, risk, tenant, catalog, and platform rule passes. It is not a global bypass.

Needs approval pauses a risky action for an explicit user decision.Blocked prevents the tool from being offered or called. Blocked wins over every less restrictive setting.

Read-only prevents writes and higher-risk actions even if a tool was otherwise selected. The risk ceiling limits the highest allowed risk class. Conversation and DeepSpace controls are additional gates: when an override is absent, stale, or false, the connection is denied for that scope.

When a user asks DeepSpace to search Gmail, inspect GitHub, read a Drive file, or perform another MCP task, AverQel checks the current tenant, user, connection, provider approval, authentication state, catalog revision, scope enablement, tool mode, risk policy, and confirmation requirement before planning and again immediately before the remote call.

A blocked or disabled tool is not offered to the MCP action surface. A tool result may be summarized for the user, but raw remote payloads are not returned through the MCP inspector or persisted as unredacted MCP events.

Administrators can manage approved catalog metadata through the protected catalog permission. Normal admin views receive operational metadata, not users' OAuth tokens or private MCP content. Audit and deletion workflows remain tenant-aware and do not require exposing raw secrets.

These controls describe AverQel's application contract. Operators must still configure production OAuth clients, callback URLs, encryption keys, database RLS, retention, network egress, provider scopes, and incident procedures for their deployment.