Skip to main content
Every plan can browse the same verified catalog. Free and Pro make verified catalog apps self-service and read-only by default. Enterprise admins can keep that open experience or require review and apply rollout rules.

Add an app

Add an app from the catalog, or add a custom MCP endpoint:

From the catalog

Choose a reviewed managed API integration or a probe-verified MCP connector. Members click Connect; Passport applies the workspace’s catalog policy automatically.

Add custom app

Point Passport at any MCP server URL. It connects, discovers the tools, and scans them.
Each app authenticates upstream in one of three ways: a single company account for everyone (org), each person’s own account (member, through an OAuth broker), or no auth (none). Managed API integrations use per-person OAuth.
Some connectors need a one-time company OAuth client before anyone can connect them (when the provider does not support dynamic registration). Passport shows a “needs admin setup” state and the callback URL to register, rather than a dead-end member sign-in.

Enterprise catalog modes

  • Open: verified catalog apps connect without an admin decision.
  • Review: the first Connect intent creates or joins a grouped request.
  • Rules: allow or review by app, category, and team, with an explicit block for exceptions.
Approval defaults to the requesters with a read-only pass. An admin can widen it to a team or the workspace. API keys and manual OAuth clients stay in setup until their readiness check passes; requesters are notified only when they can actually connect.

Passes and access

A pass is what a person can do with an app:
  • Full: every tool, including writes.
  • Read-only: only the tools marked read-only. Write tools are hidden from the tool list entirely, so an agent never sees a capability its user cannot call.
  • None: no access; the app is not advertised to that person.
Access resolves from three layers, strongest last:
1

Workspace default or selected scope

Grant a default pass to everyone, or scope the app to selected teams and people only.
2

Per-team passes

Give a team its own pass, for example read-only GitHub for Support.
3

Per-person overrides

Override a specific person, which wins over the team and default.
Selected scope, team passes, and person overrides are part of Pro and Enterprise. On Free, an app has one workspace-wide pass: read-only or full.
How read-only is decided: a tool is treated as read-only only when it is provably so. Probe-verified catalog connectors (and demo apps) may honor the upstream’s own readOnlyHint. Custom URL apps are stricter: an upstream hint counts only when the tool name also looks read-only (prefixes such as get_, list_, search_). Anything not provably read-only counts as a write and is withheld under a read-only pass. The name heuristic is best-effort, not a guarantee that a tool is safe.

Per-tool control and drift

Within an app you can turn individual tools on or off, workspace-wide. On Enterprise, you can also choose whether newly discovered tools default on or off. Passport snapshots each integration’s tool set and detects drift, so you are alerted when an upstream MCP or reviewed API manifest changes rather than silently gaining new capabilities. With Keep off until I approve selected, a new tool stays off until you approve it. A changed tool stays off too, unless the change is low risk: the tool reads data before and after, its new description and parameters pass Passport’s poisoning and runtime security checks, and it only gains optional parameters or a reworded description. Low-risk changes keep serving and are still recorded in the tool history and alert as auto-approved. Tool history and in-app alerts are part of Pro and Enterprise. A write tool, or a change that removes, retypes, constrains, or requires a parameter, stays off. On every plan, a tool whose new definition looks like a poisoning attempt is switched off until you review it. Held tools are listed under Review tool changes in Apps → your app → Connections, with what changed. Select the ones to approve and turn them back on in one step. Flagged tools are approved one at a time. Until then, an agent that calls a held tool is told the app changed it and an admin review is pending, and Activity records the call as held for admin review rather than as a tool you switched off.

Action approvals

Separate from catalog requests, a member’s own Safety preference can put a write or destructive action on hold until that person allows it. Passport asks them wherever it can reach them: agents that support MCP elicitation get a prompt inside the agent itself, with the app, the action and its risk class, the account, and a redacted one-line argument summary; everything else waits while the person decides in the Passport app. Either way the decision lands on the same durable approval record, so a decision made on one replica releases a call held on another. The audit trail records how consent was collected. An approval shows whether it was answered in Passport or in an agent, and which agent install answered it; the Activity row for the released call carries the same provenance next to the approval it consumed. Autonomous agent credentials are never prompted, and the CLI keeps returning an explicit pending result for its own retry loop. Set PASSPORT_APPROVAL_ELICITATION=off to turn in-agent prompts off for a deployment and keep the Passport-app flow as the only channel.

Workspace approval defaults

Two workspace-wide defaults live in Settings → Access → Approvals. Wait for approval inside the agent decides what an interactive agent gets while a person is deciding. Wait for approval (the default) keeps the call open for up to 55 seconds, which is what lets an in-agent prompt or a decision in Passport release the original call. Answer right away returns immediately with the same pending result the CLI gets, so the agent retries instead of waiting. Automation keys that run as themselves and the CLI always get the pending result, whichever mode is set. Team floors (Pro and Enterprise) set the least strict Autopilot preset people on a team may hold in each environment, such as “Production: at least Careful”, with an all-teams default and a per-team override. It is a floor, not a setting on their behalf: a member’s own stricter choice always wins, and their stored choice is kept, so lowering the floor later gives them their choice back. Floors also bound every exception. Admins can add team and workspace exceptions, and a block always wins. The older default approval rules and production safety column are read as floors and blocks.

Requests

In a managed Enterprise catalog, Connect creates or joins one durable request for that app. The admin sees every requester together and can allow the requesters, their teams, or the workspace. If company setup is required, the request moves through Approved · setup in progress and becomes Ready to connect only after the credential or OAuth client is configured. On every plan, a provider that requires a company credential creates an admin setup task rather than pretending the app is ready. Custom and unverified endpoints are always admin-managed.

Browser approval notifications

Open Settings and switch on Approval alerts in this browser under Notifications, then allow notifications in your browser. Use Send test to check that a notification reaches this device. Each browser needs its own permission; enabling one device does not subscribe your other devices. Notifications contain a generic approval reminder, not action arguments or account details. Open the notification to review the specific request in Passport and allow or deny it. If it has expired or someone already answered, Passport shows its current status instead of allowing a second decision. You can receive notifications without keeping a Passport tab open. Delivery still depends on browser and operating-system settings, network connectivity, and Focus or Do Not Disturb. Keep the Approvals page available for requests that need an immediate response. On iPhone or iPad, add Passport to your Home Screen, open it from that icon, and enable notifications there. If permission is blocked, change it in your browser or system notification settings and return to Passport. Switch Approval alerts in this browser off to stop notifications for this workspace in the current browser. Signing out, revoking the browser session, or deactivating the member also stops server-side delivery for that subscription. After signing in again, enable notifications again if prompted.