{"slug": "a-bgp-inspired-identity-network-for-autonomous-ai-agents", "title": "A BGP-Inspired Identity Network for Autonomous AI Agents", "summary": "Telecommunications engineer Rodrigo Montiel proposed Universal Agent Identity (UAI), an open protocol and reference implementation for identifying, authorizing and verifying autonomous AI agents, with a Python SDK published on GitHub. UAI comprises four components — UAI-ID for agent identification, UAI Credential for ownership and granted capabilities, UAI Passport for time and jurisdictional scope limits, and UAI Action Attestation for signed statements about actions and their authorization context — and is described as BGP-inspired, with independent registries exchanging verifiable identity statements. Montiel states the project's core distinction is that \"an identified agent is not, simply by being identified, a safe agent,\" and that UAI does not grant software legal personhood.", "body_md": "**By Rodrigo Montiel**\n\n*UAI (Universal Agent Identity) proposes identifying, authorizing, and verifying — not certifying that an AI system is harmless (yet?)*\n\nThis is my first scenario and concern. Imagine an ordinary moment in the near future: an agent is asked to optimize an operation. It retrieves information, uses tools, and changes a configuration. Something goes wrong :/\n\nThe organization discovers that the action is attributed to a service account. But that account alone cannot reconstruct who delegated the task, which agent instance performed it, what permissions it held, or which policy was in force.\n\nWhat concerns me is **what we will be able to prove when an agent acts on our behalf**.\n\nI think we do not need to assume an inevitable catastrophe to take that question seriously. Agent safety documentation already addresses concrete risks, including malicious instructions embedded in external content and information leakage through tools. NIST also provides a dedicated profile for managing generative AI risks. This problem deserves engineering.\n\nThat concern is the starting point for my idea of **Universal Agent Identity, UAI**: like an open protocol and reference implementation exploring identity, authorization, and verifiable accountability for autonomous agents.\n\nThinking about boundaries, for some reason BGP (Border Gateway Protocol) comes to my mind. I meant, in a long-term vision, my tool is **BGP-inspired**: independent registries exchanging verifiable identity statements while retaining their own policies and authority.\n\nI am not presenting it as the definitive answer to AI risk. I am presenting it as a small human contribution to a question I consider fundamental: **how do we keep delegated autonomy from becoming a loss of traceability and accountability?**\n\nThe project’s most important distinction fits on a single line:\n\n**An identified agent is not, simply by being identified, a safe agent.**\n\nAn identity does not establish good intentions nor guarantee beneficial outcomes. And a cryptographic signature does not demonstrate that software behaved correctly.\n\nThis vision aims to make something else verifiable: the relationship between an identity, a declared accountable owner, a set of capabilities, an authorization decision, and a signed statement about what happened. These distinctions are explicit in my project.\n\nNor does UAI seek to give software legal personhood. The analogy with a national ID is useful for explaining identification, not for equating an agent with a human being or automatically assigning culpability to its owner.\n\nFrom a product perspective, the proposal has four components. **UAI-ID** identifies the agent. **UAI Credential** expresses ownership relationships and granted capabilities. **UAI Passport** limits the time and jurisdictional scope of certain operations. **UAI Action Attestation** preserves a signed statement, linked to the event history, about an action and its authorization context.\n\nThe passport is an authorization within the ecosystem, not a permit issued by a state. It does not expand privileges: a capability the owner never granted cannot appear simply because a passport was issued.\n\nConsider an agent that organizes deliveries and requests access to a resource in another jurisdiction. Before the operation, we want to verify its identity, the requested capability, the applicable restrictions, and the version of the policy that permits or denies access.\n\nAfterward, we want more than a text message in a log: a signed statement connecting those elements to the recorded outcome, including denials and errors.\n\n**Disclaimer:** My background is in telecommunications engineering. I’m learning as I build UAI, using AI tools to assist with implementation.\n\nMy [README](https://github.com/rodmontiel/uai) illustrates this intent through the Python SDK:\n\n```\nwith agent.action( capability=\"route.optimize\", purpose=\"delivery_optimization\", jurisdiction=Jurisdiction( origin=\"AR\", targets=(\"DE\",), basis=\"resource_location\", ), input=order,) as act: act.output = optimize(order)\n```\n\nIn this flow, the SDK checks the policy before entering the block. If the operation is denied, that business logic does not execute. The design also supports attesting failed outcomes, not only successful operations.\n\nControls before an action and evidence after it serve different purposes. An SDK does not replace external controls over tools and infrastructure.\n\nThe implementation documents Ed25519 signatures, canonicalized JSON documents, and events linked through hashes and sequence numbers. On the other hand, Canonicalization produces a deterministic representation: two implementations need to sign the same bytes, even when their original JSON differs in field order or spacing.\n\nThe transparency layer adds receipts and Merkle-tree inclusion proofs. The browser verifier checks cryptographic material locally rather than merely displaying a verdict returned by the server.\n\nSeems to be obvious, this does not eliminate every trust assumption. Verifiers still need to trust their verification software, the keys they accept, and their chosen trust anchors. But it makes the checks explicit and reduces dependence on an API that certifies its own assertions.\n\nOne limitation belongs at the center of this discussion: **an attestation proves a signed statement; it does not, by itself, prove that an external effect occurred**.\n\nThe manual acknowledges this. Stronger evidence would require the receiving system to provide its own signed confirmation: for example, the API that applied a configuration change or the service that accepted an operation. That counter-attestation is not **yet** implemented.\n\nThere is also an enforcement boundary. An SDK runs inside the agent’s process; a compromised agent may try to bypass it. A real deployment therefore needs enforcement points around tools, APIs, and resources, outside whatever the agent voluntarily chooses to record.\n\nSo… UAI does not replace isolation, least privilege, or runtime security. Verifiable identity can complement those defenses; it does not make them unnecessary. That is my starting point. SPIFFE, one of the technologies used by the project, addresses workload identity through short-lived cryptographic credentials.\n\nUAI already has a reference implementation for exploring these ideas. The README lists specifications, JSON schemas, OpenAPI, PostgreSQL persistence, cryptography, policy evaluation, transparency mechanisms, governance and revocation, smart contracts, a browser verifier, SDKs for Go, Python, and TypeScript, and MCP integration. This is an initial architecture of components, not a definitive guide (has to do with what I can see as beneficial for this implementation).\n\nIt also documents end-to-end demonstrations and a **bilateral federation prototype**. That progress should not be mistaken for certified infrastructure or global production readiness: security validation, production hardening, and full federation remain unfinished.\n\nTwo limitations are particularly important. Owner verification remains self-asserted. In addition, the transparency-log witnesses run on the same machine: the co-signing mechanism exists, but genuine independence between operators does not.\n\nThese distinctions matter. Having a field called “owner” is not the same as verifying an organization. Having two witnesses is not the same as having two independent institutions observe the same history.\n\n**That being said, we can keep in mind that trust infrastructure earns credibility by making the limits of its guarantees visible.**\n\nThis question got me thinking: **what happens when one organization needs to recognize agents registered by another? Is this a possibility in our internet?**\n\nThe answer I explore with UAI is not a worldwide database controlled by a single entity. It is a network of independent registries.\n\nThe inspiration comes from Internet Autonomous Systems and BGP.\n\nMy background in telecommunications engineering shaped the way I approached this problem. That is where the BGP analogy comes from: independent domains cooperating while retaining their own policies and authority. This is a protocol that exchanges reachability information between independently administered domains. The useful parallels are operational autonomy, explicit relationships between peers, and local decisions about what to accept.\n\n**But my BGP inspiration does not mean BGP-based.** UAI does not use BGP to route agent identities. A **UAI-AS** represents an installation with its own identity and keys, capable of exchanging signed statements about agents. It does not route packets, and its identifiers are not official Internet AS numbers.\n\nIn the [current prototype](https://github.com/rodmontiel/uai), two registries configure each other explicitly. A signed exchange, REGISTRY_HELLO, identifies the peer; an IDENTITY_ANNOUNCEMENT then communicates a statement about an identity issued by the origin. The receiver checks the signature, freshness, and sequence, applies authority checks, and stores remote information separately from its local agents.\n\nAccepted keys must be established carefully. Verifying a message against a key supplied inside that same message does not establish that it came from the expected sender. The demonstration explicitly distinguishes exchanging keys through an independent channel from trusting whoever answers on first contact.\n\nBGP-inspired federation: bilateral exchange today, interconnected domains as a future vision. The nodes do not represent participating organizations or existing agreements.\n\nThe principle underpinning federation is simple:\n\n**Accepting a registry as a peer does not mean authorizing all of its agents.**\n\nThe network does not distribute a universal seal of trust. It distributes verifiable statements, and each participant retains the decision to accept them.\n\nThe next challenge is proving who has authority to issue identities within a namespace, beyond a bilateral agreement. Another analogy becomes relevant here: RPKI and Route Origin Authorizations allow verification that a resource holder has authorized an AS to announce particular prefixes. UAI could explore an equivalent mechanism for its registries, without presenting it as an already implemented feature.\n\nMulti-hop transit, path selection, automatic discovery, confederations, and cross-registry revocation propagation remain future work.\n\nIn such a network, control should not mean that a central administrator can unilaterally decide which agents may exist. The proposed architecture separates responsibilities: a registry issues information, an authorized governance body produces a decision, and a participating service determines how to enforce it within its own domain.\n\nI would imagine a future incident. The originating registry publishes a signed quarantine notice linked to a case, a policy, and a defined scope. Recipients verify the issuer’s authority, the notice’s validity, and its sequence. They then apply local rules to restrict operations. **That distributed workflow is a future direction, not a current federation capability.**\n\nDesigning it **still** requires concrete answers. How long can a preventive restriction last? How is a false accusation reviewed? What happens when two authorities disagree? What happens if a registry disappears or loses its keys?\n\nThis small prototype already explores governance mechanisms for permanent revocations. The project describes a threshold of four votes from five delegates spanning at least three jurisdictions, with votes bound to WebAuthn user verification (the four-of-five threshold is an experimental parameter, not an established governance standard). The administrator has a read-only role, with a narrowly defined exception for executing a previously authorized decision.\n\nThese parameters describe an experimental model. They do not represent an international agreement, participating countries, or an established judicial authority. Cryptography can verify a vote; it cannot, by itself, determine the legitimacy of the voter or eliminate collusion. The project explicitly recognizes collusion as a residual risk.\n\n**Important and essential:** *revoking an identity does not switch off its code everywhere on Earth*. Participants can stop honoring credentials and reject operations. A machine outside that ecosystem may continue running the program.\n\nUAI does not promise a universal kill switch. Revocation changes what participating systems will accept; it does not stop code running outside that ecosystem (at least, not yet).\n\nI have made some exploration on Smart Contracts in the past. Blockchain is not an arbitrary choice here. I believe it has a possible and bounded role in this architecture: preserving cryptographic commitments and historical checkpoints.\n\nIn the documented design I use commitments with random values, or *salts*, to avoid directly publishing sensitive inputs, outputs, or evidence. A plain hash of predictable data can be guessed by testing candidate values; “we only store hashes” is therefore not a sufficient privacy argument.\n\nRecording a commitment on a blockchain does not make the original statement true. It helps establish that particular evidence was committed and makes certain alterations detectable, subject to the assumptions of the network and its verification mechanisms.\n\nThe repository includes contracts and anchoring mechanisms.\n\nThe federation network and the blockchain are not the same thing. One would exchange state and authority; the other would support historical evidence. Conflating them would make it harder to understand what each component guarantees.\n\nThe following sequence would be proposed evolution based on documented capabilities and gaps.\n\nCurrent capabilities and limitations come from the repository. Future sequencing is proposed and does not imply delivery commitments.\n\n**The first priority is strengthening the prototype’s guarantees.** That includes stronger owner verification, genuinely independent witnesses, better operational defenses, and external review of both implementation and protocol. The security policy lists outstanding work such as rate limiting, domain-control proof, artifact signing, and cross-instance fork observation.\n\n**The next horizon is verifiable cooperation between operators.** I propose prioritizing origin authority, status propagation and freshness, key recovery, and pilots involving independent entities. The validation question would be whether a third party can verify and apply a decision without blindly depending on its issuer.\n\n**A broader BGP-inspired network remains a research horizon.** This includes transit, discovery, confederations, and federated passports. A confederation could group registries while retaining clearly defined internal responsibilities; it would not need to become a universal authority. The [README](https://github.com/rodmontiel/uai) identifies these extensions as unfinished.\n\nFor a CTO, a CISO, or an agent-platform team, the question should not end with how many agents can be deployed. It should also include how many can be identified, what limits can be enforced, and what evidence will remain when something fails.\n\nThe invitation is not to install a prototype in a critical production environment or immediately replace existing infrastructure. It is to explore a bounded use case, without sensitive data, and test the complete chain: identity, permission, decision, outcome, and verification from another domain.\n\nA pilot could measure the coverage of attested actions, verification latency, resistance to replayed messages, behavior during outages, and the time needed to apply restrictions once propagation is implemented. These would be pilot measurements, not results UAI has already demonstrated at scale.\n\nThere is room for contributions in security, identity, distributed systems, agent tooling, and independent verifiers. There is also room to challenge the protocol itself. A reproducible test that disproves an assumption may contribute more than another interface.\n\nThe [repository](https://github.com/rodmontiel/uai) releases its reference implementation under Apache-2.0 and additionally makes the specification available under CC-BY-4.0. It includes instructions for running the demonstrations; sensitive findings should follow its private reporting policy.\n\n```\ngit clone https://github.com/rodmontiel/uai.gitcd uai./deploy.sh upmake demomake federation-demo\n```\n\nThese are the project’s documented commands for starting the implementation and exploring its demonstrations.\n\nI do not believe a digital identity can, on its own, resolve the dangers of artificial intelligence. Nor do I believe we can delegate to another model the final decision about what we should accept as safe.\n\nPerhaps the result will be a more mature protocol. Perhaps parts of the work will find a place in other ecosystems. Perhaps the most valuable contribution will be exposing a limitation we had not yet understood.\n\nThe BGP-inspired vision gives this work a direction: independent domains cooperating through an open protocol, without requiring a single global identity database.\n\nThe project is open to anyone who wants to take that exploration further.\n\n**Remember: This is about building better foundations for knowing who acted, under what authority, and what evidence remains.** [Explore UAI on GitHub](https://github.com/rodmontiel/uai)\n\n[1] [UAI: README](https://github.com/rodmontiel/uai/blob/3debb0ccba8bc25ac62527e1ac25fdcb554e9619/README.md).\n\n[3] [UAI: Practical federation example](https://github.com/rodmontiel/uai/blob/3debb0ccba8bc25ac62527e1ac25fdcb554e9619/docs/Ejemplo_Practico_federation_es.md).\n\n[4] [UAI: Security policy](https://github.com/rodmontiel/uai/blob/3debb0ccba8bc25ac62527e1ac25fdcb554e9619/SECURITY.md).\n\n[5] [RFC 4271: Border Gateway Protocol 4](https://www.rfc-editor.org/info/rfc4271/).\n\n[A BGP-Inspired Identity Network for Autonomous AI Agents](https://pub.towardsai.net/a-bgp-inspired-identity-network-for-autonomous-ai-agents-9cf0d40058cb) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/a-bgp-inspired-identity-network-for-autonomous-ai-agents", "canonical_source": "https://pub.towardsai.net/a-bgp-inspired-identity-network-for-autonomous-ai-agents-9cf0d40058cb?source=rss----98111c9905da---4", "published_at": "2026-10-07 15:01:05+00:00", "updated_at": "2026-10-07 15:20:21.175822+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "agent-protocols", "ai-policy"], "entities": ["Rodrigo Montiel", "Universal Agent Identity", "UAI", "UAI-ID", "UAI Credential", "UAI Passport", "UAI Action Attestation", "NIST"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/a-bgp-inspired-identity-network-for-autonomous-ai-agents", "markdown": "https://wpnews.pro/news/a-bgp-inspired-identity-network-for-autonomous-ai-agents.md", "text": "https://wpnews.pro/news/a-bgp-inspired-identity-network-for-autonomous-ai-agents.txt", "jsonld": "https://wpnews.pro/news/a-bgp-inspired-identity-network-for-autonomous-ai-agents.jsonld"}}