A Passport for the Wandering Herd
If you switch pastures, why should your tools, settings, and hard-won lessons be left behind?
Every time the herd changes pasture, the farmer demands a new ID badge, a new list of authorized gates, and a new set of keys. Soon the paperwork weighs more than the cow.
AI users encounter a less furry version of this problem when moving between agent harnesses. A tool is configured in one environment, permissioned in another, and then configured all over again when a new model or interface arrives.
A portable identity is more than a profile
Our proposed Peasant Passport would describe the user's authorized capabilities independently of a particular AI harness. It might contain stable connector references, configurations, roles, grant scopes, and versioned records. An agent could ask for a capability by logical name instead of keeping a provider API key in its own prompt or configuration file.
But a portable identity must not become one master key. The user, the agent, the tool, and the operation are different actors. Every invocation needs an enforceable answer to who may do what to which resource, under which conditions.
What travels, and what cannot
Definitions, permissions, non-secret settings, and useful metadata are plausible export candidates. Some OAuth authorizations, device-bound credentials, and regulated provider grants may need explicit reauthorization after a move. A backup file is not a promise that another service will honor an old token.
That is why Peasant Vault is proposed as a separate trusted component. It would protect secrets from general-purpose agents and provide constrained invocation rather than handing models the keys. The isolation must be real: an agent with unrestricted shell access to the secret store defeats a merely cosmetic password field.
The exit test
The most revealing portability demonstration may be leaving the product entirely. Can a user export a usable, documented configuration? Can they still operate local tools when a hosted synchronization service goes offline? Can they revoke a permission once and have the revocation reach every authorized client?
A strong test would migrate a deliberately small setup between two harnesses and record which parts transferred automatically, which demanded approval, and which were impossible due to external platform constraints.
The field note
Owning the yoke means keeping the paperwork, the keys, and the right to leave. Portability is not a prettier login screen. It is an exit route that works.
Research status: product architecture hypothesis, not a shipped identity or synchronization service.