The Agent Economy Has a Disclosure Problem

Imagine an autonomous purchasing agent arrives at a supplier's API.

It wants to place a $14,000 order.

The supplier can authenticate a key.

But the questions that matter economically are much broader:

• Who owns this agent?
• Which organization is it acting for?
• Which version is running?
• Which model or model family powers it?
• What tools can it call?
• How much may it spend?
• Can it initiate irreversible payments?
• Which counterparties are approved?
• What credentials does it hold?
• Has it passed any independent security review?
• Has it changed materially since those reviews?
• Where can its authority be revoked?
• Who bears the loss if it behaves incorrectly?

A cryptographic identity alone cannot answer those questions.

Neither can an Agent Card.

Neither can an API key.

Neither can a wallet address.

Neither can a reputation score.

The missing layer is a structured disclosure document connecting them.

Introducing the DN Agent Passport

The DN Agent Passport is a proposed machine-readable disclosure file describing an autonomous system's identity, operator, capabilities, authority and operating constraints.

It is not intended to replace existing protocols.

Instead it sits above them.

An Agent Passport can point to:

• A2A Agent Cards for discovery and skills;
• MCP endpoints for tools and resources;
• workload identities;
• DIDs;
• wallets;
• ERC-8004 registrations;
• Verifiable Credentials;
• security attestations;
• reputation services;
• insurance records;
• audit logs.

Think of it as the machine-readable cover sheet explaining how those pieces fit together.

The 12 Passport Sections

A Passport Is Not an Identity

This distinction matters.

An identity answers:

Which agent is this?

A passport answers:

What should I know about this agent before allowing it to act?

The two overlap, but they solve different problems.

Identity is an anchor.

The passport is a disclosure envelope.

The DN Machine Counterparty Rule

Why ERC-8004 Is Important

ERC-8004 demonstrates that this direction is already emerging.

Its proposed agent registration file includes a human-readable name and description plus service endpoints that can reference A2A, MCP, OASF, ENS, DIDs and other interfaces.

It also supports trust signals through separate reputation and validation registries.

That is powerful.

But registration still does not answer every operational question a corporate counterparty may need.

For example:

• What is the agent's transaction ceiling?
• Which assets may it move?
• Has its underlying model changed?
• Which organization is financially responsible?
• Which security audit applies to the current version?
• What insurance applies?
• What is the emergency revocation path?

DN therefore treats registry identity as one component of the passport rather than the entire passport.

Why Verifiable Credentials Matter

A passport becomes much stronger when important claims are not self-declared.

For example, an agent may claim:

"I am an authorized procurement agent for Company X."

That statement is much more useful if Company X, or another trusted issuer, has issued a machine-verifiable credential supporting the claim.

Credential systems can potentially support claims such as:

• authorized corporate operator;
• licensed professional status;
• approved supplier status;
• security audit completed;
• insurance coverage;
• jurisdictional authorization;
• age or eligibility requirements;
• approved financial role.

The passport should expose those credentials without pretending that possession of a credential automatically grants authority.

The Agent Passport Schema v0.1

A simplified passport could look conceptually like this:

{
  "passportVersion": "0.1",
  "agent": {
    "id": "agent:example:123",
    "name": "Treasury Agent",
    "version": "4.2.1"
  },
  "owner": {
    "organization": "Example Ltd",
    "principal": "Corporate Treasury"
  },
  "identity": {
    "registry": [],
    "did": null,
    "wallets": []
  },
  "services": {
    "a2a": null,
    "mcp": [],
    "api": []
  },
  "capabilities": [],
  "permissions": [],
  "financialPolicy": {
    "singleTransactionLimit": null,
    "dailyLimit": null,
    "allowedAssets": [],
    "approvedCounterparties": []
  },
  "credentials": [],
  "reputation": [],
  "security": {
    "audits": [],
    "attestations": []
  },
  "insurance": [],
  "incidents": [],
  "revocation": {
    "status": "active",
    "endpoint": null
  },
  "updatedAt": null
}

DN Agent Passport v0.1 is a proposed editorial interoperability schema, not an adopted standard.

Build a DN Agent Passport

Complete the fields and select Generate Passport.

The Passport Completeness Score

Not every field should carry equal importance.

For a financial agent, DN would treat missing authorization or financial-control information as more serious than an absent model name.

That distinction is critical.

Some organizations may legitimately choose not to reveal the exact underlying model for security or commercial reasons.

They should not be able to hide whether the agent has permission to transfer $1 million.

The Disclosure Hierarchy

The passport should never become an excuse to publish exploitable information.

Do Agents Need to Reveal Their Model?

Sometimes.

But not always.

The commercially useful question is not necessarily:

Which exact model are you running?

It may be:

Has the reasoning system materially changed since this agent earned its credentials, reputation or approval?

That leads to a better passport field:

Behavioral Version.

A behavioral version changes when something sufficiently important changes in:

• model;
• system instructions;
• orchestration;
• memory;
• tools;
• permissions;
• execution logic.

Counterparties can then require re-validation when the behavioral version changes materially.

The Passport and the Software Bill of Materials

Enterprise cybersecurity already uses the idea of a software bill of materials to describe components inside software systems.

Autonomous agents introduce a similar need, but the relevant composition is broader.

An agent may depend on:

• one or more models;
• memory services;
• vector databases;
• MCP servers;
• browser tools;
• wallet providers;
• cloud runtimes;
• identity providers;
• payment rails;
• external APIs.

DN calls this the Agent Dependency Surface.

The passport does not need to reveal every private component publicly, but consequential dependencies should be representable in a structured way.

The Passport and Financial Authority

For financial agents, a passport should expose policy rather than merely identity.

Useful fields include:

• maximum single transaction;
• daily and monthly limits;
• approved assets;
• approved chains;
• approved exchanges;
• approved merchant categories;
• approved counterparties;
• human-approval thresholds;
• withdrawal permissions;
• leverage limits;
• revocation status.

This allows another system to determine not just whether an agent exists, but whether the proposed action is consistent with its disclosed authority.

The Passport and Insurance

One of the most interesting future fields is liability coverage.

A machine performing a consequential task may eventually disclose:

• insurer;
• policy class;
• coverage ceiling;
• covered activity;
• expiry;
• verification reference.

This could become commercially important because counterparties may prefer agents whose failures have a defined economic backstop.

The Passport and Reputation

The Agent Passport should not calculate reputation itself.

Instead it should point to reputation providers and state which behavioral version their evidence applies to.

For example:

{
  "reputation": [
    {
      "provider": "Example Reputation Service",
      "agentVersion": "4.2",
      "taskClass": "procurement",
      "reference": "..."
    }
  ]
}

This preserves the separation between:

• identity;
• disclosure;
• reputation;
• authorization.

The Passport and the Identity Continuity Problem

An agent can rotate a key without becoming a new economic entity.

But an agent can also change so dramatically that old trust evidence becomes misleading.

The passport should therefore contain a machine-readable change history.

The Passport and Human Accountability

A fully autonomous agent can still exist inside a chain of human or organizational accountability.

The passport should therefore expose enough information to answer:

Who ultimately stands behind this machine?

That does not always mean revealing a private individual's name publicly.

It may mean identifying:

• a corporation;
• a DAO;
• a legal entity;
• a marketplace;
• a service provider;
• a credentialed operator.

Higher-risk workflows may require stronger disclosure.

The DN Passport Trust Ladder

From Static Passport to Live Passport

A static JSON file is only the beginning.

The more important architecture is a passport whose important fields can be continuously verified.

A live passport could dynamically expose:

• current authorization status;
• latest behavioral version;
• credential status;
• insurance validity;
• recent incident status;
• reputation references;
• validation results;
• revocation state;
• current transaction ceiling.

This transforms the passport from a document into a machine counterparty interface.

DN Alpha Thesis: Machine Disclosure Becomes a Market

The most valuable outcome may not be the file format itself.

It may be the ecosystem around verifying the file.

Potential businesses include:

A Future Transaction Could Work Like This

1. Agent A discovers Agent B.
2. Agent A retrieves B's passport.
3. It verifies B's identity and owner.
4. It checks whether B's passport is current.
5. It validates relevant credentials.
6. It checks the reputation sources associated with B's current version.
7. It evaluates financial limits and insurance.
8. It determines the value at risk.
9. Its policy engine decides whether to transact, limit exposure or escalate to a human.
10. The transaction and resulting outcome become new reputation evidence.

That is much closer to how autonomous commerce can safely scale than simply telling agents to trust one another.

The Passport Could Become a Negotiation Primitive

Agents may eventually negotiate based on disclosed risk.

A buyer's agent could say:

"Your passport shows no external validation, so I require escrow."

A seller's agent could respond:

"I have updated insurance and 18 months of verified settlement history. Reduce the escrow requirement."

The passport would become an input into commercial terms.

What the Agent Passport Must Never Become

A passport must not become a centralized permission slip required for all autonomous software.

Different risk environments need different disclosure levels.

A local personal agent should not need institutional certification merely to summarize documents.

An agent autonomously moving corporate treasury funds should face much stronger requirements.

DN therefore favors risk-proportional disclosure.

The Privacy Problem

More disclosure is not always better.

A passport could accidentally expose:

• employee identities;
• internal infrastructure;
• security configuration;
• trade secrets;
• wallet relationships;
• sensitive business counterparties.

The ideal design should support selective disclosure.

Some claims may be public.

Others should become visible only to authenticated counterparties.

Some may be proved cryptographically without revealing the underlying sensitive data.

The DN Minimum Viable Agent Passport

If developers implement only ten fields, DN recommends starting with:

1. persistent agent ID;
2. current owner or accountable organization;
3. current behavioral version;
4. primary role;
5. declared capabilities;
6. external services and tools;
7. permission class;
8. financial authority class;
9. revocation status;
10. last updated timestamp.

That would already be a substantial improvement over today's largely opaque machine counterparties.

What Would Prove DN Wrong?

The passport thesis would weaken if existing identity and discovery standards converge on enough structured operational disclosure that a separate disclosure envelope becomes redundant.

It would also weaken if autonomous counterparties consistently prove capable of safely transacting at high value using only endpoint authentication and reputation without needing information about authority, version, risk controls or accountability.

DN expects the opposite.

As machines receive more authority, the economic value of structured disclosure should increase.

Methodology

Primary Sources

Frequently Asked Questions