Authentication

Sign up for Clerk and keep its API key out of agent context

Clerk provisioning mixes an email-verified dashboard signup with a backend secret that must never be bundled into browser code.

The reviewed registry flow creates the account and captures the secret directly, while the example below calls Clerk's documented Backend API through a vault grant.

Ask your coding agentUse Trusty Squire to sign me up for Clerk, save the secret key, allow api.clerk.com for server-side requests, and wire it into this app without exposing the raw key.
Registry status
Active
Recorded actions
7
Credential fields
1
Provider entry
dashboard.clerk.com

What this setup unlocks

Use Clerk for application authentication and user management while Trusty Squire injects the credential only into allowed provider requests.

  • Add sign-up and sign-in to a new web application.
  • Provision authentication for a prototype.

What your agent does

These public steps preserve the active registry flow while omitting captured account identifiers, brittle DOM selectors, and literal form values.

  1. 01

    navigate

    Open the Clerk account console.

  2. 02

    fill

    Enter the generated signup email alias.

  3. 03

    fill

    Enter a generated password through the sealed browser session.

  4. 04

    click

    Continue through the account flow.

  5. 05

    await email code

    Receive and enter the email verification code through the sealed verification flow.

  6. 06

    click

    Create a new API credential.

  7. 07

    extract via regex

    Capture the validated credential directly into the vault.

Credential saved to the vault

  • CLERK_API_KEY

    An environment-specific Clerk backend secret. Development instances use sk_test_; production instances use sk_live_. Creating or promoting a production instance is separate from this reviewed signup flow.

Write-only by design. Clerk's CLERK_API_KEY is stored as write-only vault credential. For backend use, mint a host-scoped egress grant and keep its revocable token in server-side secret storage. The raw provider value is not returned to the agent or written to the project.

Use it without revealing the provider key

In the Vault, first make api.clerk.comthe credential's primary allowed host. Then ask your agent to call grant_app_access. It returns a host-scoped egress base URL and a revocable token; the backend uses those values to list users from the Clerk Backend API.

// One-time Vault policy: make api.clerk.com
// the primary allowed host. Off-allowlist requests are refused.

// Then ask your agent to create a scoped grant:
grant_app_access({
  service: "clerk",
  rate_limit_per_hour: 100
})

// Inject the returned fields from backend-only secret storage:
// SQUIRE_EGRESS_BASE_URL=<returned base_url>
// SQUIRE_EGRESS_TOKEN=<returned token>

const response = await fetch(
  `${process.env.SQUIRE_EGRESS_BASE_URL}/v1/users?limit=10`,
  {
    headers: {
      Authorization: `Bearer ${process.env.SQUIRE_EGRESS_TOKEN}`,
    },
  },
);

if (!response.ok) throw new Error(`Clerk returned ${response.status}`);
const users = await response.json();

Provider request checked against Clerk Backend API: list users on 2026-07-15.

The egress token is still a secret. Keep SQUIRE_EGRESS_TOKEN in backend-only secret storage. Do not expose it in browser JavaScript, logs, or source control. grant_app_accessreturns this scoped token once through the MCP result, so it can enter agent context; it is not the provider key. Move it directly into your deployment's secret store, or useuse_credential when you need zero grant-token exposure. Grants are host-scoped, audited, and revocable without rotating the provider credential.

Frequently asked questions

How do I use the Clerk API key without .env?
Ask your coding agent: “Use Trusty Squire to sign me up for Clerk, save the secret key, allow api.clerk.com for server-side requests, and wire it into this app without exposing the raw key.” Trusty Squire captures the provider credential directly into its write-only vault instead of returning it for an .env file. An environment-specific Clerk backend secret. Development instances use sk_test_; production instances use sk_live_. Creating or promoting a production instance is separate from this reviewed signup flow.
Can Trusty Squire automate Clerk signup?
Yes, for the reviewed email flow. Enter the generated signup email alias. Receive and enter the email verification code through the sealed verification flow. A hard CAPTCHA, payment, phone requirement, or human-only decision still stops the run for you.
How does Clerk MCP provisioning keep the API key private?
Trusty Squire is the MCP server between your coding agent and the vault. It stores the captured Clerk credential as a write-only value, then returns a reference or scoped egress grant instead of the raw provider key. The backend grant can call only its configured provider host and remains revocable and auditable.
What can I do with the generated Clerk credential?
Clerk documents the secret key as bearer authentication for its Backend API, including server-side user, session, organization, and invitation operations.
What should I verify before using Clerk in production?
The captured key belongs to one Clerk instance. Frontend publishable keys, application configuration, user-model settings, and production-instance promotion are separate from this credential flow.