Connect your first runtime
Prove the connection before granting real authority. Your runtime signs a diagnostic request; Passport deliberately blocks it and returns a signed receipt. Nothing deploys, spends money, or calls an upstream tool.
You need a Passport account, an organization, and Node.js 24 or later. An owner or admin prepares the check. You do not need Vercel or an npm account.
1. Choose an agent
Open Dashboard → Set up. Create an agent or choose an active one whose private key you control.
Generated keys are displayed once. Save the PEM file outside the starter directory, with access restricted to your trusted runtime. If lost, rotate the key in Agents and save the replacement. You can instead register an existing Ed25519 public key; keep the private half in your runtime or KMS.
Do not paste private keys into prompts, assistant messages, source control, URLs, or browser storage. The model proposes actions; a separate trusted runtime signs and enforces decisions.
2. Prepare a blocked check
Choose Prepare or resume check. This explicitly creates:
- A provider-neutral project used only for this check.
- A narrow
toolgrant forpassport-onboarding/connection_check. - A policy that denies this action from
local-dev.
Existing permissions are unchanged. Returning to setup resumes the same account and agent configuration. If it has expired, been revoked, or changed, setup explains the problem and offers a new isolated check without rewriting the old evidence.
3. Run the Node starter
Download the starter, extract it, and open the
passport-node-starter directory in a terminal. No dependency installation
is needed. Use the commands shown in setup: they contain your organization,
agent, project and configured Passport URL, but no secrets.
Replace PASSPORT_PRIVATE_KEY_FILE with the absolute path to your saved PEM
file, then run npm run check. The Node guide explains the package
and error handling.
The expected result is Blocked as expected, with status denied and reason
POLICY_DENIED. The starter checks the issuer, signature and exact request
binding before reporting Runtime connected. It never calls execution.
4. Inspect the evidence
Return to Set up → Check for my request. The result is tied to this agent and isolated project, not merely to the existence of some recent request. Inspect the real authorization ID, reason and signed receipt. The selection survives refreshes; evidence remains discoverable after newer requests arrive.
Key rotation or configuration changes can leave valid historical evidence without a currently connected state. Run the check again with the current key and a ready diagnostic configuration.
Next: give the runtime real permissions
Runtime connected is not permission to act or a production-readiness claim. Keep the diagnostic deny rule. Use Configure real permissions to create a separate project, give the selected agent a bounded grant, and set its policy: allow, deny, or require human approval.
Choose the integration you need: Vercel, HTTP, or MCP. Treat failed checks and unexpected responses as a stop, not a reason to bypass Passport.