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.

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). 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).
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.