AI Keypass gives every enterprise AI system, application, model, agent, or AI-enabled capability a persistent identity — a digital passport that acts as the key to verifying it.

The core idea is deliberately simple: give every AI an identity. Register it once. Verify it anywhere.

AI Keypass is not a governance suite, compliance scanner, observability platform, risk engine, or policy system. It is the identity and registration layer for enterprise AI. Other products can determine whether an AI is secure, compliant, or safe — AI Keypass simply says "This is AI ai_pspt_7F3A92K1. Acme recognizes it. Jane owns it. Its registration is active."

Why "Passport"? AI Keypass is built on two ideas. The Passport is the credential — the durable identity record each AI carries. The Key is the function — how systems verify, attest, and access that identity. Together: a verifiable passport you can key into. When you see passport in an API scope, ID prefix, or webhook event, it refers to this credential feature — the first capability of the platform.

• CIO / CTO — see what AI exists across the organization.
• CISO — know whether an AI is registered and who owns it.
• AI leaders — maintain a canonical AI inventory.
• Risk & Governance — establish ownership and lifecycle accountability.
• Enterprise architects — use a canonical identifier across systems.
• Product owners — own, update, and attest their AI.
• Developers — get an identity for what they're building.
• Auditors — prove an AI was registered and owned at a given date.
• Procurement — check whether a vendor AI already has a record.

• Create a canonical AI inventory.
• Establish ownership.
• Give AI a persistent identifier.
• Eliminate disconnected spreadsheets.
• Make AI references portable across systems.
• Create lifecycle accountability.
• Enable other systems to verify registration.

Organizations already maintain AI inventories, assessments, model cards, approval records, and technical metadata. The problem is that these records live in different systems, use different identifiers, and frequently become disconnected from the AI system they describe.

AI Keypass gives the system itself a durable identity. Governance records, assessments, deployments, owners, versions, and attestations can reference the same passport—even when the surrounding tools or organizations change.

When you look at an AI record in your inventory, one question matters more than any other: how do you know it still accurately describes the AI operating today — and who last confirmed that?

Two records, same AI. See which one you'd rely on.

Which record would you be more comfortable relying on, sharing with a customer, or joining to another system?

Trust in the registry record isn't only a governance concern — it's what makes AI cost and business value manageable. When you can't confidently attribute spend and outcomes to specific, accountable AIs, two things stay broken: spend stays anonymous (one generic model bill, no owner) and value claims stay unvalidated (outcomes credited to systems you can't even name).

Two cost records, same month. See which one lets you act.

Which cost record would let you answer "what did we spend on, who owns it, and was it worth it" — and which would keep those questions open?

The Passport ID is the join key: spend rolls up by owner, environment, or a tag like cost-center:402 rather than a generic model bill, and a deprecated or revoked Passport can be excluded from value reporting so it stops crediting systems that no longer exist. The registry stays the identity source of truth; FinOps stays the cost source of truth; the Passport ID is what connects them. See Integrations → FinOps & AI value management for the wiring.

Recognize the triggering event. Create a passport when any of the following occurs:

• An AI system enters assessment or discovery.
• A model, agent, or AI-enabled application is approved for production.
• A business unit buys an AI product from a vendor.
• A system is transferred to a new owner.
• A material version or deployment is created.
• A customer, auditor, insurer, or partner needs to verify governance claims.
• Multiple governance tools need to refer to the same system.

When a passport is unnecessary. A short-lived development experiment with no users, production data, or organizational decision-making does not need a passport. If no one outside the build team will ever ask "what is this, and who owns it," the registry isn't adding value yet. Register it when it becomes accountable.

A consulting firm assesses a customer-service agent. It creates a passport during discovery, records the accountable owner and intended use, and attaches an assessment attestation. Six months later, the agent changes models and is deployed in another region. The deployment and version records change, but the system retains its identity. A customer can verify approved claims without receiving access to the company's governance platform.

1. Registration. During discovery, the consulting firm registers the agent and receives its permanent Passport ID.
2. Ownership verification. The firm records the accountable owner and intended use, and the client confirms ownership.
3. Assessment attestation. The assessment team publishes selected conclusions as an attestation linked to the passport.
4. Production approval. When the agent is approved for production, that approval is recorded against the same passport.
5. Version or deployment change. The model changes and the agent is deployed in a new region; the passport's version and deployment records update while its identity is preserved.
6. External verification. A customer verifies the agent's approved claims through the public verification endpoint, without access to the company's governance platform.
7. Retirement. When the agent is decommissioned, the passport is revoked—its audit trail and identity are preserved, and the ID is never reused.

A worked example communicates the product faster than several pages of abstract definitions.

Keypass mentions systems, applications, models, agents, and capabilities. Each is distinct, and a recommended default applies.

• AI system. The governed business capability; usually the primary passport.
• Agent. An independently operated agent with its own purpose and accountability.
• Model. A reusable technical component referenced by one or more systems.
• Deployment. A runtime instance or environment associated with the system.
• Version. A material configuration of an existing system.
• AI-enabled product. A product supplied to customers or acquired from a vendor.
• Automation/RPA process. Eligible when it makes or materially influences consequential actions.

Difficult identity questions

• Does changing the underlying model create a new passport? No—a material change creates a new version, not a new identity.
• Do development, staging, and production share an identity? They share one passport; each is a deployment of the same system.
• Does a multi-agent system get one passport or several? The governed system gets one; each independently operated agent with its own accountability gets its own.
• What happens after a merger or ownership transfer? Ownership transfers onto the existing passport; its identity and history are preserved.
• When does a material change create a new version versus a new system? If the accountable purpose and identity persist, it's a version; if it's a new governed capability, it's a new passport.
• Can the same system appear in several governance platforms? Yes—the passport is the shared reference each platform stores as an external identifier.

A common objection is that identity will become a feature inside an existing governance platform. It's a fair question, and the answer is that the two solve different problems.

Positioning. AI Keypass does not replace an AI governance platform. It gives governance platforms a shared object to govern.

How platforms integrate. A governance platform can store the Passport ID as an external identifier on each AI record, deep-link to the public verification page, import and export passports alongside its own inventory, and call the verify API to confirm registration status before acting. The Passport ID becomes the stable join key between the platform's internal records and the canonical identity.

Beyond governance. Because the Passport ID is a stable cross-system reference, it also ties governance to adjacent domains that need to attribute activity to a known, accountable AI. AI value management platforms join outcomes and ROI to a registered system rather than an estimate; AI analytics capabilities correlate usage and adoption signals to a named AI; AI orchestration layers stamp the Passport ID onto each orchestrated run so every invocation is traceable; and AI cost management / FinOps platforms attribute spend to an owned AI for chargeback and budget control. In each case the governance record, the outcome, the activity, and the cost all resolve to the same identity—turning isolated platform data into a coherent, attributable picture of the AI estate.

Watermarking, model identifiers, and content provenance solve a different layer than a passport. They are complements, not alternatives.

A watermark can help determine where an output came from. It does not, by itself, identify the accountable business owner, authorized use, assessment status, deployment, or lifecycle state of the system that produced it. Content provenance can therefore be referenced by a passport rather than treated as an alternative to one.

A registration must not accidentally look like certification. Keypass distinguishes between the following claim states:

• Registered — a passport exists and is owned by an organization.
• Ownership verified — the stated owner has been confirmed.
• Claim self-attested — the owning organization asserts the claim itself.
• Claim attested by a named third party — an identified external party asserts the claim.
• Independently assessed — the claim was evaluated against an external standard or method.
• Currently approved — the system is authorized for its intended use at this time.
• Expired, revoked, superseded, or retired — the claim or passport is no longer current.

For each claim, documentation should explain who made it, what evidence supports it, its scope, issue date, expiration date, and revocation state. This distinction matters to governance buyers: registration is accountability, not endorsement.

A dedicated guide for governance consultancies. The services workflow:

1. Create a passport during discovery.
2. Use the Passport ID throughout assessment documentation.
3. Verify the system owner and intended use.
4. Publish selected assessment conclusions as attestations.
5. Transfer administration to the client.
6. Schedule reassessment or attestation expiry.
7. Allow downstream governance tools to reference the passport.

Assessment handoff template. A minimal JSON shape a services firm can hand to a client so the passport is usable on day one:

{
  "passport_id": "ai_pspt_7F3A92K1",
  "system_name": "Customer Service Agent",
  "owner": "VP Customer Operations",
  "intended_use": "Tier-1 triage and routing",
  "attestations": [
    {
      "claim": "Assessment complete",
      "attested_by": "Northbridge AI Advisory",
      "attested_at": "2026-02-10T00:00:00Z",
      "expires_at": "2026-08-10T00:00:00Z"
    }
  ]
}

Small, outcome-oriented recipes—each reproducible against the public API.

1. Add a Passport ID to an AI inventory. Store the Passport ID as the external identifier on each AI record; join inventory exports to the registry by ID.
2. Create a passport when an assessment starts. Call the register endpoint from your assessment tool's intake workflow; reference the returned ID in all assessment artifacts.
3. Verify passport status in CI/CD. In a deploy gate, call the verify API with the build's Passport ID; fail the gate on registered: false or a non-active status.
4. Prevent deployment when an attestation has expired. Treat attested: false or an expired status as a hard block before promotion to production.
5. Add a passport reference to a model card. Include the Passport ID and a verification deep link in the model card header so readers can confirm identity.
6. Connect an AI gateway event to a registered system. Send the Passport ID on each request via the X-AI-Keypass-ID header; resolve and log it against the registered system.
7. Reconcile records across two governance platforms. Join both platforms' inventories on Passport ID; flag records present in one but missing in the other.
8. Export a customer-facing verification link. Build a link to /p/<passport_id> so customers verify approved claims independently.

Stating the boundary clearly makes the proposition easier to understand:

• Keypass does not discover every AI system automatically.
• It does not inspect model behavior.
• It does not certify regulatory compliance.
• It does not watermark generated content.
• It does not replace governance workflows.
• It does not guarantee that a registered claim is true.

AI Keypass identifies systems and provides a structured mechanism for attributable, time-bound, verifiable claims. That boundary is the proposition: a shared, accountable identity layer that your governance, assessment, and verification tools operate on.

1. Register — create the permanent identity.
2. Identify — reference the Passport ID anywhere.
3. Verify — confirm the registration is current.

Start with known production AI. Don't attempt to solve the entire enterprise immediately.

Provide an AI name, type, purpose, owner, and environment. Everything else is optional. Registration immediately creates the Passport and displays its permanent Passport ID.

Every Passport carries a tags array — short labels you attach to a record. Tags are the supported way to track organization-specific attributes that the canonical schema doesn't have a dedicated field for, like region, cost center, project code, or compliance scope.

Why tags instead of custom fields. The Passport schema is intentionally fixed so that the registry, the public API, and every integration share one stable shape. Renaming or adding core fields per organization would break API contracts, fragment reporting, and make every registry a snowflake. Tags give you the flexibility without that cost: the schema stays canonical, your taxonomy stays yours.

The convention. Use a key:value pattern so tags stay queryable and unambiguous. A few examples:

• region:emea — where the AI operates.
• cost-center:402 — for chargeback or budget mapping.
• compliance:hipaa — a regulatory scope the AI touches.
• project:atlas — an internal initiative the AI belongs to.
• vendor:acme-llm — a procurement or vendor-provided AI marker.

Where they show up. Tags are searchable from the Registry search bar, included in CSV exports, and accepted on both the in-app register form and the API register endpoint. The API treats them as a simple string array — send each tag as its own element, e.g. ["region:emea", "compliance:hipaa"]. In CSV import, separate multiple tags with a semicolon (region:emea;compliance:hipaa).

What tags are not. Tags are descriptive metadata on the identity record — they don't change a Passport's status, owner, or attestation, and they aren't a substitute for the required fields. Keep them short and consistent across your registry so they stay useful for filtering and reporting.

Every Passport receives a globally unique, non-sequential, immutable identifier such as ai_pspt_7F3A92K1.

The pspt segment marks this as a Passport credential — the identity record at the core of AI Keypass.

Passport IDs are URL-safe, difficult to guess, never reused, and not derived from customer-sensitive information. A deleted or revoked Passport ID is never assigned to another AI.

Attestation is deliberately lightweight. Periodically, an authorized member is asked: is this information still accurate?

Attestation records who attested, when, and to which version. It means the record was reconfirmed — it does not mean compliance, safety, or certification.

What you are attesting to

An attestation is a dated assertion that the information contained in a specific version of the Passport accurately describes the registered AI to the best of the attestor's knowledge. This includes the AI's recorded identity, ownership, purpose, operational details, lifecycle status, and other metadata present in that version. The attestation applies only to that Passport version; it is not a general guarantee about every future configuration or use of the AI.

Who makes the assertion

The attestation is made by the identified user shown in the attestation history, acting on behalf of the organization that owns the Passport. Within an organization, any member except a viewer may attest — not only the named owner on the record. Keypass records the individual, organization, time, and Passport version so a verifier can determine who stood behind the information and when.

What a current attestation means

A current attestation means that an authorized person recently reconfirmed the identified Passport version. It gives governance systems, customers, partners, and auditors a time-bound indication that the owning organization still stands behind the record.

What it does not mean

Keypass does not independently inspect the AI system or determine that the attested information is true. An attestation is not a safety evaluation, regulatory approval, risk assessment, compliance certification, or guarantee of system behavior.

When the AI changes

If the Passport no longer accurately describes the AI, edit the Passport. Editing creates a new version that updates the recorded content — but it does not re-attest. Attestation is an explicit act of reconfirmation: a named person consciously saying "this is still accurate." Treating a tag fix or typo correction as an implicit attestation would let any edit silently refresh the trust clock without anyone actually reviewing the record. So editing leaves last_attested_date and expiration_date exactly where they were. The version number and audit history preserve what changed and when; to refresh the attestation clock after an edit, use Attest.

To make this drift visible to verifiers, each Passport records an attested_version — the version number that was last explicitly confirmed. When you attest, it is set to the current version; when you edit, it stays put. Verification surfaces current_version_attested: true when the version being checked matches the attested version, false when the content has changed since the last confirmation. This lets a verifier distinguish a record that is current and confirmed from one whose content has drifted — even before the attestation clock expires.

What "attested" means in the API. The verify response carries three attestation-related fields, and they answer different questions:

A Passport can show attested: true (the clock hasn't expired) while current_version_attested: false (the content was edited since the last confirmation). Both must be true for reliably_current. The attested field is retained for backward compatibility; new integrations should gate on reliably_current.

When an attestation expires

Expiration means the organization has not reconfirmed the Passport within its selected attestation period. The Passport ID continues to exist and is never reassigned, but verifiers can see that the record is no longer currently attested. Re-attesting establishes a new confirmation date and applies the organization's current attestation period.

Lifecycle states

Example

A customer-support agent was attested on March 1 as Passport version 2, establishing an attestation valid through the organization's configured period. On June 10, its owner and model information were updated, creating version 3. The edit updated the content but did not re-attest — the March 1 attestation still governs the expiration clock. If nobody explicitly re-attests, the Passport goes expiring and then expired on the original schedule, regardless of the edit. When the owner reviews version 3 and clicks Attest, a new attestation record is created for version 3 and the clock refreshes. The permanent Passport ID did not change, and the attestation history — visible to organization members — records both who attested to version 2 and who later reconfirmed version 3.

Attestation answers a narrow but important question: who last confirmed that this specific version of the Passport accurately described the AI, and when? It confirms the currency and accountability of the identity record — not the safety, compliance, or performance of the AI itself.

Reminders. Before a Passport's attestation expires, Keypass emails the organization's configured reminder recipients a single digest of everything needing re-attestation — one message per organization, not one per AI. By default that's the organization's owners and admins; each Passport's registered owner is also included when they're an active member in a reminder-eligible role (an admin can add member to the recipient roles, or disable reminders entirely, in Settings → Lifecycle). Reminders go only to currently-active members, so people who've left the organization aren't contacted, and each Passport is nudged at most once per cycle. Re-attesting or revoking keeps the registry current.

A methodology, not a maintenance task. The periodic cadence is the point. A registry that updates itself silently is a spreadsheet; a registry that an owner reconfirms on a rhythm is a governance practice. Asking a human to periodically assert "this is still my AI, and this is still what it does" is what keeps the record authoritative — and it's the foundation any stronger governance methodology (risk review, compliance evidence, audit) builds on. Keypass doesn't replace your governance process; it gives that process a stable, accountable identity to operate on.

Assurance is a read-only organizational dashboard that turns the registry into an operational health view — not a new data source, but a different lens on the Passports you've already registered. It answers: is our attestation practice keeping up with our AI estate?

Who sees it. Organization owners and admins. Members and viewers do not — it's a management surface, not a general registry view. The link appears in the sidebar (Gauge icon) only for those roles.

What it shows.

• Coverage — the percentage of in-scope Passports that are attested and within their attestation period (current or due soon). Shown as "—" when there are no in-scope Passports yet. Note this does not factor in version drift — a Passport can be covered but still drifted; that's what the drift metric is for.
• Version drift — Passports whose content has been edited since the last explicit attestation. These need a fresh attest to be reliably current again.
• Past due — Passports whose attestation period has expired. These are the most urgent; their registration is no longer current.
• Due soon — Passports attested but expiring within 30 days. These are your proactive queue.
• Attestations in period — how many attestations were completed in the selected activity window, with a 6-month trend chart.

Posture groups. Every in-scope Passport falls into one of four postures: current, due soon, past due, or never attested. Revoked Passports appear as a fifth group for visibility but are out of active governance scope. Click any posture group — or any KPI card — to filter the drill-down table to just those Passports.

Breakdowns. Passports are grouped by owner and by AI type, each sortable by count (high to low or low to high) and paginated at 10. The counts reflect total in-scope Passports per owner or type — they don't re-filter when you apply a posture or KPI filter. Click a row to filter the drill-down table to that owner or type. The By Owner view is useful for workload distribution: it shows which owners are responsible for the most Passports, so you know where attestation volume is concentrated.

Activity period. The "Attestations in period" KPI and its trend chart count attestations completed in a selectable window: this month, a rolling 30 days, or a custom date range. The trend chart itself always shows the last 6 months regardless of the selected window.

What's excluded. Archived Passports are excluded from all counts, posture groups, and breakdowns — they're no longer in active governance scope. The dashboard reads from the same Passport and Attestation records as the Registry; it doesn't store anything separately.

One AI. Many IDs. One canonical identity.

Every enterprise system identifies a different piece of an AI — the cloud resource it runs on, the model digest it uses, the cost tag that bills it, the workload identity that authenticates it, the GRC record that governs it. Each system knows its piece. Keypass knows which AI the pieces belong to.

The Passport is the cornerstone: a persistent, human-owned, attested identity that every surrounding record maps to. It does not replace native, runtime, access, governance, security, or financial identities — it binds them to one recognized AI, one owner, and one current registration. Each surrounding record maps to the persistent Passport ID, and Keypass becomes the identity spine for enterprise AI trust.

The seven identity domains

These are the domains a single AI typically appears in. The trust_domain field on each linked identity binding categorizes which domain it belongs to — native, runtime, access, governance, security, finops, data, or vendor — so the binding graph is queryable by domain, not just by system.

Why Keypass is the cornerstone

Every system knows its piece. Keypass knows which AI the pieces belong to. It does not replace native, runtime, access, governance, security, or financial IDs — it binds them to one recognized AI, one owner, and one current registration. Each surrounding record maps to the persistent Passport ID, and Keypass becomes the identity spine for enterprise AI trust.

This is the conceptual foundation for linked identities: the feature that implements the map by letting you bind each of those external identifiers to a Passport and resolve them back.

A Passport is the canonical identity for an AI, but that AI also exists in other systems — a Vault entity, a SPIFFE workload identity, a deployment name, a cost-allocation tag. Linked identities (identity bindings) connect those external identifiers to a Passport so a single record stays authoritative across your stack.

Keypass is the canonical AI identity and resolution layer. Bindings are how that resolution works in reverse: an external identity in any system maps back to the registered, owned AI the organization recognizes and holds someone accountable for. Bindings are org-scoped and live on the Passport detail page. Any non-viewer member can add, edit, flag, or remove them — and external platforms can bind themselves programmatically via the API.

Progressive trust levels

A binding is not a binary "verified / not verified." It carries a trust level that strengthens as the mapping is confirmed. This mirrors the philosophy behind attestation: identity gets stronger when a person stands behind it.

Canonical system names

Every common system has a canonical slug that is stored on the binding, while the UI displays a human-readable label. This prevents the same system from fragmenting into multiple identities — Vault, HashiCorp Vault, hashicorp_vault, and HASHICORP_VAULT all normalize to hashicorp_vault. That normalization is what makes uniqueness and reverse resolution reliable: the same external identity always lands on the same binding.

External identifiers follow per-system case rules. Most are case-sensitive (UUIDs, ARNs, hex digests) and are preserved as-is; a few systems (e.g. GitHub repositories) are case-insensitive and are lowercased so casing variants don't create duplicate bindings. Keypass does not globally lowercase every external ID — that would corrupt case-sensitive identifiers.

Custom systems are allowed. They are normalized to a stable slug so they participate in uniqueness and resolution the same way canonical systems do.

Attestation integration

When a Passport has active bindings, the Attest button opens a confirmation modal listing every linked identity — each pre-checked. The owner can confirm all, uncheck to skip, flag one for review, remove one that no longer applies, or add a missing identity on the spot. Confirmed bindings are marked owner-attested with an updated last_verified_at.

This step is non-blocking. If the owner skips every binding — or if the Passport has none — attestation completes exactly as before. The binding confirmation is an opportunity to strengthen trust, not a gate that prevents attestation.

Reverse resolution

The complement of binding is resolving an external identity back to its Passport. A model gateway that knows a Vault entity made a request can call the resolve endpoint to find out which registered, owned AI that entity belongs to — turning an opaque system identifier into an accountable identity.

GET /functions/api/v1/resolve?system=<system>&external_id=<id> with header x-api-key (scope passport:resolve). Returns the parent Passport and the matching binding, or 404 when no active binding matches within your org. The call is scoped to the key's owning organization — you can only resolve identities your org has bound.

Resolution succeeding is not the same as the binding being trustworthy. A declared binding resolves but hasn't been confirmed; a flagged binding resolves but signals low confidence. Gate on the trust level, not just existence — see the Gateway Interceptor pattern in the Developer Community for observe / warn / enforce modes.

Programmatic binding lifecycle

External platforms — a Vault, cloud provider, GRC system, or FinOps tool — should not require a person to create every mapping in the UI. The binding lifecycle API lets integrations create, list, update, and remove bindings programmatically.

POST /functions/api/v1/passports/bindings with header x-api-key (scope passport:bindings) and a JSON body { "action": "create" | "list" | "update" | "delete" | "transfer", ... }:

• create — { "action": "create", "passport_id": "ai_pspt_…", "fields": { "system": "hashicorp_vault", "external_id": "fe2a8568-…", "trust_domain": "Access", "environment": "Production" } }. Creates a declared binding. The system is normalized to a canonical slug; the external_id follows per-system case rules.
• list — { "action": "list", "passport_id": "ai_pspt_…" }. Returns all bindings (active and removed) for that Passport.
• update — { "action": "update", "binding_id": "…", "fields": { "environment": "Staging" } }. Updates editable fields; omitted fields are left untouched.
• delete — { "action": "delete", "binding_id": "…" }. Marks the binding removed (preserved in the audit trail).
• transfer — { "action": "transfer", "binding_id": "…", "passport_id": "ai_pspt_…", "reason": "…" }. Moves a binding from one Passport to another (see below).

A key-authenticated call is scoped to the key's owning organization and cannot touch another org's bindings. Create, update, delete, and transfer require an active platform subscription; list does not.

Conflict and transfer

The same external identity — the combination of system and external identifier — can be bound to at most one Passport within your organization, enforced server-side. When a create would collide with an existing binding, the response doesn't merely fail. It surfaces the current owning Passport, its status (active, expired, revoked), when the binding was last confirmed, and the system + external ID — so the caller can decide whether to transfer.

A transfer requires a reason, supersedes the old binding (marks it removed), creates the new relationship on the target Passport, writes both events to the audit history, and resets the new binding's trust to declared until it is re-attested. This turns a conflict from friction into useful identity reconciliation — the kind of thing that happens when a Vault entity is reassigned during a service migration.

Bulk import

Organizations adopting Keypass often already have hundreds of cloud resource IDs, GRC records, model registry IDs, repositories, CMDB configuration items, and cost tags. The in-app bulk importer accepts a CSV with columns key_id, system, trust_domain, identity_type, external_id, environment, external_url, validates and normalizes each row, surfaces per-row conflicts (with the current owning Passport), and creates declared bindings in one batch. A template can be downloaded from the import dialog.

Binding economics

Linked identities are included with each registered Passport. Adding a binding does not consume another Registry Credit. You want customers to add as many useful relationships as possible — binding volume creates value and defensibility, so charging per binding would discourage the behavior that makes Keypass harder to replace. Unusually large volumes, batch resolution, and high API throughput are reserved for enterprise tiers without charging for normal relationships.

What it is not

Linked identities are a declarative mapping confirmed by a human — not a cryptographic proof that the running workload possesses the credentials to prove it is the bound identity. That runtime binding (signed assertions, key proof-of-possession) is the roadmap's Phase 3. Today, bindings answer "which Passport does this external ID map to?" — they do not answer "is the caller cryptographically who they claim to be?"

Keypass also does not ingest the external system's data. The binding stores only the system name (as a canonical slug), the external identifier, and optional metadata (trust domain, identity type, environment, deep link). No secrets, tokens, or configuration from the source system are stored.

AI Keypass uses a hybrid access model: a platform subscription keeps the registry writable, while Registry Credit Packs pay for registration volume (1 credit = 1 Passport).

What the subscription gates. Write operations — registering a new Passport, editing, and revoking — require an active platform subscription. Attestation is allowed during the subscription's grace window, since it keeps existing registrations current. Reads are always free: the registry stays readable, verification is always available, and public Passport pages keep working regardless of subscription state. Registered Passports are never affected by subscription status.

Credits vs. subscription. Credits are a one-time consumable for registration volume — they register new Passports and are independent of the subscription. The subscription is the recurring access layer that keeps the platform writable. An org can hold credits and still need an active subscription to spend them on new registrations; an active subscription doesn't grant free registrations.

Early-adopter program. Every new organization receives a free platform subscription for its first year — no payment, no setup. After the free year, a grace window applies (writes pause, attestation keeps working, reads stay open). A paid platform subscription will follow; early adopters will be notified before it takes effect.

Future Stripe integration. Paid subscriptions are not yet billed. The data model and UI are in place so a future phase adds a Stripe subscription product, checkout, and webhook handler without changing the access model described here.

Registry Credit Packs are one-time purchases: 1 credit = 1 Passport registration. They fund registration volume and are independent of the platform subscription — an active subscription keeps the registry writable, while credits pay for each new Passport you register.

Shelf life. Purchased credits are valid for 12 months from purchase. When a credit pack expires, any remaining purchased credits are removed from your balance — they don't linger as unspendable placeholders. Already-registered Passports are unaffected: a Passport you registered with a credit stays in the registry, stays verifiable, and keeps its identity no matter what happens to your credit balance.

Stacking on re-purchase. Buying a new pack adds its credits to your current balance and extends the expiry of your remaining credits to 12 months from the new purchase. So topping up before an existing pack expires both adds credits and refreshes the shelf life of what you already hold.

Gift credits never expire. Credits granted as support gifts are separate from purchased packs — they carry no expiration date and remain available even after a purchased pack has expired. They're spent first, before purchased credits, so gifted volume is always used before paid volume.

Credits vs. subscription, restated. Credits are a consumable you spend down; the subscription is recurring access. An org can hold credits and still need an active subscription to spend them on new registrations, and an active subscription doesn't grant free registrations. They're priced and purchased separately on purpose: one pays for volume, the other pays for the platform being there.

A person or system can provide a Passport ID and receive a minimal response confirming whether the Passport exists and its registration is current.

Verification answers one question: does this Passport exist and is its registration current? Sensitive metadata is never exposed unless explicitly authorized by the organization's privacy settings.

AI Keypass is API-first. The public, versioned surface covers verification, registration, management (attest, edit, revoke), and inventory listing. The same operations are also available to authenticated organization members through the in-app SDK.

Quickstart

Verify a Passport ID from any shell:

curl "https://aikeypass.com/functions/api/v1/passports/verify?id=ai_pspt_7F3A92K1" \
  -H "x-api-key: aip_live_…"

A successful response confirms existence, status, and attestation recency:

{
  "passport_id": "ai_pspt_7F3A92K1",
  "registered": true,
  "status": "active",
  "attested": true,
  "current_version_attested": true,
  "reliably_current": true,
  "last_attested_at": "2026-08-12T20:00:00Z"
}

Authentication

Verification is optional auth. Anonymous requests receive the public-level response. Supply an API key in the x-api-key header (or api_key body field) to identify your verifier and unlock member-level detail for your own organizations. Keys are 224-bit random secrets created in Settings → API Keys, stored only as a SHA-256 hash, and carry scopes:

• passport:verify — call the verify endpoint.
• passport:register — register Passports via the public register endpoint.
• passport:update — edit and revoke Passports via the manage endpoint.
• passport:attest — attest Passports via the manage endpoint.
• passport:read — list the owning organization's Passports via the list endpoint.
• passport:resolve — reverse-resolve an external identity to its Passport via the resolve endpoint.
• passport:bindings — create, list, update, delete, and transfer linked-identity bindings via the bindings endpoint.

Scopes are namespaced passport:* because they operate on the Passport credential — the identity record each AI carries. As the platform adds capabilities, additional scope namespaces may follow.

Verify endpoint

GET /functions/api/v1/passports/verify?id=<passport_id> — or POST with JSON { "passport_id": "…", "api_key": "…" }. The id (or passport_id) parameter is the Passport ID. Private organizations reveal only existence and status unless the caller is a member. The response includes three attestation-related fields:

• current_version_attested — true when the Passport's current version matches the version that was last explicitly attested, false when the content has been edited since the last confirmation. Always present in the response.
• attested — true when the attestation period is current (unexpired). Does not confirm the current version was attested. Deprecated in favor of reliably_current; retained for backward compatibility. Only present for public organizations or org members.
• reliably_current — the composite a verifier should gate on: attested == true AND current_version_attested == true. Revocation is folded in (a revoked passport has attested: false). Only present for public organizations or org members.

Register endpoint

POST /functions/api/v1/passports/register with header x-api-key (scope passport:register) and a JSON body { "record": { "name": "…", "type": "…", "purpose": "…", "owner_name": "…", "environment": "…" } }, or { "records": [...] } for bulk. Returns the created Passports with their permanent Passport IDs and remaining credits. Each registration consumes 1 Passport credit. Supply a Keypass-Idempotency-Key header (any UUID) so a retried request returns the cached result instead of registering a duplicate.

Manage endpoint

POST /functions/api/v1/passports/manage with header x-api-key and body { "action": "attest" | "edit" | "revoke", "passport_id": "ai_pspt_…" }. The Passport may be referenced by its public Passport ID or its entity id. Required scope: passport:attest to attest, passport:update to edit or revoke. A key-authenticated call is scoped to the key's owning organization and cannot touch another org's Passports.

For edit, include a fields object with any subset of the editable metadata (name, type, purpose, owner_name, environment, business_unit, provider, model, repository_url, application_url, internal_reference, data_classification, description, tags). Omitted fields are left untouched; required fields (name, type, purpose, owner_name, environment) cannot be blanked. Each successful edit bumps the Passport version but does not re-attest — attestation remains an explicit act (see Attestation); use the attest action to refresh the attestation clock and set attested_version to the current version

{ "action": "edit", "passport_id": "ai_pspt_7F3A92K1",
  "fields": { "purpose": "Updated purpose statement", "model": "gpt-4o-2024" } }

Error responses

All errors return a JSON body with an error field and an appropriate HTTP status:

400  { "error": "Missing passport_id" }
401  { "error": "Unauthorized" }            // management endpoints only
402  { "error": "Insufficient Passport credits", "available": 0, "requested": 1 }
403  { "error": "Forbidden: not a member of this organization" }
200  { "registered": false, "status": "unknown", "current_version_attested": false }  // no Passport found for that ID
429  { "error": "Rate limit exceeded", "retry_after": 30 }
500  { "error": "Verification failed" }

Rate limiting

Keys are 224-bit random secrets, so brute-force is infeasible — but request flooding is throttled at the network edge (CDN/WAF) rather than in-application. A 429 response includes a retry_after hint in seconds. Clients should retry with exponential backoff. Configure per-key and per-IP limits at the edge for your expected volume.

Idempotency

Registration calls accept a Keypass-Idempotency-Key header. Supply a client-generated UUID; the server caches the result of that key for 24 hours and returns the cached response on retry, so accidental double-submits never register the same AI twice. Keys are scoped to the calling organization.

List endpoint

GET /functions/api/v1/passports/list with header x-api-key (scope passport:read) enumerates the calling key's owning-org Passports. Optional query params: status (one of active|expiring|expired|revoked|archived — a post-derivation filter), limit (default 100, max 500), and sort (-updated_date default, -created_date, -last_attested_date, or name). A key-authenticated call is scoped to the key's owning organization and cannot enumerate another org's Passports. Derived statuses (expiring/expired) are computed from expiration_date server-side.

curl "https://aikeypass.com/functions/api/v1/passports/list?status=expiring&limit=50" \
  -H "x-api-key: aip_live_…"

A successful response returns the org's Passports with derived statuses:

{
  "organization_id": "…",
  "count": 2,
  "total": 14,
  "passports": [
    { "passport_id": "ai_pspt_7F3A92K1", "name": "Claims Assistant",
      "type": "Agent", "status": "expiring",
      "current_version_attested": true, "reliably_current": true,
      "last_attested_date": "2026-02-10T…", "expiration_date": "2026-08-30T…" }
  ]
}

This is what makes the registry observable to machines — inventory sync, attestation dashboards, and reconciliation against what's actually deployed. Field-level search is still on the roadmap. The list endpoint enumerates and filters today; full-text and field-specific search across the registry will follow, with cursor pagination for large orgs.

Resolve endpoint (linked identities)

GET /functions/api/v1/resolve?system=<system>&external_id=<id> with header x-api-key (scope passport:resolve) performs reverse resolution: given an external identity (a Vault entity, a SPIFFE ID, a deployment name), it returns the parent Passport and the matching binding. A key-authenticated call is scoped to the key's owning organization — you can only resolve identities your org has bound, so there is no cross-org leakage. Returns 404 when no active binding matches within your org.

curl "https://aikeypass.com/functions/api/v1/resolve?system=hashicorp_vault&external_id=fe2a8568-91cc-…" \
  -H "x-api-key: aip_live_…"

A successful response returns the Passport and the binding's trust level:

{
  "key_id": "ai_pspt_7F3A92K1",
  "name": "Claims Assistant",
  "status": "active",
  "owner": "Priya Patel",
  "binding": {
    "system": "hashicorp_vault",
    "identity_type": "Vault entity",
    "external_id": "fe2a8568-91cc-…",
    "environment": "Production",
    "status": "owner_attested",
    "last_verified_at": "2026-08-12T20:00:00Z"
  }
}

Bindings carry a progressive trust level — declared (added by a member), owner_attested (confirmed during attestation), system_verified (reserved for future automated verification), stale (flagged for review), or removed. Only active (non-removed) bindings resolve. The same org + system + external_id can be bound to at most one Passport, enforced server-side, so reverse resolution always lands on a single authoritative record.

Bindings endpoint (programmatic lifecycle)

POST /functions/api/v1/passports/bindings with header x-api-key (scope passport:bindings) and a JSON body { "action": "create" | "list" | "update" | "delete" | "transfer", ... }. External platforms can bind themselves programmatically — a Vault, cloud provider, GRC, or FinOps integration should not require a person to create every mapping in the UI.

Actions:

• create — { "action": "create", "passport_id": "ai_pspt_…", "fields": { "system": "hashicorp_vault", "external_id": "fe2a8568-…", "trust_domain": "Access", "environment": "Production" } }. Creates a declared binding. The system is normalized to a canonical slug; the external_id follows per-system case rules.
• list — { "action": "list", "passport_id": "ai_pspt_…" }. Returns all bindings (active and removed) for that Passport.
• update — { "action": "update", "binding_id": "…", "fields": { "environment": "Staging" } }. Updates editable fields; omitted fields are left untouched.
• delete — { "action": "delete", "binding_id": "…" }. Marks the binding removed (preserved in the audit trail).
• transfer — { "action": "transfer", "binding_id": "…", "passport_id": "ai_pspt_…", "reason": "Vault entity reassigned during migration" }. Moves a binding from one Passport to another: supersedes the old binding, creates the new relationship with trust reset to declared, and writes both events to the audit history. A conflict response from create includes the current owning Passport, its status, last-verified time, and the conflicting binding ID — so the caller can decide whether to transfer.

A key-authenticated call is scoped to the key's owning organization and cannot touch another org's bindings. create, update, delete, and transfer require an active platform subscription; list does not. System names are normalized to canonical slugs (hashicorp_vault, spiffe, aws_iam, …) so uniqueness and reverse resolution stay reliable; custom systems are allowed and slugified. External identifiers follow per-system case rules — most are preserved as-is, a few (e.g. GitHub) are lowercased.

Bulk binding import

For organizations that already have hundreds of cloud resource IDs, GRC records, model registry IDs, or CMDB configuration items, the in-app bulk importer (Linked identities → Import on any Passport detail page) accepts a CSV with columns key_id, system, trust_domain, identity_type, external_id, environment, external_url. Each row is validated, normalized, and checked for conflicts — successful rows create declared bindings in one batch. Per-row conflicts surface the current owning Passport so they can be transferred. Bindings do not consume Registry Credits.

Webhooks (roadmap)

Roadmap. Lifecycle events — passport.created, passport.updated, passport.attested, passport.expiring, passport.expired, passport.revoked — will be delivered as POST JSON to your registered endpoint. Each delivery is signed with a keypass-signature header: an HMAC-SHA256 of the raw body using your endpoint's signing secret. Verify it before processing:

expected = hmac_sha256(signing_secret, raw_body).hex()
if expected != request.headers["keypass-signature"]: return 401

Failed deliveries are retried with exponential backoff (1s, 5s, 30s, 2m, 10m, 1h) up to 24 hours, then marked failed. Acknowledge with a 200; anything else triggers a retry.

OpenAPI (roadmap)

Roadmap. A machine-readable OpenAPI 3.1 specification will be published once the public REST surface (verify, register, manage, and list) stabilizes, so the spec can't drift from the implementation:

# Download the spec (planned public URL)
curl https://aikeypass.com/openapi.yaml -o keypass-openapi.yaml

Verify, register, manage (attest, edit, revoke), and list are available on the public REST surface today; field-level search and the machine-readable OpenAPI spec are on the roadmap. The in-app SDK additionally exposes these operations to organization members.

Passport IDs are designed to be referenced by GitHub, GitLab, Azure DevOps, ServiceNow, Jira, cloud providers, model gateways, CI/CD systems, GRC platforms, CMDBs, procurement systems, and AI development frameworks.

The initial engineering focus is the API, with webhook delivery on the roadmap so external products can integrate cleanly. Planned webhook events are namespaced to the Passport credential — passport.created, passport.updated, passport.attested, passport.expiring, passport.expired, and passport.revoked — so a single event stream would describe the lifecycle of one AI's identity.

Process mining & business process automation

Process-mining and BPA tools — such as Celonis, SAP Signavio, and IBM Process Mining — model how work moves through your organization, including the steps performed by AI. AI Keypass is the identity layer that connects those automated steps to a registered, accountable AI. Integration works in two directions:

• Keypass → BPA (enrichment). A process-mining tool that knows an automated step ran can resolve it to a Passport via the public verify API or a batch registry export — turning "automated by system X" into "performed by registered, attested AI Y, owned by team Z." This adds accountability and data-classification context to process events without the BPA vendor building its own identity model.
• BPA → Keypass (continuous attestation). Process-mining event logs are ground truth for whether an AI is actually in use. Feeding lightweight usage signals back into AI Keypass can drive lifecycle automation — flagging AIs absent from any process for review or archival, or triggering re-attestation when an AI appears in a new process or scope. This aligns with AI Keypass's existing attestation and expiration model, and it requires no ingestion of prompts, outputs, or source code.

CI/CD & source control

Source-control and CI/CD tools — such as GitHub, GitLab, and Azure DevOps — are where AI gets built and shipped. Tag a pipeline or repository with its Passport ID (for example as a build variable or workload label), and every run is traceable to a registered, accountable AI. A deploy gate can call the verify API to confirm the AI's registration is active and attested before promoting to production — turning "some automated job" into a named, owned AI in your release history, with no prompts or source code ingested.

ITSM & ticketing

ITSM and ticketing tools — such as ServiceNow and Jira — manage changes, incidents, and work that increasingly involves AI. Attach the Passport ID to a change record, incident, or ticket, and verifiers resolve it to the owning team and registration status. A change advisory board can require a verified, active Passport before approving an AI-driven change, and post-incident review links the event back to a specific registered AI rather than an anonymous automation.

GRC & governance platforms

GRC tools — such as AI Governr, ServiceNow GRC, and Archer — need an authoritative inventory to operate on. AI Keypass is that inventory's identity layer: export the registry (or call the list API) to reconcile it against a GRC platform's risk register, control catalog, or policy scope. Ownership, environment, data classification, and attestation recency flow straight in, so governance teams assess real, registered AIs instead of a spreadsheet that drifts. Keypass doesn't score risk or enforce policy — it gives those systems a stable, accountable record to score and enforce against.

CMDBs & enterprise asset management

CMDBs — such as ServiceNow CMDB and BMC Helix — already track servers, services, and applications; AI is often missing or misclassified. Treat a Passport as the configuration item (CI) record for an AI — syncing the Passport ID, owner, environment, and lifecycle status into the CMDB keeps the AI estate consistent with the rest of the asset graph. Reconciliation runs in either direction: the CMDB can verify a Passport to confirm an AI is still registered and owned, and a revoked or expired Passport can flag a CI for review.

Model gateways & agent runtimes

Model gateways and inference platforms — such as LiteLLM, Kong, and Portkey — route the requests AI actually makes. Send the Passport ID on each request (the X-AI-Keypass-ID header convention), and the gateway resolves it to a registered, accountable AI before routing — refusing or flagging requests that claim an unregistered or revoked identity. This identifies the claimed AI at the point of use; it does not authenticate the calling workload, which is the subject of the roadmap's cryptographic-binding phase.

Procurement & vendor management

Before onboarding a vendor AI through tools like Coupa or SAP Ariba, procurement can check whether it already has a Passport — and require one as a condition of contract. A vendor's Passport gives you a durable identifier to reference in the MSA, a named owner on the vendor side, and a registration you can re-verify over the life of the relationship. When the AI changes scope or ownership, the vendor re-attests; you re-verify. No ingestion of the vendor's prompts, data, or internals is required.

Agent & assistant platforms

Agent builders and assistant frameworks — such as OpenAI Assistants, Microsoft Copilot Studio, and LangChain — are where AI is increasingly assembled and shipped. Give each deployed agent or assistant its own Passport and stamp the Passport ID onto its runs, traces, or manifests. The platform can then resolve any agent invocation back to a registered, owned AI, and a registry query answers "which agents exist here, and who owns each one" without inventing a parallel identity model. This is also the natural on-ramp: an assistant platform that registers every agent it ships becomes a source of Passports your other systems can verify.

Observability, discovery & AIOps

Observability and AIOps tools — such as Datadog, LangSmith, and Splunk — see the AI that's actually running, which the registry may not. Correlate traces and metrics to a Passport ID so an alert, a spike, or an incident references a named, accountable AI rather than an anonymous endpoint. Reconciling what observability sees against what the registry records is also the cleanest way to surface shadow AI — systems running in the wild that were never registered — so they can be brought into the registry or revoked. AI Keypass supplies the identity; the observability layer supplies the signal.

FinOps & AI cost management

FinOps and AI cost-management platforms — such as Apptio Cloudability and Vantage — attribute spend to workloads, but AI spend is often anonymous — "model calls," "token usage," "agent runtime" with no owner. Tag cost records with the Passport ID (or join on it), and every dollar maps to a registered, owned AI. Chargeback rolls up by owner, environment, or a tag like cost-center:402 rather than a generic model bill, and budget owners can see which registered AIs are driving their spend. The registry stays the identity source of truth; FinOps stays the cost source of truth; the Passport ID is the join key.

AI value management

Tying identity to AI value management is what turns an inventory into a measured investment. Value-management and AI-ROI programs track outcomes — adoption, business impact, cost-to-value — but only against known, attributable systems. Joining those outcome records to a Passport ID means every measured result maps to a registered, owned AI, so ROI can be validated rather than estimated and a deprecated or revoked Passport can be excluded from value reporting so it stops crediting (or charging) systems that no longer exist. Identity is the precondition for trustworthy outcomes: you can only track and validate the return on an AI investment when you know which AI delivered it.

All of these patterns are API-based today, with webhook events on the roadmap rather than shipped as managed connectors — so enterprises and partners across CI/CD, ITSM, GRC, CMDB, model gateway, procurement, agent platforms, observability/AIOps, FinOps, and AI value management tooling can integrate on the existing passport:verify, passport:read, and passport:register APIs without waiting for a first-party build.

Identity vs. runtime authenticity. AI Keypass verifies registration status and organizational ownership — not runtime cryptographic authenticity. We confirm that an AI asset is registered in your organization's canonical registry and that its ownership is current. We do not currently validate that the running workload itself possesses the credentials to prove it is the asset it claims to be (signed assertions, key binding, or proof of possession). Our roadmap includes support for signed assertions and runtime binding, enabling Passport IDs to become verifiable, cryptographically provable credentials.

AI Keypass is designed around encryption in transit and at rest, server-side tenant isolation, least-privilege access, hashed API credentials, tamper-resistant audit logging, and input validation. The trust story: we identify your AI; we don't need to ingest your AI.

Tenant isolation. Every record belongs to an organization. Reads and writes are filtered server-side through row-level security scoped to the organizations you belong to — no organization can see or touch another's private data, and cross-organization queries are not possible through the API.

Role-based access. Within an organization, four roles apply: owner, admin, member, and viewer. Viewers can read but never create, edit, attest, revoke, invite, or manage API keys. Every create, update, and delete runs through a server-side function that re-checks the caller's membership and role before acting — the client is never trusted to enforce its own permissions. Admins and owners manage members, invitations, API keys, and organization settings.

API key security. Verification API keys are 224-bit random secrets, stored only as a SHA-256 hash. The full key is shown once at creation and never recoverable; list views show only an unguessable prefix so a key can be recognized without exposing it. Keys carry scopes — the verify endpoint requires passport:verify — and can be revoked at any time, which immediately invalidates them. Last-used time is tracked per key.

Audit integrity. Audit events — registration, edits, attestation, revocation, linked-identity binding changes, member and invitation changes, API key lifecycle — are written server-side only. Regular members cannot create or alter audit records, so the log reflects actions that actually happened, attributed to the user who took them.

Passport ID integrity. IDs are generated server-side and are globally unique, non-sequential, immutable, and never reused — including for revoked or deleted Passports. They are not derived from sensitive input.

Input handling. Form and CSV values are validated and field-typed server-side; enum fields reject out-of-range values. CSV export is sanitized against spreadsheet formula injection. URL and reference fields are stored as inert text and rendered as clickable links only when they begin with http(s).

Rate limiting. Brute-forcing Passport IDs or API keys is computationally infeasible; request flooding is throttled at the network edge (CDN/WAF) in production rather than in-application. Configure per-key and per-IP limits at the edge for your expected volume.

AI Keypass is intentionally minimal about what it stores. Identity and ownership metadata — name, type, purpose, owner, environment, and optional references — is the core. The platform does not require or accept prompts, model outputs, training data, source code, datasets, secrets, or behavioral telemetry from the AI systems it registers.

Verification minimizes exposure. A public verification returns only whether the Passport exists, its status, attestation recency, and the organization name. Identifying detail — the AI's name, type, and owner — is shown only to members of the owning organization.

Private verification mode. Organizations can set verification visibility to private. In that mode, non-member verifiers learn only that the Passport exists and its status — nothing else. This suits sensitive environments where even an AI inventory is confidential.

Retention. Revoking a Passport preserves its audit trail (who revoked, when) so accountability is never lost, and a revoked Passport ID is never reassigned. Data is stored in a managed database with encryption in transit and at rest.

Transactional email. Keypass sends operational emails to registered members only — organization invitations and pre-expiry attestation reminders. Reminder recipients are scoped to currently-active members of the owning organization; departed members are not contacted. Email bodies contain only metadata the recipient is already authorized to see (AI name, Passport ID, expiry date) — never prompts, outputs, or source code.

No behavioral surveillance. Because AI Keypass does not ingest AI activity, there is no behavioral data to leak, sell, or train on. The surface area for privacy risk is deliberately small.

1. Register — start with known production AI.
2. Identify — put Passport IDs into the systems where AI already lives.
3. Verify — allow systems and people to verify registration.
4. Attest — periodically reconfirm ownership and information.
5. Expand — register additional AI as it enters the organization.

The organizational principle becomes: no anonymous AI. The cadence — register, identify, verify, attest, expand — isn't overhead to be automated away. It's the rhythm of a mature AI governance practice, with identity as its foundation.

AI Keypass is built in deliberate phases, starting with the hardest foundational problem — a reliable identity for every AI — and progressing toward cryptographic runtime binding.

1. Phase 1 — Canonical registration (shipped). A centralized organizational registry with structured metadata, ownership, attestation, and a permanent, immutable Passport ID for every AI.
2. Phase 2 — Verification (shipped). API-driven verification of registration status, enabling Jira, ServiceNow, GRC platforms, and CI/CD systems to check whether an AI is in scope for governance before acting on it.
3. Phase 3 — Cryptographic binding (roadmap). Support for cryptographically signed identity tokens linking the Passport ID to the live workload via key binding or signed assertions — turning Passport IDs into provable credentials.

Each phase compounds on the previous one. The registry you build today becomes the anchor point your future runtime security can bind to.

Keypass is built for early adoption: a registry that's fast to stand up, simple to operate, and useful from day one. Some of today's constraints are deliberate tradeoffs that keep the platform approachable for organizations just starting their AI identity practice. As your registry grows, we'll work with you to address them.

Current limits

Why these limits exist

Each constraint reflects a choice: ship a working, simple registry first, then scale the infrastructure as real organizations hit real ceilings. A 1,000-record export cap is irrelevant to an org registering their first 20 AIs — but it keeps the query path predictable and the UI fast while the platform matures. The same principle applies to API pagination and field-level search: the operations teams need today (enumerate, filter, verify, attest) are shipped; the ones needed at enterprise scale are on the roadmap, not blocking adoption.

Enterprise & custom tier

For organizations whose registry exceeds these limits — large enterprises with hundreds or thousands of registered AIs, high-volume API consumers like model gateways calling verify or resolve on every request, or partners building managed integrations — we offer enterprise and custom-tier engagements to address them directly:

• Cursor-based API pagination for registries exceeding the list endpoint's limit.
• Higher per-key rate limits and dedicated edge configuration for high-volume verification or resolution callers.
• Full-text and field-level search ahead of the general-availability release.
• Larger binding volumes per Passport and batch resolution for identity-graph workloads.
• Webhook delivery for lifecycle events once the feature ships generally.

If you're hitting a limit, reach out — these are configuration and infrastructure changes we can make for your organization rather than waiting for the platform-wide release. Contact info@aikeypass.com to discuss your scale requirements.

A common objection is that no governance or compliance framework calls for an AI identity registry. The evidence says otherwise. Several of the most authoritative frameworks now mandate registration or inventorying by law or standard — and the ones that don't mandate it treat an AI inventory as table-stakes. What none of them prescribe is how to make that inventory portable and verifiable across systems. That gap is precisely what Keypass fills.

Where the frameworks stop short. They all say keep a registry. None of them say give each AI a persistent identity that your CI/CD pipeline, ITSM tool, GRC platform, model gateway, and CMDB can all resolve to the same record. A registry that lives only inside one team's spreadsheet or GRC tool satisfies the letter of the obligation but not its spirit — it can't be verified by the systems that actually run, deploy, or depend on the AI. Each system ends up maintaining its own parallel identity for the same AI, and the inventory drifts from reality the moment it's written.

Why Keypass is the right way. Keypass is the identity primitive the frameworks assume exists but don't define. A Passport ID is a single, durable, verifiable identifier that every system a registered AI touches can resolve to the same accountable record — owner, environment, status, attestation recency. The frameworks mandate the inventory; Keypass makes that inventory portable, cross-system, and verifiable, so it functions as more than an internal checklist. When Article 49 requires registration, the Passport is that registration, made queryable. When ISO 42001 asks for an AI system register, the registry is that register, made interoperable. When NIST GV.1.6 calls for an inventory, Keypass is the stable identifier that lets every tool in your stack reference the same entry instead of inventing its own.

Put simply: the regulatory tailwind for AI identity registration is already here. What's still nascent is the cross-system identity layer that makes those mandated registries actually work — and that's exactly what Keypass provides.