API Passport — When and Why

Why API Passports exist

Agents commonly call external APIs, MCP servers, GPT Actions, webhooks, or internal authorised tools. Each authorised API surface is its own logical thing that may need to be referenced, scoped, and resolver-verifiable.

Rule of one

• One Agent Credential = one logical agent
• One API Passport = one authorised API surface
• Multiple agents that share an API still each reference the same single API Passport for that surface

When an API Passport is required

• The agent exposes APIs to other agents or systems under ECZ-ID rules
• The agent depends on an authorised API surface that is expected to be resolver-verifiable
• The agent advertises GPT Actions, MCP tools, or webhook endpoints
• The repository or package declares API trust metadata for relying parties

Practical examples

• Agent with no external API surface — Agent Credential only
• Agent calling one internal API — Agent Credential plus one API Passport for that API
• Agent exposing GPT Actions — Agent Credential plus an API Passport for the action surface
• MCP server or tool endpoint — API Passport for the server, plus Agent Credential for any agent that wraps it
• Repository or package declaring API trust metadata — API Passport reference declared via OpenAPI x-ecz-id

What API Passports do not do

• They do not certify the API as safe
• They do not guarantee the API is reachable
• They do not replace authentication, authorisation, rate limiting, or input validation
• They are not transferable by copying metadata

Where things happen

API Passport acquisition and lifecycle happen in TrustOps. Current API Passport proof must be checked in Resolver. Developer Gateway only documents and routes.