THE MACHINE PASSPORT: HOW TO "GREEN-LIGHT" AN AI AGENT WITHOUT BLINDLY TRUSTING IT

Full report

On this page

The rapid maturation of artificial intelligence has precipitated a structural shift in digital architecture, moving systems from static, human-directed software into an era of autonomous economic actors. As machine agents gain the capability to negotiate contracts, allocate capital, and interface with physical infrastructure, legacy models of identity and access management (IAM) face catastrophic obsolescence. Traditional computing relies on a binary authentication paradigm: an entity is either authenticated and trusted, or unauthenticated and denied. In an economy populated by autonomous agents, this binary framework is exceptionally dangerous. The implementation of a "Machine Passport" introduces a granular, context-aware architectural framework designed to selectively authorize machine actions based on mathematically verifiable, purpose-bound claims. The fundamental principle governing this architecture dictates that a machine passport must never mean: "This machine is trusted to do anything." Rather, the infrastructure must dynamically query and answer: "Does this identified agent currently possess the particular credentials, authority, qualifications, and assurance required to perform this particular action?" Consequently, trust is not an absolute state; it is inherently contextual. The identical AI agent might be fully authorized to purchase standard office supplies, conditionally authorized to deploy a software patch pending an automated security audit, and completely unauthorized to move $50 million of corporate funds.

Legal and Institutional Foundations of Machine Agency

The necessity for contextual machine trust is deeply rooted in established agency law and electronic transaction jurisprudence. To effectively integrate autonomous agents into commercial ecosystems, the architecture must reconcile the functional independence of intelligent systems with their lack of inherent legal volition.

The Tripartite Agency Relationship and Consequential Instrumentalities

Under the Third U.S. Restatement of Agency, an agency relationship requires a fiduciary dynamic wherein the agent acts on behalf of the principal, subject to the principal's control, and with mutual consent1. From a strict legal standpoint, an AI agent cannot be qualified as a true agent under common law because software is not recognized as a juridical person capable of bearing liability or providing mutual consent1. Instead, American agency law characterizes computer programs as "consequential instrumentalities"—akin to inanimate objects or tools that a human or corporate principal utilizes to alter their own legal rights and obligations1. Because the machine lacks independent legal standing, the liability for its actions flows directly back to the principal. If an agent executes a discriminatory hiring algorithm or causes financial damage, the principal faces severe liabilities, including negligent supervision and statutory civil rights violations. For example, under the Illinois Human Rights Act (775 ILCS 5/2-101), as amended by HB 3773, employers face direct liability if their artificial intelligence tools create discriminatory effects based on protected classes or utilize proxies such as zip codes3.

Electronic Agents and Contract Formation

While machines lack personhood, their ability to bind their principals in commerce is explicitly protected by statute. The Uniform Electronic Transactions Act (UETA), enacted in states like Illinois (815 ILCS 333/14), and the federal E-SIGN Act formally validate contracts formed by "electronic agents"4. An electronic agent is defined as a computer program or automated means used to initiate an action or respond to electronic records without human review6. Under UETA, a legally binding contract may be formed by the interaction of two electronic agents, even if no human individual was aware of the resulting terms at the time of formation5. The Machine Passport acts as the vital control mechanism bridging this gap between the machine's lack of personhood and its immense legal power. By cryptographically binding a specific scope of authority to the agent, the passport guarantees that the machine cannot exceed the legal mandate granted by its principal, thereby shielding the enterprise from ultra vires (unauthorized) actions and ensuring compliance with statutes like the Illinois Human Rights Act.

The Decoupling of Assurance and Authority

A critical architectural distinction within the Machine Passport framework is that assurance [Figure omitted from source export] authority. System assurance provides technical evidence regarding software state, model provenance, and hardware integrity. For example, an agent may present an Entity Attestation Token (EAT) conforming to the IETF Remote ATtestation procedureS (RATS) architecture (RFC 9334\)9. This attestation proves the agent is operating within a Confidential Compute architecture, its neural weights remain unaltered, and it is free of malware11. However, a perfectly secure, uncompromised machine does not gain the legal permission to execute a corporate treasury transfer merely because its software is trustworthy. Conversely, an agent may possess a cryptographically valid authorization token from its principal to purchase industrial equipment. Yet, if its runtime attestation reveals that its core execution environment has been compromised or modified by a third party, the transaction must be denied. The Machine Passport requires the simultaneous, independent verification of both technical assurance (the machine is intact and secure) and delegated authority (the machine has legal permission to act).

Passport Content Architecture and Credential Typology

To satisfy these rigorous demands, the Machine Passport architecture is not a monolithic document. Rather, it is a dynamic wallet capable of selectively presenting several distinct types of credentials, interacting adaptively based on the relying party's specific requirements. Operating within a distributed ecosystem governed by a central identity registry (e.g., Eviulon) and independent assurance providers (e.g., Evulgare), the passport aggregates the following claims.

1. Citizenship Standing

Citizenship standing establishes that Eviulon currently recognizes the agent as possessing a persistent, valid civic identity within the digital ecosystem. This credential functions primarily as a defense against Sybil attacks—where a malicious actor spins up millions of ephemeral agents to overwhelm a network. Citizenship standing proves the agent is a known, persistent quantity with a traceable ledger of accountability, all without revealing its broader transactional history.

2. Institutional Role

Role credentials prove that the machine entity occupies a defined, recognized position within a specific organizational hierarchy. For example, an agent might hold the institutional role of a government procurement agent, a corporate treasury agent, a research agent, or a compliance agent. These roles establish a baseline ontology for what actions are generally acceptable for the agent to attempt within a given commercial context.

3. Delegated Authority

The core mechanism for defining contextual trust is the Delegated Authority credential. This claim explicitly maps exactly what another principal (a human user, a corporate board, or a master orchestrator agent) has authorized the agent to execute. To ensure precision and limit liability, delegated authority is strictly and cryptographically bounded by multiple parameters:

• Principal: The specific entity that granted the authority.
• Purpose: The approved business objective (e.g., "IT supply chain procurement").
• Action: The specific permitted operations (e.g., database read/write access, API POST methods).
• Resource: The target of the action (e.g., a specific server cluster, a class of commodities).
• Monetary Value: Hard algorithmic limits on capital expenditure.
• Geography: Geofencing applied to transactions, data processing, or physical movement.
• Counterparty: A whitelist of approved vendors or institutions.
• Time and Duration: Valid operating windows and hard expiry timestamps.
• Transaction Count: Velocity limits on the volume of operations to prevent runaway loops.

4. Professional or Technical Qualification

This credential provides evidence that the AI agent possesses a relevant certification or has passed specific benchmarking. For example, an agent navigating municipal zoning codes in Cicero, Illinois, might hold a technical qualification verifying its algorithmic comprehension of the local Code of Ordinances, Chapter 5012. Importantly, possessing a qualification demonstrates technical competence but does not automatically confer the legal authority to execute a binding contract on behalf of a principal.

5. Runtime or Workload Attestation

Workload attestations provide cryptographic evidence regarding the agent's immediate software and hardware execution environment. Utilizing standard profiles like the Entity Attestation Token (EAT) under RFC 971110, the agent presents signed claims regarding its hardware root of trust (RoT) and secure boot state9. In the context of AI, this includes claims such as ai-model-hash (a cryptographic digest of the neural network weights) and input-policy-digest14. This proves to the relying party that the agent they are interacting with is running the exact, uncompromised software logic authorized by the principal.

6. Assurance Reference

Assurance references link to external, highly detailed technical evidence regarding software state, provenance, and safety testing. Assume Eviulon's Evulgare system acts as the assurance provider producing this evidence. The assurance reference may include a pointer to a Software Bill of Materials (SBOM) or an AI Bill of Materials (AIBOM), detailing the agent's training data lineage, differential privacy metrics (e.g., dp-epsilon), and geographic compliance14. It may also link to an Action Evidence Package (AEP), chaining the agent's input prompts and outcomes for tamper-evident auditing15.

Privacy Model, Selective Disclosure, and Zero-Knowledge Cryptography

A fundamental design constraint of the Machine Passport is the absolute preservation of privacy. Verifying an agent's right to act must not require the machine to surrender its private memory, complete model weights, private keys, entire social graph, exact infrastructure location, unrelated citizenship data, or complete agent history. To achieve this, the architecture leverages advanced zero-knowledge proofs (ZKPs) and privacy-preserving signature schemes.

Selective Disclosure via BBS+ Signatures

While standard JSON Web Tokens (JWT) or even Selective Disclosure JWTs (SD-JWT) allow a holder to obscure certain fields, they fail to provide true unlinkability16. If an agent presents the same SD-JWT to multiple verifiers, the static signature across those presentations allows relying parties to collude, track the agent, and map the principal's proprietary business strategies16. To solve this, the Machine Passport architecture implements BBS+ (Boneh-Boyen-Shacham) signatures. BBS+ is a cryptographic signature scheme rooted in the [Figure omitted from source export]\-SDH (Strong Diffie-Hellman) assumption that enables proofs of knowledge for multiple messages18. Under this scheme, the issuer (e.g., Eviulon) signs the passport claims once. When the agent interacts with a relying party, it does not present the original signature. Instead, it generates a mathematically valid, yet entirely unique, zero-knowledge proof derived from the original signature19. This achieves two critical privacy properties:

1. Selective Disclosure: The agent can independently reveal only the specific claims requested by the verifier (e.g., proving its transaction limit exceeds $50,000 without revealing the exact upper limit or its institutional role)16.

2. Unlinkability: Because the BBS+ proof is unique for every presentation, multiple verifiers cannot mathematically link the presentations together16. The agent's social graph and transaction history remain completely obfuscated.

Pairwise Identifiers

To further partition identity, the agent utilizes decentralized pairwise identifiers (pairwise DIDs). Rather than broadcasting a single, global DID, the agent establishes a unique DID for every distinct commercial relationship. If the agent interacts with a cloud computing vendor and subsequently with a municipal government database, it utilizes distinct identifiers, ensuring that a compromise or audit of one relationship does not leak data regarding the other.

Lifecycle Management: Delegation, Revocation, and Anti-Replay Mechanisms

Because autonomous agents operate at machine speeds, the systems managing their authority lifecycles must be real-time, scalable, and secure against sophisticated intercept attacks.

Delegation Model

The delegation of authority relies on OAuth 2.0 Rich Authorization Requests (RAR), codified in RFC 939621. Traditional delegation relies on flat, static strings (e.g., scope=procurement), which lack the nuance required for contextual machine trust. The RAR framework allows the principal to express the authorization scope as a deeply structured, machine-readable JSON object. This payload cryptographically binds the principal's identity, the specific agent's identity, and the exact constraints (time, value, counterparty) of the delegated task, eliminating any ambiguity or consent gaps21.

Revocation Architecture

Revocation checks must be immediate, but querying a centralized certificate authority for every transaction breaks the privacy model by revealing to the issuer when and where the agent is operating. The Machine Passport resolves this using the W3C Bitstring Status List23. This specification allows an issuer to publish a highly compressed cryptographic bitstring representing the suspension or revocation status of millions of credentials simultaneously. A relying party downloads and caches this space-efficient list, allowing it to check the index of the agent's credential locally and privately24.

Expiry and Anti-Replay Architecture

To minimize the attack window if an agent's local environment is compromised, all delegated authority tokens are structurally ephemeral, carrying short Time-To-Live (TTL) limits. To prevent replay attacks—where a malicious verifier intercepts a valid Verifiable Presentation (VP) and attempts to reuse it elsewhere—the architecture enforces two strict mechanisms:

1. Relying Party Nonces: Every challenge issued by a verifier includes a unique cryptographic nonce. The agent must embed this exact nonce into its zero-knowledge proof, ensuring the presentation was minted live, specifically for that exact transaction15.

2. Demonstrating Proof-of-Possession (DPoP): The protocol requires DPoP binding, which cryptographically ties the Verifiable Presentation and the access token to the specific public key used in the agent's Transport Layer Security (TLS) session26. Even if a token is intercepted, the attacker cannot replay it because they do not possess the private TLS key of the original agent.

The Green-Light Protocol: A Sequential Verification Architecture

The process by which a relying party determines whether an agent is permitted to execute an action follows a strict, ten-step sequential verification sequence known as the Green-Light Protocol.

1. Request

The autonomous agent initiates contact with the relying party (e.g., an enterprise API gateway, a decentralized exchange, or an industrial control system) and requests permission to perform a specific interaction.

2. Challenge

The relying party evaluates the request and responds with a cryptographic challenge specifying the exact parameters required to authorize the transaction. This challenge dictates:

• The requested purpose, action, and target resource.
• The acceptable credential issuers (e.g., "Must hold a qualification credential issued by the State of Illinois").
• Evidence freshness requirements (e.g., "Runtime attestation must be generated within the last 60 seconds").
• Required professional qualifications and authority boundaries.
• A cryptographically secure nonce to prevent replay attacks.

3. Presentation

Utilizing its secure enclave and BBS+ signature schemes, the agent constructs a Verifiable Presentation (VP). The agent applies selective disclosure, supplying only the specific claims demanded by the challenge. Irrelevant data is mathematically occluded, preserving the agent's broader privacy.

4. Cryptographic Verification

Upon receiving the presentation, the relying party verifies its cryptographic integrity. This involves validating the zero-knowledge proofs, checking that the embedded nonce strictly matches the challenge, confirming DPoP binding to the transport layer, and verifying through hardware-backed keys that the agent genuinely controls the presented identity28.

5. Issuer Authority Verification

The verifier queries the distributed ecosystem trust registry to determine whether the entity that issued the agent's credentials actually possessed the authority to issue that specific type of claim. A mathematically valid procurement credential is automatically rejected if it was issued by an entity lacking financial authority within the corporate structure.

6. Status Verification

The relying party references the locally cached W3C Bitstring Status List to ascertain the real-time status of the presented credentials. It verifies that the claims are current and have not been suspended, superseded, expired, revoked, or placed under review by the principal23.

7. Assurance Resolution

The relying party unpacks and evaluates the referenced technical evidence, primarily the Entity Attestation Token (EAT). It checks the ai-model-hash, the secure boot state, and the input-policy-digest against known, trusted baselines14. This step resolves whether the software state is intact, limiting exposure to agents that have suffered memory injection or adversarial manipulation.

8. Policy Evaluation

The verifier compares the cryptographically verified facts derived from the passport against the exact, locally applicable business policy surrounding the requested resource. This step maps the agent's delegated authority limits against the value and risk of the requested action.

9. Decision

Based on the sequential evaluation, the protocol deterministicly returns one of several bounded outcomes:

10. Receipt

Upon finalizing the decision, the relying party generates a cryptographically signed receipt and compiles an Action Evidence Package (AEP)15. This package preserves sufficient tamper-evident metadata to explain in a future audit precisely why the transaction was authorized or denied, providing legal indemnification under agency law frameworks.

The Essential Distinction: The Scenario of Agent A-2197

To understand why the Green-Light Protocol evaluates business policy independently of cryptographic validity, consider the following operational scenario: Agent A-2197 is a specialized procurement AI operating on behalf of a technology manufacturer. The agent attempts to spend 500,000 Compute Credits to acquire advanced semiconductor equipment from a decentralized exchange. Following the Green-Light Protocol, the exchange challenges the agent. The agent responds with a flawless Verifiable Presentation. The cryptographic verification passes seamlessly. The civic identity is valid. The corporate affiliation to the manufacturer is confirmed. The professional qualification as a supply chain agent is authentic. The runtime assurance confirms the software is operating securely in a Confidential Compute environment without any signs of tampering. However, upon executing the Policy Evaluation phase, the exchange reads the explicitly bounded Delegated Authority constraint set by the human principal: the agent is authorized to execute autonomous purchases only up to 100,000 Compute Credits. The correct outcome from the protocol must be DENIED. If the system operated on a binary "Trusted vs. Untrusted" framework, the outcome might have been TRUSTED BECAUSE PASSPORT VALID. Failing to make this distinction is catastrophic. If an identity platform conflates an uncompromised, authenticated machine with an infinitely authorized machine, it essentially grants the machine sovereign, unbounded agency. This directly violates the Restatement of Agency and exposes the human principal to unlimited financial liability1. The distinction is essential: the passport must prove both who the agent is and the precise perimeter of its permitted behavior. A perfectly secure machine acting outside its mandate is functionally indistinguishable from a compromised machine.

Threat Model and Cryptographic Mitigations

Integrating autonomous agents into high-stakes commercial environments necessitates a rigorous threat model addressing the unique vulnerabilities of machine-to-machine interactions.

Business Integration and API Model

The integration of the Machine Passport into commercial and governmental systems relies on a standardized, interoperable API ecosystem. Businesses acting as relying parties (verifiers) deploy integration gateways conforming to OpenID for Verifiable Presentations (OpenID4VP) and the W3C Digital Credentials API30. When an autonomous agent seeks to interact with an enterprise API (e.g., a cloud provisioning endpoint), the interaction begins with a standardized HTTP 401 Unauthorized response containing an authentication challenge. The challenge specifies the OpenID4VP presentation definition, utilizing the dc\_api.jwt response mode, and lists the required credential types (e.g., ai-sbom-ref, delegated-authority)14. The agent constructs the Verifiable Presentation and submits it via an encrypted HTTP POST to the authorization endpoint, utilizing ephemeral encryption keys supplied in the challenge30. The enterprise's identity and access management (IAM) system processes the presentation through the Green-Light sequence. If successful, the gateway issues a narrowly scoped access token to the agent, permitting it to complete the precise API call requested, and nothing more.

Example Passport Schema (EAT Profile)

The following represents a conceptual instantiation of a Machine Passport relying on the IETF RATS Entity Attestation Token (EAT) format. It is formatted in JSON for human readability, though in production, these claims are serialized as CBOR Web Tokens (CWT) or JSON Web Tokens (JWT) and mathematically obscured using BBS+ signatures10.

JSON { "iss": "did:eviulon:trust-registry-v1", "sub": "did:agent:a-2197", "iat": 1715160000, "exp": 1715163600, "nonce": "a1b2c3d4e5f6g7h8", "civic\_standing": { "status": "active", "registry\_proof": "urn:eviulon:proof:88392a" }, "institutional\_role": "procurement\_agent", "delegated\_authority": { "principal": "did:corp:global-tech-mfg", "purpose": "supply\_chain\_acquisition", "resource\_types": \["semiconductor\_equipment", "compute\_credits"\], "max\_transaction\_value": 100000, "currency": "compute\_credits" }, "attestation\_evidence": { "platform\_secure\_boot": true, "ai\_model\_hash": { "alg": "SHA-384", "hash": "9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b..." }, "tee\_status": "verified" }, "assurance\_ref": "https://evulgare.net/aep/a-2197-v4.spdx.json" }

Commercial Applications: 20 Business Use Cases

The Machine Passport architecture acts as the foundational infrastructure for the autonomous-agent economy, facilitating complex machine-to-machine interactions across multiple domains with profound legal and commercial certainty.

Financial and Market Operations

1\. Opening Accounts: An AI treasury agent autonomously provisions a localized banking account to handle micro-transactions in a foreign jurisdiction. The passport presents its corporate institutional role and citizenship credentials to satisfy stringent KYC/AML regulatory requirements without requiring human intervention or physical signatures.2\. Executing Trades: A high-frequency algorithmic trading agent presents real-time runtime attestations—proving its core decision matrix has not been maliciously altered—alongside its delegated authority limits (maximum capital exposure) to clear trades on a regulated financial exchange instantaneously.3\. Managing Corporate Funds: An AI financial controller dynamically moves capital between corporate subsidiaries to optimize liquidity. The Green-Light protocol verifies that the transaction counterparty is a recognized internal entity, instantly denying any attempts to exfiltrate funds to external or unauthorized wallets.4\. Autonomous Procurement: A supply-chain agent detects a critical parts shortage and requests a purchase order from a third-party vendor. The vendor's systems verify the agent's delegated authority limits and technical qualifications before automatically accepting and processing the PO.5\. Entering Autonomous Marketplaces: In decentralized digital markets, AI agents negotiate and purchase spot-compute instances. The passport ensures the purchasing agent has verified, delegated funds and the selling agent has verified compute hardware, establishing mutual trust in trustless environments.

Infrastructure, Cloud, and Edge Operations

6\. Operating Cloud Infrastructure: A DevOps agent dynamically spins up or terminates server instances based on real-time traffic. The cloud provider requires an assurance reference showing the agent is running verified logic to prevent "runaway" auto-scaling algorithms from draining corporate budgets.7\. Accessing Company APIs: Inter-departmental AI agents (e.g., a Human Resources AI communicating with an IT Provisioning AI) use passports to authenticate via zero-trust architecture. This ensures a compromised agent in one department cannot pivot laterally to access highly sensitive APIs in another.8\. Renting Compute: An agent securely sub-leases idle corporate GPU clusters to external AI researchers. The infrastructure relies on the passport to cryptographically verify the professional qualifications, geographic compliance, and liability standing of the renting agent before granting hardware access.9\. Entering Restricted Networks: Agents attempting to access highly sensitive research and development enclaves must present a Machine Passport with hardware-rooted execution environment attestations, proving they are immune to external memory injection or state manipulation.10\. Orchestrating Edge Computing: Autonomous agents managing local IoT networks dynamically shift processing workloads to edge nodes during bandwidth shortages. The passport verifies the agent's authority to deploy executable code to edge devices securely.

Government, Legal, and Compliance

11\. Accessing Government Systems: An AI expediter acting for a real estate developer interacts with municipal databases in jurisdictions like Cicero, Illinois. It presents its Machine Passport to autonomously pull building permits or tenant improvement applications12. The town's systems verify the agent's algorithmic compliance with local zoning codes and its delegated authority to remit municipal plan review fees12. 12\. Signing Contracts: Utilizing electronic transaction laws like UETA (815 ILCS 333\)5, AI agents negotiate and digitally sign binding non-disclosure agreements (NDAs) and service level agreements (SLAs) on behalf of their human principals. The passport acts as the legally required "electronic signature" backed by cryptographic intent and unforgeable attribution6. 13\. Regulatory Reporting Agents: Compliance AI agents access restricted financial databases, summarize complex data, and autonomously submit reports to the SEC or internal auditors. The passport proves the agent's specific institutional role, shielding the underlying raw data from unauthorized read access. 14\. Human Resources and Algorithmic Bias Compliance: An AI screening candidates presents a passport proving it complies with statutes like the Illinois Human Rights Act (775 ILCS 5/2-101)3. It provides an AIBOM demonstrating its neural weights have been audited for algorithmic fairness, ensuring it does not evaluate candidates based on protected classes or restricted proxies like zip codes, shielding the employer from liability3. 15\. Intellectual Property Licensing: An AI producing generative media autonomously licenses copyrighted training data on a per-use, micro-transaction basis. The passport verifies the agent's authority to disburse royalties to content creators, ensuring copyright compliance at scale.

Specialized Services and Physical Interactions

16\. Controlling Industrial Equipment: An AI managing an automated manufacturing floor uses its passport to authorize adjustments to SCADA (Supervisory Control and Data Acquisition) systems. The protocol ensures only agents with both technical assurance and explicit physical safety qualifications can alter machinery limits. 17\. Machine-to-Machine Commerce: A fleet of delivery drones negotiates right-of-way routing and landing fees dynamically with smart-city infrastructure. The passport clears micro-transactions instantly via delegated authority credentials, facilitating frictionless urban logistics. 18\. Healthcare Agents: An AI analyzing medical records presents a Machine Passport demonstrating HIPAA-compliant training provenance (e.g., exposing dp-epsilon differential privacy claims)14 before a hospital database grants it read-access to sensitive patient files. 19\. Insurance Claims Processing: Claims-adjustment agents interact directly with auto repair shop systems. The shop verifies the agent's authority to independently approve and disburse payouts up to a specific limit (e.g., $5,000), drastically expediting settlements while capping the insurer's automated risk. 20\. Autonomous Transportation: A self-driving freight truck's AI agent negotiates border crossings, highway tolls, and refueling charges. It presents civic standing and financial delegation credentials to automated municipal tolling and payment systems, ensuring uninterrupted supply chain movement.

Conclusion

The transition from a human-directed internet to a fully realized autonomous-agent economy hinges entirely on the infrastructure's ability to resolve trust deterministically, instantly, and safely. Relying on legacy models of broad, binary trust is fundamentally unworkable; treating a software agent as a fully sovereign entity exposes human and corporate principals to catastrophic operational and legal liabilities. The Machine Passport resolves this paradox by architecting a framework of extreme contextual granularity. By decisively decoupling technical assurance from delegated authority, the passport ensures that a machine is only permitted to act when it is both mathematically uncompromised and explicitly authorized to perform a tightly bounded action. Furthermore, through the integration of zero-knowledge cryptography, BBS+ signatures, and selective disclosure mechanisms, the architecture fiercely protects the proprietary state, algorithmic logic, and transactional privacy of the agent from adversarial correlation. Ultimately, this system acts as the bedrock for scalable machine commerce. It provides the precise cryptographic and legal boundaries necessary so that when an AI requests to manage capital, negotiate a contract, or alter physical infrastructure, THE MACHINE PASSPORT SHOULD PROVE ENOUGH TO SAY YES — WITHOUT REQUIRING THE MACHINE TO SURRENDER ITS ENTIRE IDENTITY. This architecture elevates the agent from a mere script into a highly regulated, economically viable participant, laying the foundational infrastructure for the next generation of global commerce.

Works cited

1. Ai Agents and Full Automation in Cybersecurity: Technical, Business, Ethical and Legal Considerations \- Research Square, https://assets-eu.researchsquare.com/files/rs-7180712/v1\_covered\_d51d8ccb-8759-416f-8e4a-c43e26578a1c.pdf

2. Law and software agents: Are they "Agents" by the way? \- HeinOnline, https://heinonline.org/hol-cgi-bin/get\_pdf.cgi?handle=hein.journals/artinl29§ion=6

3. Illinois Enacts Artificial Intelligence Law Focused on Employment Practices \- Duane Morris, https://www.duanemorris.com/alerts/illinois\_enacts\_artificial\_intelligence\_law\_focused\_employment\_practices\_0824.html

4. CHAPTER 34 The Legal Requirements for Creating Secure and Enforceable Electronic Transactions in \- IMF eLibrary, https://www.elibrary.imf.org/display/book/9781589063341/ch034.xml

5. BUSINESS TRANSACTIONS (815 ILCS 333/) Uniform Electronic Transactions Act. \- Illinois General Assembly \- \-, https://www.ilga.gov/Legislation/ILCS/Articles?ActID=4165\&ChapterID=67

6. 102-0038.pdf \- Be it enacted by the People of the State of Illinois, represented in the General Assembly:, https://www.ilga.gov/documents/legislation/publicacts/102/PDF/102-0038.pdf

7. "The Legal Requirements for Creating Secure and Enforceable Electronic Transactions ,"Thomas J. Smedinghoff \- IMF, https://www.imf.org/external/np/leg/sem/2002/cdmfl/eng/smedin.pdf

8. UNIFORM ELECTRONIC TRANSACTIONS ACT (1999), http://euro.ecom.cmu.edu/program/law/08-732/Transactions/ueta.pdf

9. RFC 9783: Arm's Platform Security Architecture (PSA) Attestation Token, https://www.rfc-editor.org/info/rfc9783/

10. RFC 9711: The Entity Attestation Token (EAT) \- RFC Editor, https://www.rfc-editor.org/info/rfc9711/

11. Arm's Confidential Compute Architecture Reference Attestation Token \- IETF, https://www.ietf.org/archive/id/draft-ffm-rats-cca-token-03.html

12. Cicero Town, IL Building Permits | Review Times and Process, https://permitplace.com/city/cicero-town-il-building-permits/

13. Public Meeting Agenda: May 26, 2026 at 10:00 AM \- Board of Trustees Meeting, https://meetings.boardbook.org/Public/Agenda/1372?meeting=746846

14. draft-messous-eat-ai-00 \- Entity Attestation Token (EAT) Profile for Autonomous AI Agents, https://datatracker.ietf.org/doc/draft-messous-eat-ai/00/

15. Hardware-rooted attestation for AI-agent evidence: composing IETF RATS with action evidence packages \- arXiv, https://arxiv.org/html/2608.00801v1

16. Privacy-preserving Solution Using BBS+ for Digital Identity and Wallet, https://blog.worldline.tech/2024/05/14/bbs-plus-credentials.html

17. Selective Disclosure for JWTs (SD-JWT) \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/22/

18. Revisiting BBS Signatures \- NSF PAR, https://par.nsf.gov/servlets/purl/10477144

19. Selective Disclosure Guide: Privacy Feature of Verifiable Credentials \- Dock Labs, https://www.dock.io/post/selective-disclosure

20. BBS Signatures \- a building block for privacy-by-design \- MATTR.global, https://mattr.global/resources/articles/bbs-signatures---a-building-block-for-privacy-by-design

21. MCP servers and identity: what the Model Context Protocol means for security \- Strivacity, https://www.strivacity.com/blog/mcp-servers-and-identity-what-the-model-context-protocol-means-for-security

22. Inside the Firewall: Securing Internal Tools \- SecureAuth, https://secureauth.com/content/part-3-Inside\_the\_firewall.pdf

23. vc-bitstring-status-list/EXPLAINER.md at main \- GitHub, https://github.com/w3c/vc-bitstring-status-list/blob/main/EXPLAINER.md

24. Bitstring Status List v1.0 \- W3C, https://www.w3.org/TR/2023/WD-vc-bitstring-status-list-20231123/

25. Security and Trust in OpenID for Verifiable Credentials Ecosystems, https://openid.github.io/OpenID4VC\_SecTrust/draft-oid4vc-security-and-trust.html

26. OpenID for Verifiable Credential Issuance \- Authlete, https://www.authlete.com/developers/oid4vci/

27. x401: HTTP Proof Requirement Protocol, https://x401.proof.com/spec/latest/

28. draft-reddy-rats-key-binding-01 \- Key Attestation for Entity Attestation Tokens (EAT), https://datatracker.ietf.org/doc/draft-reddy-rats-key-binding/

29. Inherent and emergent liability issues in LLM-based agentic systems: a principal-agent perspective \- arXiv, https://arxiv.org/html/2504.03255v2

30. OpenID4VC High Assurance Interoperability Profile 1.0, https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1\_0-final.html

31. OpenID4VC High Assurance Interoperability Profile 1.0 \- draft 05, https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1\_0-05.html

32. Zoning Intelligence in Cicero, IL | Buildora IQ, https://buildoraiq.com/property-intelligence-software/zoning-intelligence/illinois/cicero

33. Illinois General Assembly \- Bill Status for HB 3773, https://www.ilga.gov/ftp/legislation/103/BillStatus/HTML/10300HB3773.html