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.
- 01
navigate
Open the Clerk account console.
- 02
fill
Enter the generated signup email alias.
- 03
fill
Enter a generated password through the sealed browser session.
- 04
click
Continue through the account flow.
- 05
await email code
Receive and enter the email verification code through the sealed verification flow.
- 06
click
Create a new API credential.
- 07
extract via regex
Capture the validated credential directly into the vault.
Credential saved to the vault
CLERK_API_KEYAn 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.
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.
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.