How does MCP authorization work and what credentials are stored?

MCP servers may use org secrets, per-user OAuth, or API keys—know what Harriet retains, how the connector wizard maps to these patterns, and how approvals work in workflows.

Connecting external tools through MCP involves credentials and sometimes per-user sign-in. What is stored depends on how the connector is configured in the MCP wizard.

Organization keys are never given to end users

When IT connects a vendor or internal API with a single organization API key (sometimes called a god-mode or admin key), that secret is configured once in Company settings and stored on Harriet’s servers. Employees never receive, paste, or configure that key in chat, Claude Desktop, Harriet Desktop, or any other client.

Instead, Harriet authenticates each person and issues subscoped access tied to their Harriet identity:

Harriet chat and workflows: The user is already signed in to Harriet. Each MCP tool call runs under that user’s account, after tool permissions (enabled tools, groups, roles), optional request/response hooks, and workflow confirmation rules. The organization key is used only on the server side when Harriet forwards an allowed call upstream.
Endpoint AI (desktop MCP): Harriet provisions a per-user, per-device MCP proxy credential (a unique proxy URL/token for that employee on that enrolled device). The desktop agent talks to Harriet with that credential—not with the vendor org key. The proxy exposes only tools that user is permitted to use under the connector’s tool permissions and skill assignment.

Train users and admins: do not paste vendor API keys into chat or desktop config. If someone needs broader access, change groups, tool permissions, or skills—do not hand out the org secret.

See How do we turn MCP tools on or off for specific groups? and How can we restrict a shared-key MCP connector to each user's own data? for how to narrow what each audience can call and see.

Common patterns

Organization secret: A single API key or client secret your IT provides. Harriet stores it securely server-side and uses it when the skill runs (subject to your deployment’s security model). End users never see or hold this key—see Organization keys are never given to end users above. Used by some OpenAPI and Native MCP setups.
Per-user OAuth: Each employee signs in to the third party (for example Google). Harriet stores tokens on their behalf so actions run as that user, limited to what they authorized. The wizard surfaces OAuth client ID requirements when this mode is enabled.
Service account JSON (for example Google Workspace): Some setups use a Google service configuration managed by IT; end users still complete consent where required so Harriet can act with the right scopes.
Sandboxed commands: Sandboxed (uvx / npx) connectors may use registry packages with files or environment you supply in the connector configuration—treat these like any other managed secret surface.

Approvals in workflows

Some tool actions may require explicit approval before they run (for example sending email or updating a system of record).
Configure Requires confirmation per tool under Tool permissions on the MCP connector—see How do we turn MCP tools on or off for specific groups?
In workflow runs attached to a ticket, a pending action can pause the workflow until an approver confirms it in the ticket UI. After approval, the workflow continues with the same overall task.

Endpoint AI review (separate from tool approval)

Connectors and package skills may also go through an org review queue when Endpoint AI is enabled. That is governance before users see the integration, distinct from in-workflow per-action approval.

Example

You connect Google Calendar with per-user OAuth. When a manager asks Harriet to schedule a meeting, Harriet uses that manager’s calendar permissions—not someone else’s.

Guardrails

Treat MCP servers like any vendor integration: document who owns the credentials and rotation schedule.
Per-user OAuth means the user’s privileges apply—train users not to connect personal accounts if your policy forbids it.
Do not paste secrets into chat; configure them only in Company settings (connector configuration and related admin pages).

See How to create an MCP connector (Company settings) and MCP from GitHub and registries—sandboxed connectors vs skill packages.

When you must use an organization secret instead of per-user OAuth, combine least-privilege tool permissions with request/response hooks—see How can we restrict a shared-key MCP connector to each user's own data?