ChatGPT, Claude, an agent, or a developer tool requests access.
P03Security
Two trust
boundaries.
MCP client access and upstream API access are controlled separately. That separation lets you rotate, revoke, and troubleshoot each layer independently.
Authentication guideOAuth or token →
Checks client access, validates the selected tool, and maps the request.
Provider credential →
Receives the request using the upstream authorization you configured.
01Controls
Security controls built into the connector lifecycle.
Keep tool access narrow and credentials replaceable as your integration evolves.
OAuth 2.1-style flow
Dynamic client registration, authorization code flow with PKCE, access bound to one server or toolkit, and refresh rotation.
Encrypted provider credentials
Upstream credentials, shared or each person’s own, use authenticated encryption and are never returned in responses.
Scoped, hash-only tokens
Static MCP secrets are shown once and kept only as hashes. Each can be read-only, limited to chosen tools, or set to expire.
Workspace roles
Servers, toolkits, tokens, and calls belong to one workspace. Owners, admins, editors, and viewers each get only what their role allows.
Destination guardrails
Private and reserved destinations are blocked during imports and calls, and a server can accept calls only from your networks.
Rates and quotas
Cap requests a minute and tool calls a day for each server, on top of the plan’s monthly allowance.
Confirm before risky calls
Tools that change data can require the user’s approval, and agents are told to ask for it.
Calls and changes
Inspect each call’s status, latency, and redacted details, and see every change in the audit log.
02Shared responsibility
You control what the agent can do.
Select only the operations needed for the intended workflow, document side effects clearly, and use least-privilege provider credentials.
AlltoMCP is provided as-is. You remain responsible for your API, data, credentials, tool selection, and how connected clients use them.
Read the terms