When Software Can Act, Who Is Responsible? The Case for an AI Agent Passport

Software used to wait for a person to tell it exactly what to do.

An AI agent can be different. Depending on its design and permissions, it may interpret a request, choose a sequence of steps, call external tools, retrieve information, create content, update another system or prepare an action for approval.

Once software can act across business systems, its identity is no longer merely a technical detail.

An organisation may need to answer:

• Which agent performed this action?
• Which version was running?
• Who developed, deployed and operated it?
• Which model, instructions and tools did it use?
• What data could it access?
• What was it permitted to do?
• Which actions required human approval?
• Which licence or contractual terms applied?
• What changed since the previous version?
• Can its activity be reconstructed later?

A name, avatar or conversational personality cannot answer these questions.

Key point: An AI agent needs more than a name. It needs a structured identity, a defined controller, explicit permissions, traceable rights and an auditable lifecycle.

From AI personality to AI agent

The expression AI personality may describe the tone, style, appearance or behavioural character presented to a user. It can be commercially important, but it represents only one layer of an operational AI system.

An AI agent may also include:

• a foundation model supplied by another company;
• system instructions and prompts;
• orchestration software;
• retrieval sources or knowledge bases;
• external tools and APIs;
• authentication credentials;
• memory or conversation state;
• action and spending limits;
• safety and approval rules;
• organisation-specific training or configuration; and
• logs created during operation.

Different parties may own, license, host, configure or control different components. Treating the entire agent as one simple personality with one owner would hide the relationships that matter most.

The more useful concept is therefore not an AI Personality Depository, but an AI Agent Passport.

What is an AI Agent Passport?

An AI Agent Passport could be a structured, versioned record describing an agent and the evidence associated with it.

Its purpose would not be to declare that the agent is a person, a legal entity, a security or an independently intelligent owner of rights.

Its purpose would be to help authorised parties understand:

• what the agent is;
• which version they are dealing with;
• who is responsible for operating it;
• what it can access and do;
• which rights and restrictions apply;
• which evidence supports the record; and
• what happened during its lifecycle.

The passport could be used when an organisation deploys an internal agent, procures an agent from a vendor, licences a configured agent to another company or needs to explain an agent to an auditor, customer, insurer, regulator or business partner.

Why the CSD analogy is useful—and where it ends

Central securities depositories use disciplined records and controlled processes to support securities issuance, maintenance and settlement.

The analogy is useful because an AI Agent Passport may also need:

• a unique reference;
• a maintained record;
• version and change history;
• defined roles and permissions;
• evidence of authorised instructions;
• controlled transfer of applicable rights;
• lifecycle states; and
• an audit trail.

But the analogy has a firm limit.

An AI agent is not automatically a security, and an AI Agent Registry would not automatically be a central securities depository. In the EU, CSDs form part of regulated securities-settlement infrastructure and are subject to organisational, conduct, prudential and supervisory requirements.

DaDepo should therefore use the discipline of a depository model without claiming the legal status or functions of a regulated CSD.

The first useful product concept is an Agent Passport. A registry may follow later. The term Agent Depository should be reserved, if used at all, for a long-term vision with clearly defined rights and legal boundaries.

Identity is not the same as ownership

An AI agent may involve several different roles:

• Model provider — supplies the underlying model or service.
• Developer — builds the orchestration, prompts, tools or application layer.
• Owner of particular intellectual property — holds rights in specific code, content, branding, data or configurations.
• Operator — runs the agent in a particular environment.
• Deployer — puts the agent into use for a defined purpose.
• Accountable organisation — accepts responsibility for the business workflow in which it operates.
• Authorised user — instructs or supervises the agent.
• Licensor or licensee — grants or receives specified usage rights.
• Data controller or processor — has a defined role in relation to personal data, depending on the circumstances.

These roles may belong to the same organisation, but they should not be assumed to do so.

A passport should therefore avoid one unexplained Owner field. It should identify the relevant role, the object or right to which that role relates, the source of the information and any applicable limitation.

What an AI Agent Passport could contain

1. Identity and version

The passport could record:

• a unique agent identifier;
• agent name and description;
• current version and status;
• previous and successor versions;
• creation, deployment and retirement dates;
• relevant software or configuration hashes; and
• the environments in which the version is approved for use.

An identifier shows which record is being referenced. It does not by itself prove that every statement in the record is correct.

2. Composition and dependencies

An agent is often assembled from several services and components.

The passport could identify, at an appropriate level:

• the foundation model or model service;
• orchestration software;
• material prompt or policy versions;
• retrieval sources and knowledge bases;
• connected tools and APIs;
• relevant hosting or execution environment;
• memory and state design; and
• critical external dependencies.

Sensitive source code, credentials, prompts or trade secrets would not need to be made public. The passport could record controlled evidence or attestations while restricting access to confidential detail.

3. Purpose, capabilities and limitations

The record should explain what the agent is intended to do and where it should not be used.

This may include:

• intended business purpose;
• supported tasks;
• known limitations;
• prohibited uses;
• testing context;
• expected human involvement; and
• conditions under which the agent must stop or escalate.

A broad statement such as “general business assistant” would rarely be sufficient for an agent that can access sensitive information or take material actions.

4. Tools, data and permissions

The passport could describe:

• systems the agent may access;
• categories of data it may read;
• records it may create or modify;
• tools it may call;
• transactions it may prepare;
• actions it may perform automatically;
• actions that require one or more approvals;
• spending or transaction limits;
• geographic, account or organisational scope; and
• emergency suspension or revocation controls.

Permissions should be versioned. A change in tool access may materially change the agent even if its name and model remain the same.

5. Rights and licensing

There may be no single transferable right called “ownership of the AI agent”.

The relevant rights may instead concern:

• software code;
• model access;
• trained or adapted model components;
• prompts and configuration;
• databases or knowledge content;
• name, visual identity or voice;
• documentation;
• the right to deploy or operate the system;
• the right to sublicense it; or
• revenues associated with a particular use.

An Agent Passport could record the available licence evidence, permitted purpose, territory, duration, transferability, sublicensing conditions and restrictions.

Recording a licence does not prove that the licensor owns every underlying right or that the licence is valid in every jurisdiction.

6. Provenance and supporting evidence

Important statements should remain connected to evidence.

Depending on the context, that evidence may include:

• development and version records;
• model or service documentation;
• licence agreements;
• dataset or knowledge-source descriptions;
• testing and evaluation reports;
• security assessments;
• human approvals;
• conformity or third-party attestations;
• incident records; and
• signed change or deployment decisions.

The passport should distinguish between evidence supplied by a participant, information extracted automatically, statements confirmed by an authorised person and conclusions made by an independent reviewer.

7. Human oversight and accountability

An operational agent should have a clearly identified human or organisational control structure.

The passport could show:

• the accountable organisation;
• the operational owner or responsible team;
• approval requirements;
• monitoring responsibilities;
• escalation contacts;
• override and stop mechanisms;
• incident-handling procedures; and
• the authority required to change permissions or deploy a new version.

Human oversight should not be described only as “a human is involved”. The record should explain when intervention is possible, who has authority and what information is available to support the decision.

8. Lifecycle and audit history

An AI agent changes over time.

The passport could maintain events such as:

• initial registration;
• version creation;
• review and approval;
• deployment;
• material configuration change;
• permission expansion or reduction;
• licence update;
• incident or investigation;
• suspension;
• revocation; and
• retirement.

For privacy, security and proportionality reasons, the passport should not necessarily contain every raw interaction. It should preserve the material lifecycle and audit evidence appropriate to the agent's purpose and risk.

Registration should apply to a defined version

An agent can change when its model, prompt, tools, data, permissions or environment changes.

Registering only a brand name would therefore provide little assurance. The meaningful object is a defined version with known components and permissions.

This creates several practical rules:

1. A material change should create a new version or recorded amendment.
2. Previous versions should remain identifiable.
3. The currently approved deployment should be visible.
4. A suspended or retired version should not appear active.
5. Evidence should state which version it covers.
6. A licence or approval should not silently extend to a materially different agent.

The version boundary is essential for auditability and controlled reuse.

What could be transferred or licensed?

The object of a transaction must be defined before any concept of settlement becomes meaningful.

A transaction might concern:

• a software licence;
• access to a hosted agent service;
• a configured deployment package;
• the right to use a name or persona;
• the right to operate the agent for a defined purpose;
• a support and maintenance relationship;
• a revenue-sharing right; or
• a bundle containing several of these rights.

The Agent Passport could help describe the bundle, its evidence and its history. It should not collapse all components into a fictional transfer of the agent's “self”.

Any future registry or marketplace workflow would need to identify precisely what is being granted, assigned or transferred and which approvals or third-party consents are required.

Why this direction is becoming relevant

The EU AI Act does not create a universal depository for AI agents. It does, however, illustrate the growing importance of structured system information.

For high-risk AI systems within its scope, the Act includes requirements concerning technical documentation, event logging and human oversight. It also provides for registration information concerning certain high-risk systems. These requirements do not apply identically to every AI agent, but they show why identity, intended purpose, version, responsible parties, limitations and lifecycle evidence increasingly matter.

The NIST AI Risk Management Framework similarly treats AI risk as a lifecycle issue and encourages structured governance, measurement and management rather than reliance on a one-time claim that a system is safe.

An Agent Passport would not replace applicable documentation, conformity assessment, contracts, audits or regulatory registers. It could provide a structured layer connecting relevant information and evidence for authorised users.

The identifier does not have to be a blockchain token

An AI agent needs a durable identifier, but that does not dictate one technical architecture.

The identifier could be maintained in a central registry, a federated system or another controlled infrastructure. Decentralised identifiers and verifiable credentials may provide useful components where portability or third-party attestations are required.

Blockchain anchoring could be used for specific integrity or timestamping purposes, but it is not necessary merely to create an Agent Passport. The design should begin with the trust, governance and interoperability problem—not with a predetermined ledger technology.

A possible DaDepo evolution path

An AI Agent Passport is a future product direction, not a statement that DaDepo currently operates an AI-agent registry or depository.

A cautious evolution could follow four stages.

Stage 1: Passport model

Define the Agent Passport schema, roles, version rules, permission model and evidence requirements. Test it with a small number of concrete enterprise use cases.

Stage 2: Controlled passport creation

Allow an authorised organisation to create a private Agent Passport from its documentation, review the structured information and share selected parts with approved recipients.

Stage 3: Agent registry

Add maintained identifiers, version history, attestations, status, suspension and revocation. The registry should record claims and evidence without representing every claim as independently verified.

Stage 4: Rights and licensing workflows

Only after the registered object and relevant rights are clearly defined should DaDepo consider controlled licensing, assignment or marketplace workflows.

This sequence keeps identity and evidence ahead of transactions.

What an AI Agent Passport would not prove

Creating or registering a passport would not automatically prove that:

• the agent is safe, reliable or compliant;
• all components were lawfully developed or acquired;
• the stated party owns every relevant right;
• training or operational data may lawfully be used;
• the agent will behave consistently in every context;
• its outputs are accurate;
• the agent is suitable for a particular decision;
• a licence is valid or transferable;
• a regulator or third party has approved the system;
• the agent has legal personality; or
• the agent is a security or regulated financial instrument.

The passport would organise claims, evidence, reviews and lifecycle information. Independent assessment and professional advice may still be required.

What DaDepo does—and does not do

DaDepo currently provides technology and information tools for organising documents, extracting available information, creating structured Asset Passports and supporting controlled asset workflows.

An AI Agent Passport would extend the same general principles—structure, provenance, controlled sharing, versioning and lifecycle history—to a new type of digital object. It remains a potential future direction and is not presented as an available regulated registry, CSD, certification service or AI approval mechanism.

DaDepo would not grant legal personality to an AI agent, determine ownership of every component, validate every licence, certify safety or guarantee regulatory compliance merely by creating a passport.

Important: DaDepo provides technology and information tools. It does not provide legal, financial, investment, tax, accounting, regulatory, cybersecurity-certification or valuation advice. Users should review the underlying evidence and obtain appropriate professional advice.

Agents need accountable identities

As software becomes capable of acting, organisations will need more than a product name and a vendor promise.

They will need to know which agent is operating, which version is approved, who controls it, what it may access, which rights apply and how its history can be examined.

The Agent Passport is a practical response to that need.

It does not turn software into a person or a security. It turns a complex and changing agent into a record that people and organisations can inspect, govern and—where the relevant rights permit—use or license with greater clarity.

Further reading

• European Commission: Central securities depositories
• Regulation (EU) 2024/1689: Artificial Intelligence Act
• NIST AI Risk Management Framework
• W3C: Decentralized Identifiers
• AI Can Prepare an Asset—But You Make the Final Decision