Developer Community
The registry is the foundation. These are the integration patterns that make a Passport ID part of how AI actually runs in your stack — contributed and refined by the community of architects and developers building on Keypass.
Each pattern is a copy-paste starting point. They all build on the public verify and manage endpoints.
Block unauthorized AI at the model gateway
Middleware that verifies the Passport ID on every inbound request before it reaches the model. If the Passport isn't reliably current — registered, unexpired, and on its attested version — the request never reaches the LLM.
# FastAPI middleware — verify before serving
from fastapi import Request, HTTPException
@app.middleware("http")
async def verify_passport(request: Request, call_next):
passport_id = request.headers.get("X-AI-Keypass-ID")
if not passport_id:
raise HTTPException(401, "No Passport ID supplied")
res = httpx.get(
"https://aikeypass.com/functions/api/v1/passports/verify",
params={"id": passport_id},
headers={"x-api-key": settings.KEYPASS_KEY},
)
body = res.json()
# reliably_current = attested AND current_version_attested (revocation folded in)
if not body.get("registered") or not body.get("reliably_current"):
raise HTTPException(403, "Unregistered or not current AI")
return await call_next(request)Fail the pipeline if the AI isn't registered
A pre-deployment check that refuses to ship a model or agent whose Passport is missing, revoked, expired, or whose current version hasn't been attested. The Passport ID lives next to the code, so the registry and the release stay in sync.
# .github/workflows/deploy.yml
- name: Verify AI Passport before deploy
env:
AI_KEYPASS_ID: ai_pspt_7F3A92K1
KEYPASS_API_KEY: ${{ secrets.KEYPASS_API_KEY }}
run: |
# reliably_current = attested AND current_version_attested (revocation folded in)
RELIABLE=$(curl -s "https://aikeypass.com/functions/api/v1/passports/verify?id=$AI_KEYPASS_ID" \
-H "x-api-key: $KEYPASS_API_KEY" | jq -r .reliably_current)
if [ "$RELIABLE" != "true" ]; then
echo "::error::Passport $AI_KEYPASS_ID is not reliably current"
exit 1
fiMachine-generated — not a substitute for owner attestation
Owner attestation is an explicit human act: an owner reconfirms the registry metadata is still accurate. A deployment is not that — it proves a version shipped, not that a person reviewed the record. These are different assurance levels. This pattern records a machine-generated assertion under a named API key (provenance is preserved in the audit trail as '<key name> (API key)'), useful as a freshness signal. It does not replace owner attestation.
# cron: record a system attestation under a named API key when a
# pipeline deploys. This is a machine assertion with provenance — distinct
# from owner attestation, which is an explicit human reconfirmation.
for pid in $(cat .keypass/registered_passports.txt); do
curl -s -X POST "https://aikeypass.com/functions/api/v1/passports/manage" \
-H "x-api-key: $KEYPASS_KEY" \
-H "Content-Type: application/json" \
-d "{ \"action\": \"attest\", \"passport_id\": \"$pid\", \"notes\": \"system: deploy v${BUILD_VERSION}\" }"
doneReconcile deployed AI against the registry
Pull your org's full registered inventory over the API and diff it against what's actually running. Anything deployed but unregistered is a gap; anything registered but never seen in production is drift. The list endpoint turns the registry from a static list into a live reconciliation source — the foundation for attestation dashboards, expiry alerts, and 'no unregistered AI in production' gates. Requires a key with the passport:read scope.
# nightly: pull the registry and flag AIs that expired or were revoked
PASSPORTS=$(curl -s "https://aikeypass.com/functions/api/v1/passports/list?limit=500" \
-H "x-api-key: $KEYPASS_KEY" | jq -c '.passports[]')
echo "$PASSPORTS" | while read -r p; do
PID=$(echo "$p" | jq -r .passport_id)
STATUS=$(echo "$p" | jq -r .status)
NAME=$(echo "$p" | jq -r .name)
if [ "$STATUS" = "expired" ] || [ "$STATUS" = "revoked" ]; then
echo "::warn::$NAME ($PID) is $STATUS — stop routing to it"
fi
done
# gap analysis: anything in your CMDB or deploy manifest without a
# passport_id is an unregistered AI. Diff the list output against your
# deployed inventory to surface what's running without an identity.Map an external identity back to its Passport
Your AI shows up in many systems under many names — a Vault entity, a SPIFFE workload identity, a Kubernetes service account. When one of those makes a request or shows up in an audit log, resolve it back to the registered, owned Passport it belongs to. The resolve endpoint turns an opaque system identifier into an accountable identity. Requires a key with the passport:resolve scope; the call is scoped to your org's bindings. Resolution succeeding is not the same as the binding being trustworthy — gate on the trust level, not just existence.
# gateway middleware: resolve a Vault entity to its Passport, then
# apply policy by trust level. Three adoption modes:
# observe — log every resolution; never block (shadow mode)
# warn — declared bindings warn; stale/flagged blocks
# enforce — only owner_attested or system_verified pass through
MODE="${KEYPASS_MODE:-enforce}"
VAULT_ENTITY="fe2a8568-91cc-4d2f-a9b1-7e3c5f8d2a90"
RESOLVED=$(curl -s "https://aikeypass.com/functions/api/v1/resolve" \
--get \
--data-urlencode "system=hashicorp_vault" \
--data-urlencode "external_id=$VAULT_ENTITY" \
-H "x-api-key: $KEYPASS_KEY")
PID=$(echo "$RESOLVED" | jq -r .key_id // empty)
STATUS=$(echo "$RESOLVED" | jq -r .binding.status // empty)
if [ -z "$PID" ]; then
echo "Vault entity $VAULT_ENTITY is not bound to any Passport"
[ "$MODE" = "observe" ] && exit 0
exit 1
fi
case "$STATUS" in
system_verified|owner_attested)
echo "Binding accepted: $VAULT_ENTITY -> $PID ($STATUS)"
;;
declared)
echo "Binding exists but is not yet attested: $PID"
[ "$MODE" = "enforce" ] && exit 2
;;
stale)
echo "Binding is flagged for review: $PID"
[ "$MODE" = "observe" ] && exit 0
exit 1
;;
*)
echo "Binding is not trusted: $PID ($STATUS)"
[ "$MODE" = "observe" ] && exit 0
exit 1
;;
esacAdoption ladder
The Identity Resolver pattern supports three modes. Start in Observe to see what's bound, move to Warn when you're ready to flag gaps, and switch to Enforce once attestation is part of your workflow. You don't need a hard deployment gate on day one.
Resolve and log every binding status.
Shadow mode — nothing is blocked. Every resolution is recorded so you can see what's bound, what's declared but unattested, and what's stale before you tighten anything.
Allow declared; warn until owner-attested; block stale.
Declared bindings pass with a warning. Stale or flagged bindings are blocked. The team sees which identities still need an owner to attest — friction is low, but drift is caught.
Require owner-attested or system-verified.
Only attested or verified bindings pass through. Declared and stale bindings are blocked. This is the gate for production and regulated environments.
Operating practice
The registry gives every AI an identity. Assurance is how you keep that identity honest over time — but a dashboard alone doesn't run a program. This is the operating cadence shared by teams that have moved from reactive to mature attestation practice.
Weekly
Triage the queue
Open Assurance and filter to Due Soon. These are the Passports expiring within 30 days — your proactive window. The drill-down table shows the owner for each, so you know exactly who to contact to get the attestation done before it lapses. If any have already slipped to Past Due, those are the first thing on the list — an expired attestation means the registration is no longer current, and any verifier or deploy gate will see it.
Monthly
Review coverage and drift
Check Coverage — if it's low, attestation isn't keeping pace with registration. Then check Version Drift: these are Passports that were edited (model changed, scope expanded, owner transferred) but never re-attested. Drift means the record may be accurate but hasn't been reconfirmed. Walk the drift list with owners and attest the ones that are still correct; fix the ones that aren't, then attest.
Quarterly
Distribute accountability
Use the By Owner breakdown (sorted high to low) to see which owners are responsible for the most Passports — that's where attestation volume is concentrated and where lapses are most likely to have impact. Click an owner to filter the table to their Passports, then sort by posture to find which need attention. Flip the sort to low-to-high to surface owners with small inventories you might have overlooked. Pair this with the By AI Type view to understand how your AI estate is distributed across system classes.
As needed
Drill down and act
Every KPI card and posture group on Assurance doubles as a filter. Click Past Due to see just those records, then click a breakdown row to narrow further by owner or type. The drill-down table links straight to each Passport's detail page where you can attest, edit, or revoke. Don't try to solve the whole estate at once — filter to one posture group, one owner, or one type, work through it, and clear the filter to see the impact on the top-line numbers.
Assurance is the human checkpoint in this progression. Even at the automated stage, the dashboard is where an owner or admin confirms the program is healthy — not by checking every record, but by reading the posture and acting on what the metrics surface.
Identity standards
The Passport ID is a single, stable string. When Jira, ServiceNow, your CI/CD pipeline, and your model gateway all reference the same ai_pspt_… identifier, "which AI did this?" stops being a question. These patterns are how that standard spreads — one integration at a time, by the people building them.
If you've wired Keypass into a gateway, pipeline, or workflow others could reuse, share it here. The community grows with every integration.
Share your pattern