AI Agents Need Passports: A Local First Approach to Provenance and Lineage

Arpita Sarker — Wed, 06 May 2026 23:45:56 +0000

AI Agents Need Passports: A Local First Approach to Provenance and Lineage

AI agents are becoming harder to inspect.

A simple AI app may start with one model and one prompt. Then it grows.

Suddenly there is a base model, a fine-tuned version, prompt templates, tools, API calls, retrieval sources, sub-agents, human approvals, CI workflows, and deployment changes.

At that point, a basic question becomes surprisingly hard to answer:

What exactly is this AI system, where did it come from, and what changed?

Logs show what happened after execution.

Model cards describe a model.

Registries store assets.

Observability tools monitor behaviour.

But many teams still lack a portable identity record that can stay with a model or agent across repositories, local workflows, and CI.

That is the idea behind AI Passports.

What is an AI Passport?

An AI Passport is a machine-readable record for an AI system.

It can hold:

identity
ownership
provenance
artifact references
lineage
version context
validation metadata
evidence events

The goal is not to replace model cards, MLflow, Hugging Face, or observability tools.

The goal is to complement them with a portable layer that makes AI systems easier to identify, inspect, and verify across workflows.

Think of it like this:

Model cards describe the model.

Registries store the asset.

Logs show runtime behaviour.

Passports preserve identity, provenance, lineage, and evidence.

Why local first matters

AI teams should not need to send private prompts, weights, logs, datasets, or customer data to a hosted service just to create a basic identity record.

A local-first passport workflow lets builders create and validate passport files inside their own repository and CI process.

That matters because provenance should be verifiable before a system reaches a hosted governance platform.

A passport should be useful when a developer is still working locally. It should also remain useful later when the same system becomes part of a product, agent workflow, or governed AI process.

The problem gets worse with agents

AI systems are no longer static.

Models are fine-tuned, quantized, wrapped, reused, forked, and connected to tools.

Agents can call APIs, use memory, retrieve documents, trigger workflows, or generate artifacts.

This creates a practical traceability problem.

If an agent behaves unexpectedly, teams need to know:

which model or agent version was involved
what it was derived from
what tool surface it had
what changed since the previous version
whether the identity record is still valid
what evidence exists for review

Without a durable identity record, this information gets scattered across READMEs, dashboards, logs, deployment scripts, and team memory.

What we built

We are building Forkit Dev, an AI passport infrastructure layer for models, agents, datasets, and AI workflows.

Today, there are two ways to try it.

1. Forkit Dev Core: open-source passport infrastructure

Forkit Dev Core is the Apache 2.0 open-source foundation.

It is a public alpha for local AI model and agent passports.

Current scope:

create model and agent passport JSON records
generate deterministic passport IDs
validate passports locally
keep basic provenance and lineage fields
validate passport files in GitHub CI
use a local-first workflow without requiring a hosted service

GitHub:

https://github.com/Forkit-Dev-Core/Forkit_Dev

This is for developers who want to inspect, run, extend, or challenge the passport structure.

2. Forkit.dev: free hosted AI Passport flow

For builders who do not want to run the local stack, we also opened a free hosted passport flow.

You can create a free AI Passport here:

https://forkit.dev

The hosted flow is for founders, developers, researchers, and AI teams who want to register an AI model, agent, or dataset and start building an evidence record early.

The open-source core is for inspection and extension.

The hosted flow is for speed and usability.

Both are part of the same idea:

AI systems should have a durable identity before they become invisible inside production workflows.

What this is not

Forkit Dev Core is not a replacement for model cards.

It is not a replacement for MLflow, Hugging Face, or observability platforms.

It is not a magic compliance certificate.

It is an attempt to create a portable identity and evidence layer that can sit alongside existing tools.

The current open-source core is still public alpha. That means the fundamentals are usable, but feedback may still shape the schema, APIs, and developer experience.

The open design question

The hardest question is not whether AI systems need metadata.

The harder question is where the boundary should be.

When an agent forks into sub-agents, or when tools generate artifacts:

What should become a separate passport?
What should stay as an evidence event?
Should every sub-agent get its own passport?
Should only reusable or deployable agents get passports?
Should tool-generated artifacts become passport-linked evidence instead?
How much metadata is useful before it becomes bureaucracy?

This is the question I would love feedback on.

If you are building models, agents, MLOps workflows, local LLM tools, or AI governance systems, I would genuinely value your thoughts.

Open-source core:

https://github.com/Forkit-Dev-Core/Forkit_Dev

Create a free AI Passport:

https://forkit.dev

DEV Community: Arpita Sarker

AI Agents Need Passports: A Local First Approach to Provenance and Lineage

AI Agents Need Passports: A Local First Approach to Provenance and Lineage

What is an AI Passport?

Why local first matters

The problem gets worse with agents

What we built

1. Forkit Dev Core: open-source passport infrastructure

2. Forkit.dev: free hosted AI Passport flow

What this is not

The open design question