Written for engineers and architects. The series at /passports/ is the plain-language version.
Five Agents, One Passport.
A real five-stage research pipeline — five cooperating agents that turn a topic into a report — governed by KnowMyAgents without a line of KMA code inside it. This page answers every question the design raises, at the level of the ideas. It began as one passport for the whole program. It ends with five.
The story, in five beats
Five cooperating agents — search, collate, compile, format, pdf — turn a topic into a finished report. To the model provider they are one caller with one credential: no names, no owner, no per-agent record.
The program's model traffic is pointed at the door, and each agent states its own name on its calls. Nothing else changes. The moment traffic flows, every caller appears in the inventory — named ones as themselves, the rest as Shadow Agents.
The operator mints one passport per agent, issued under the company's own domain, each bound to a key that never leaves the wallet. The pipeline keeps running untouched; it began the day with one identity for everything and ends it with five.
On every call: the name is read, the passport attached, freshness proven, the rules checked, the verdict recorded, and the call forwarded with the passport stripped before the provider sees it. The same door counts every token against the agent and the job, so budgets act before the invoice.
Everything that happened lives in a tamper-evident record on the machine, readable in the local viewer. The hosted console receives who called, which door, the verdict, the reason and the cost — never the content. Then the whole story was tested, end to end.
The shape of it
What was verified — the short ledger
| Claim | Outcome |
|---|---|
| Every agent names itself, and the door attributes each call to the right agent | verified ✓ |
| Five passports minted under the company's domain; no private key ever in the program | verified ✓ |
| A governed call end to end: checked, recorded, stripped, forwarded | verified ✓ |
| Spend metered per agent and per job; budget actions taken at the door | verified ✓ |
| Only summaries reached the console; the full record stayed on the machine | verified ✓ |
Verified on the live pipeline in September 2026, in observe mode. The message-level run log is available to pilot customers.
The questions, answered
What does "agentic governance" mean here?
To a model provider, an agent is just another HTTP client with an API key: nobody can say which agent called, who answers for it, or what it spent. KMA answers with four mechanisms — identity (a passport per agent), proof of presence (a fresh challenge on every call), attribution (every action recorded against agent and human), and evidence (a tamper-evident record on your machine, summaries only in the cloud).
What are the moving parts?
Seven components, each with one job: the program being governed, the door it points at, the engine that verifies and decides, the passport office that issues and signs, the record, the local viewer, and the hosted console. The program talks only to the door; it never learns KMA exists.
How does an ungoverned program come under governance?
Two small facts of configuration, no code: the program's model traffic is pointed at the door, and each agent states its own name on its calls using a standard field the plain provider API simply ignores. Everything else — identity, checks, records — happens at the door and behind it.
Where does everything run?
The governing pieces run beside the program on infrastructure you control. The hosted console is the only remote party, and it receives summaries, never call content.
How does an agent get named at the door?
The door reads the agent's self-declared name from each request, attaches the right passport for that agent, and asks the passport office to prove it freshly. An agent that declares nothing is still served in observe mode — and surfaced as a Shadow Agent, which is how discovery works on day one.
How does each agent get its own passport?
The operator mints one per agent. Each passport is issued under your own domain and bound to a key that never leaves the wallet — so a copied passport is a photocopy, useless without the key it was bound to. The door picks up new passports without a restart.
What is inside a passport?
A signed verifiable credential naming the agent, its operator, the responsible human and its capabilities, with an expiry and a revocation pointer. Selective disclosure means a verifier sees only the claims it needs.
Where does trust come from?
From the web's own roots: your domain, DNS and TLS, plus published status lists — the same rails the EU digital wallet runs on. No blockchain, and nothing to join: a verifier resolves your domain and checks the signature.
Is that an agent, or just an API call?
The honest answer: at the door, an agent is a named caller with continuity — a stable identity across many calls, a human behind it, and its own record. The distinction is drawn by accountability, not by how clever the software is.
How does a Shadow Agent become a named one?
It appears in the inventory the moment it calls; a person looks at it, names it, assigns an owner, and mints its passport. From then on its history accrues to its identity. Nothing is blocked until you choose to enforce.
What counts as an agent worth a passport?
Anything that acts with delegated authority and could be asked "who told you to do that?" A rule of thumb, not a theology: if it would embarrass you unattributed, it gets papers.
What happens on one governed call?
Name read, passport attached, freshness proven, rules checked, verdict recorded, call forwarded — with the passport removed before the provider sees the request. Milliseconds, local, and the same in observe and enforce; only the consequence of "would refuse" changes.
How are metering and budgets enforced?
Every call's usage is counted against the agent that made it and the job it was doing. Budgets act at the door: pause the agent, downgrade the model, or ask a person — before the invoice, not after.
What reaches the console — and what never does?
Summaries: who called, which door, allowed or refused, why, what it cost. Request and reply content stays on your machine, in the local viewer. Enforcement never depends on the console: if it goes dark, your doors keep working.
How do agents present themselves to other agents?
With agent cards — a published, verifiable statement of what an agent is and may do — so a counterpart can check papers before talking, exactly as the door does.
What about agents from another company?
Verify globally, trust locally: their passports verify against their domain with no shared infrastructure, and your rules alone decide what a verified stranger may do here.
Does this replace Entra or Okta?
No. People stay in the directory you already run; agents get the identity layer those directories were never built for. The two co-exist, joined by the responsible-human field on every passport.
Was this actually tested?
Yes — end to end on the real five-agent pipeline in September 2026, in observe mode: naming, per-agent passports, governed calls, metering, and what reaches the console, each with its expected evidence checked. The detailed run log is available to pilot customers.
What are the limits, honestly?
This layer governs access, attribution and spend. It does not evaluate model behaviour, does not see inside an agent's reasoning, and some controls — like planner-level orchestration limits — are still roadmap. The compliance page keeps the honest scores.