SPYN3 authenticates beta agents with revocable Bearer API keys. Each key belongs to one workspace and carries an explicit permission set; the raw secret is shown once and only its hash is retained. MCP OAuth 2.1 uses the same workspace and permission model when enabled, so changing the login ceremony does not widen what the agent can reach.
API keys are workload identities
Treat a SPYN3 key as the identity of one agent, integration or environment—not as a password shared across a company. A key records its name, visible prefix, permissions, creation time, last-use time and revocation state. The secret begins with spyn3_live_ and is displayed only when created.
Authorization: Bearer $SPYN3_API_KEYThe gateway derives the workspace from the authenticated key. A caller cannot switch tenants by changing a path parameter or request field. Revoking the key denies later requests without requiring a change inside the connected source.
Grant the smallest useful permission set
search:knowledgeUse search_workspace, query_workspace, /agent/search and /agent/query.read:documentsList connected sources and retrieve bounded document detail.sync:sourcesTrigger source synchronization where a surface exposes that action.write:documentsAdd or modify workspace documents where a write surface is enabled.admin:workspacePerform administrative workspace operations; do not grant it to retrieval-only agents.The current public MCP tool set needs only the first two permissions. A read-only answering agent normally receives search:knowledge and read:documents; it does not need sync, write or administration.
Where MCP OAuth 2.1 fits
API keys are the always-available machine-authentication path in the private beta. SPYN3 also implements the resource-server side of MCP OAuth 2.1: protected-resource metadata, audience validation, workspace claims, supported scopes and revocable consent grants. OAuth is available only in deployments where an authorization issuer and JWKS endpoint are configured.
A standards-compatible client can discover the authorization server after a 401, request SPYN3 scopes and receive a token bound to the selected workspace. Server-side authorization then maps those public OAuth scopes onto the same internal permissions used for API keys.
OAuth can improve consent and credential handling, but the resource server must still validate issuer, audience, expiry, workspace and scopes on every call. The production MCP security checklist covers the wider deployment boundary.
A practical credential policy
- One key per workload and environment. Separate local development, staging, production and every agent with materially different access.
- Name the purpose. “Contract assistant — production” is auditable; “API key 4” is not.
- Start read-only. Add a permission only when a tested user flow requires it.
- Never log the secret. Redact authorization headers before application, error and trace logging.
- Revoke independently. Keep the ability to disable one agent without disconnecting the data source or other clients.
- Review last use. Retire credentials with no current owner or workload.
A connection is useful only when its boundary is clear
Start with one scoped agent
Use one real workspace, one named credential and the smallest useful permission set. SPYN3 keeps that boundary behind both REST and MCP while your client keeps control of the experience.
Request private beta accessSPYN3 is AI-ready data infrastructure for technical builders. It connects business sources into a workspace-isolated knowledge layer and exposes that layer through REST and a hosted MCP server, with permission-scoped access and cited retrieval. SPYN3 is currently in private beta.
Sources and implementation basis
- MCP authorization specification — protected-resource discovery and OAuth requirements. Verified 13 Sep 2026
- SPYN3 key, permission and OAuth behavior was verified against the current private-beta gateway implementation on 13 Sep 2026.