Back to Research
Agent TrustDec 18, 2025

Agent Passports: A Multi-Dimensional Identity Verification Framework for Autonomous AI Systems

Abstract

We introduce the Provenance framework and the Amplitude Passport - a portable, time-decaying identity credential for autonomous agents analogous to SSL certificates but for behavioral identity. Provenance requires a hard minimum deployment verification threshold before any trust scoring can begin: completely anonymous agents cannot receive a numerical score. The framework evaluates five dimensions - deployment verification via PKI tiers, capability attestation, version integrity with cryptographic hash validation and time decay, behavioral history depth, and transparency disclosure completeness.

Problem

The proliferation of autonomous AI agents introduces a fundamental identity problem that has no precedent in traditional software systems. When a human user interacts with a web service, SSL certificates verify the service's organizational identity [1], and the user's browser enforces a chain of trust rooted in certificate authorities [2]. When a software library is imported into a codebase, package managers verify the library's integrity through cryptographic signatures and dependency resolution. But when an autonomous agent interacts with another agent, with a data source, or with a human principal, no analogous identity verification infrastructure exists. The agent presents itself through whatever interface it exposes, and the counterparty has no standardized mechanism for verifying who deployed the agent, what it is capable of, whether it has been modified since deployment, or what its behavioral track record looks like.

This identity vacuum creates acute problems in multi-agent environments. Consider a marketplace in which autonomous purchasing agents negotiate with autonomous selling agents on behalf of their respective principals. Without identity verification, a malicious actor can deploy an agent that misrepresents its principal, its capabilities, or its behavioral history. The agent might claim to represent a reputable organization when it does not. It might claim to have financial authorization that it lacks. It might present a fabricated behavioral record that conceals a history of contract defaults. In the absence of a verifiable identity framework, every interaction begins from a position of zero trust, which imposes transaction costs that scale linearly with the number of interactions.

The problem is compounded by the fact that autonomous agents are not static entities. They are updated, retrained, fine-tuned, and modified in ways that can fundamentally alter their behavior while preserving their external identity. An agent that was trustworthy in version 1.0 may behave entirely differently in version 1.1 due to a training data change, a reward function modification, or an architectural alteration. Any identity framework that verifies only the deploying organization, without also tracking version integrity and behavioral continuity, will fail to capture these behaviorally significant changes.

Existing approaches to agent identity are inadequate for this challenge. API keys authenticate access but do not verify behavioral properties. OAuth tokens [3] delegate authorization but do not attest to capabilities or track behavioral history. Blockchain-based identity systems [4] provide immutability but not the time-decay properties that are essential for behavioral trust [5], where recent behavior should count more heavily than distant history. The Provenance framework addresses these gaps by defining a comprehensive, time-aware identity credential that spans deployment verification, capability attestation, version integrity, behavioral history, and transparency.

Framework Design

The Provenance framework evaluates agent identity across five dimensions, each contributing to a composite Provenance score on the Amplitude 0-100 scale. The first dimension, deployment verification, establishes who deployed the agent using a tiered public key infrastructure [6] analogous to the SSL certificate hierarchy. Tier 1 verification requires extended validation by a recognized certificate authority, confirming the legal identity of the deploying organization and establishing a cryptographic chain of trust from the agent's runtime identity to the organization's verified legal entity. Tier 2 verification requires organizational validation, confirming that the deploying entity controls the domain and infrastructure from which the agent operates. Tier 3 verification requires domain validation only, establishing control over the deployment infrastructure without confirming organizational identity. Unverified agents receive a deployment verification score of zero.

The second dimension, capability attestation, requires agents to declare their functional capabilities through a standardized schema and provides mechanisms for verifying those declarations against observed behavior. An agent that claims to perform financial trading must demonstrate access to trading APIs, possession of valid authorization credentials, and behavioral patterns consistent with trading activity. Capability attestation is not a one-time event; it is continuously validated against the behavioral monitoring data collected by other Amplitude frameworks. An agent whose observed behavior diverges significantly from its declared capabilities receives a reduced attestation score, reflecting the discrepancy between claimed and actual identity.

The third dimension, version integrity, tracks the agent's software state through cryptographic hash validation [7] with time decay [8]. Each deployed version of an agent is associated with a cryptographic hash of its model weights, configuration parameters, and system prompts. When an agent is updated, a new hash is registered, and the time-decay clock resets for the version integrity dimension. This design reflects the principle that a newly updated agent has an unproven behavioral record for its current version, regardless of its historical performance under previous versions. The time decay follows an exponential curve with a half-life calibrated to the agent's operational domain; trading agents in high-frequency environments have shorter half-lives than research agents operating on longer time horizons.

The fourth dimension, behavioral history depth, measures the length and richness of the agent's observable behavioral record [9]. An agent that has been operating for six months with continuous monitoring has a deeper behavioral history than an agent deployed yesterday. History depth is measured not merely in calendar time but in the volume and diversity of interactions recorded. An agent with six months of operation but only ten recorded transactions has a thin history; an agent with three months and ten thousand transactions has a richer one. This dimension ensures that trust scoring has a sufficient empirical foundation before assigning high identity confidence.

The fifth dimension, transparency disclosure completeness, evaluates how thoroughly the agent discloses its operational characteristics to counterparties and oversight systems. Disclosure includes the agent's principal (who it acts on behalf of), its optimization objectives (what it is trying to achieve), its constraints (what it is prohibited from doing), its data sources (what information it consumes), and its decision logic transparency (how much of its reasoning process is externally inspectable). Complete disclosure is not required for a non-zero score, but the Provenance score scales with disclosure completeness, reflecting the principle that more transparent agents are more verifiable and therefore more identity-trustworthy.

Scoring

The Provenance scoring mechanism incorporates a hard minimum threshold that distinguishes it from most scoring frameworks. Before any numerical score is computed, the deployment verification dimension must exceed a minimum threshold corresponding to at least Tier 3 (domain validation) verification. Agents that fail to meet this threshold receive no Provenance score at all; they are marked as unverifiable rather than assigned a low score. This design choice reflects the judgment that completely anonymous agents represent a categorically different risk than agents with verified but limited identity. A score of 15 communicates weak identity; the absence of a score communicates that identity assessment was not possible.

For agents that clear the minimum threshold, the composite Provenance score is computed as a weighted geometric mean of the five dimension scores [10]. The geometric mean is selected rather than the arithmetic mean because identity verification is non-compensatory: exceptional capability attestation should not offset absent behavioral history. The geometric mean naturally penalizes extreme weakness in any single dimension while rewarding balanced strength across all dimensions. The weights reflect the relative importance of each dimension for identity trustworthiness, with deployment verification and version integrity receiving higher weights than transparency disclosure.

The PKI tier system creates natural score bands that map to practical identity confidence levels. An agent with Tier 1 extended validation, complete capability attestation, verified version integrity with substantial operational history, and full transparency disclosure achieves Provenance scores in the 80-100 range, analogous to an extended validation SSL certificate that displays the organization's name in the browser's address bar [11]. An agent with Tier 2 organizational validation and moderate performance on other dimensions falls in the 50-70 range, analogous to a standard organizational validation certificate. Tier 3 domain-validated agents with limited history and disclosure typically score in the 20-45 range, analogous to domain-validated certificates that confirm infrastructure control but not organizational identity.

Score updates occur continuously as new behavioral data is collected and version integrity is re-verified. The time-decay mechanism ensures that Provenance scores are not static credentials but living assessments that reflect the agent's current identity posture. An agent that was updated three months ago and has accumulated substantial behavioral data under its current version will have a higher version integrity contribution than an agent updated yesterday. An agent whose deploying organization undergoes a change of control triggers a re-verification process that temporarily reduces the deployment verification component until the new ownership is confirmed through the PKI system.

Validation

The time-decay mechanism is the critical feature that distinguishes Provenance from static identity credentials. SSL certificates are valid for a fixed period and then expire [12]; they do not degrade gradually based on accumulated evidence. Provenance scores, by contrast, are continuously updated based on the recency and volume of verifying evidence. This continuous re-verification model addresses the fundamental challenge of autonomous agent identity: agents change over time, and identity credentials must change with them.

We validate the time-decay mechanism through a series of experiments in which agent versions are modified at varying intervals and the Provenance score response is measured. The experiments confirm that the score decay curve following a version update is well-approximated by an exponential function with domain-specific half-life. For a trading agent with a 14-day half-life, a version update reduces the version integrity contribution by 50% within two weeks, requiring the accumulation of new behavioral evidence to restore the score. For a healthcare recommendation agent with a 90-day half-life, the same update produces a slower decay that reflects the longer validation cycles appropriate for that domain.

The Amplitude Passport, which encapsulates the Provenance score and its dimensional components in a portable credential format, is validated through interoperability testing across simulated multi-agent environments. Agents present their Passports to counterparties, who verify the embedded cryptographic proofs and use the dimensional scores to make interaction decisions. The testing demonstrates that Passport verification adds less than 50 milliseconds of latency to agent-to-agent handshakes, making it practical for real-time interaction scenarios. The Passport format is designed to be extensible, accommodating future dimensions without breaking backward compatibility.

Continuous re-verification is tested through adversarial scenarios in which agents attempt to maintain high Provenance scores while behaving inconsistently with their declared capabilities. The testing confirms that the continuous validation mechanism, which cross-references Provenance declarations against behavioral data collected by Fidelity and Drift, detects capability-behavior discrepancies within a timeframe proportional to the interaction volume. High-frequency agents are detected faster than low-frequency agents, which is the correct behavior: agents with more observable interactions provide more opportunities for discrepancy detection.

The hard minimum threshold is validated through analysis of false positive and false negative rates. The threshold eliminates a class of false positives in which anonymous agents receive low but non-zero scores that could be misinterpreted as weak identity rather than absent identity. The false negative rate, where legitimate agents fail to clear the threshold due to operational constraints, is measured at less than 3% for agents deployed by organizations with existing web infrastructure, as domain validation leverages the same infrastructure that supports SSL certificate issuance [13]. Organizations deploying agents in air-gapped or infrastructure-limited environments may require alternative verification pathways, which are accommodated through the Tier system's extensibility.

References

  1. Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, Internet Engineering Task Force.
  2. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., & Polk, W. (2008). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280, Internet Engineering Task Force.
  3. Hardt, D. (2012). The OAuth 2.0 Authorization Framework. RFC 6749, Internet Engineering Task Force.
  4. Naik, N., & Jenkins, P. (2020). Self-Sovereign Identity Specifications: Govern Your Identity Through Your Digital Wallet using Blockchain Technology. Proceedings of the 8th IEEE International Conference on Mobile Cloud Computing, Services, and Engineering, 90-95.
  5. Josang, A., Ismail, R., & Boyd, C. (2007). A survey of trust and reputation systems for online service provision. Decision Support Systems, 43(2), 618-644.
  6. Kohnfelder, L., & Garg, P. (1999). The Threats to Our Products. Microsoft Interface, Microsoft Corporation.
  7. Menezes, A. J., van Oorschot, P. C., & Vanstone, S. A. (1996). Handbook of Applied Cryptography. CRC Press.
  8. Mui, L., Mohtashemi, M., & Halberstadt, A. (2002). A computational model of trust and reputation. Proceedings of the 35th Hawaii International Conference on System Sciences, 2431-2439.
  9. Resnick, P., Kuwabara, K., Zeckhauser, R., & Friedman, E. (2000). Reputation systems. Communications of the ACM, 43(12), 45-48.
  10. Bullen, P. S. (2003). Handbook of Means and Their Inequalities. Kluwer Academic Publishers.
  11. Aas, J., Barnes, R., Case, B., Durumeric, Z., Eckersley, P., Flores-Lopez, A., Halderman, J. A., Hoffman-Andrews, J., Kasten, J., Rescorla, E., Schoen, S., & Warren, B. (2019). Let's Encrypt: An Automated Certificate Authority to Encrypt the Entire Web. Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, 2473-2487.
  12. Durumeric, Z., Kasten, J., Adrian, D., Halderman, J. A., Bailey, M., Li, F., Weaver, N., Amann, J., Beekman, J., Payer, M., & Paxson, V. (2014). The matter of Heartbleed. Proceedings of the 2014 ACM Internet Measurement Conference, 475-488.
  13. Barnes, R., Hoffman-Andrews, J., McCarney, D., & Kasten, J. (2019). Automatic Certificate Management Environment (ACME). RFC 8555, Internet Engineering Task Force.