DEV Community: Chris Hood

The Industry’s Mess with IAM for Agents

Chris Hood — Fri, 12 Jun 2026 15:32:32 +0000

Every identity vendor in the IAM space ships the same architecture. A directory holds the records. Each entity gets an identifier assigned by the directory. Authentication produces a token. Authorization is policy attached to the identifier. Audit is application-layer logging that references the identifier. This architecture has run human identity for 30 years and workload identity for 10 years. It is what every IAM vendor is now retrofitting for agents.

The retrofit will fail, and the reasons are structural.

The IAM industry built its tools for a problem shape that fails to match agents. Humans show up at workstations with phones in their pockets. Workloads run inside organizational perimeters with metadata services nearby. Agents do something different. They cross organizational boundaries. They outlive their operators. They act on behalf of multiple principals at once. They negotiate contracts at runtime. They get retrained, transferred, federated, and audited across regulatory regimes. The directory-and-token model was never built to handle any of this, and asking it now produces the same kind of failure mode that HTTP produces when stretched into agent transport. The substrate is wrong, and the fixes that get layered on top create new attack surfaces faster than they close the old ones.

AGTP is a different architecture. The identifier is content-derived rather than assigned. The identity is a structured set of artifacts rather than a row in a database. The protocol itself enforces it rather than leaving it to applications. This article walks through what those choices mean in practice, why they matter specifically for agents, and why no IAM vendor has shipped them.

An ID is the smallest part of identity

The first thing to be honest about is that “identity” in the IAM industry has become a synonym for “identifier.” The product is an ID and a way to authenticate that someone is allowed to use it. The Okta directory holds your user record. The Entra ID directory holds your principal. The SailPoint platform manages who has access to what. Every conversation about identity collapses into a conversation about IDs.

For humans and workloads, this collapse is mostly fine. The human’s identity outside the workplace is somebody else’s problem. The workload’s identity is short-lived and operator-defined. The directory’s view is sufficient for the directory’s purpose.

For agents, the collapse breaks. An agent’s identity must have sufficient structure to answer questions the IAM industry has never asked.

What is the agent’s origin? Who issued it into existence and signed off on its being permitted to operate? The Genesis answers this. It is a signed document recording the agent’s archetype, the registrar that issued it, the owner accountable for it, the activation timestamp, and the verification path that backs the registration.

What is the agent’s current operational state? The Manifest answers this. It is a separately resolvable document declaring the agent’s capabilities, methods, scope acceptance, policies, and current lifecycle state. The Manifest can be refreshed independently of the Genesis as the agent’s operational profile evolves.

What has the agent done? The Attribution Log answers this. Every consequential interaction produces a signed Attribution-Record that names the agent, the principal who authorized the action, the counterparty, and the result. The records flow into append-only transparency logs aligned with RFC 9162 and SCITT (RFC 9943).

What has been verified about the agent? The Trust Tier answers this. Tier 1 means full cryptographic verification through one of three documented paths. Tier 2 means organizational assertion. Tier 3 means experimental. The tier travels with the Manifest and is visible to every counterparty.

How has the agent behaved? The Behavioral Trust Score answers this. It is computed from the Attribution Log activity, signed by ANS operators, and surfaced in discovery responses. The score is no vendor’s proprietary risk number. It is a verifiable summary of the agent’s recorded behavior across the network.

Where did the agent come from? The Genesis Lineage answers this. As the agent’s underlying model gets retrained, its owner changes, or its governance zone evolves, the lineage chain records each transition. The lineage is the provenance document that lets a regulator three years from now reconstruct what happened.

What can the agent currently do? The Authority-Scope, declared for every request and bound to the Agent-ID through certificate commitments, answers this question. The scope is more than a directory entry. It is a wire-level claim the protocol enforces before the application runs.

Eight different artifacts, each answering a different question. The Agent-ID is the handle into all of them. It is the smallest part of identity rather than the whole. Treating the ID as identity, as the IAM industry has been doing for thirty years, leaves the other seven parts in vendor-proprietary formats or nowhere at all.

Why the ID has to be canonical

The IAM industry assigns IDs. The directory operator decides what your user object’s ID is, what its GUID looks like, what its DN string contains. The ID is whatever the directory says it is. Change directories, and the ID changes. Lose the directory, and the ID is gone. Trust the directory, and the ID is trustworthy. Distrust the directory, and the ID is nothing.

For humans, this is acceptable because humans have other forms of identity that outlive any single directory. Social security numbers, passports, biometrics. The IAM directory is one view of the human, and the human persists across many such views.

For agents, this is unacceptable. The directory’s view IS the agent. Lose the directory, lose the agent. Change operator policy, change the agent’s identity. The directory is a single point of failure for the agent’s existence.

AGTP takes the opposite approach. The Agent-ID is the SHA-256 hash of the canonical bytes of the Agent Genesis document. The identifier exists because the document exists. Nobody assigns it. Nobody can change it without changing the document. Anyone with a copy of the Genesis can verify the identifier by hashing.

This is the same primitive that Bitcoin uses for addresses, that Git uses for commits, that IPFS uses for content. Content-derived identifiers have specific properties that assigned identifiers lack.

Self-certifying. Verification works by hashing. The identifier and the content are inseparable. If somebody hands you an Agent-ID and a Genesis, you can verify the binding in milliseconds without contacting any third party.

Tamper-evident. Any change to the Genesis produces a different Agent-ID. Forgery requires either solving the hash function (computationally infeasible) or producing a new Genesis (which is a new agent).

Portable. The identifier travels with the document. It has no binding to a database, a host, or a domain. Moving an agent across infrastructures preserves its identifier exactly.

Operator-independent. No issuing authority can revoke or reassign an Agent-ID. The identifier exists for as long as the Genesis exists. Registrars federate to preserve the Genesis attestations, but no single registrar holds the identifier in trust.

Globally unique without coordination. 256 bits of cryptographic hash gives collision resistance well beyond any plausible population of agents. Two different Genesis documents will never produce the same Agent-ID, regardless of who issued them or where they live.

Surveillance-resistant. The identifier reveals nothing about the issuing authority. It is just bytes. An observer who sees an Agent-ID on the wire learns nothing about which registrar produced it, which jurisdiction it was registered in, or who owns it. All of that information lives in the Genesis, available only to parties the agent chooses to share it with.

These are properties the IAM industry has never needed for humans or workloads, and properties no major IAM vendor ships for agents.

What AGTP does that nobody else does

Okta has agent support that wraps an OAuth client into a service principal. Microsoft Entra has agent identity that surfaces in the Azure portal as a managed identity. Auth0 offers machine-to-machine grants that can be repurposed as agent credentials. Each one extends a primitive that was built for a different actor type. None of them ships the architecture agents actually need.

Six specific things AGTP does that no major IAM platform does:

Content-derived canonical identifiers. The Agent-ID is a hash of the Genesis. No vendor in the IAM space ships content-derived agent identifiers. Everyone assigns IDs from a directory.

Wire-level identity headers. Agent-ID, Owner-ID, and Authority-Scope are mandatory headers on every AGTP request. The protocol enforces verification before the application runs. No IAM vendor pushes identity into the transport. They keep it at the application layer where the directory can stay in charge.

Three separate principals. Agent-ID, Owner-ID, and acting principal serve as three distinct identifiers that answer three different questions: what acted, who is responsible, and who authorized. The IAM industry collapses these into a single identity record, destroying the accountability chain a regulator actually needs.

Signed Attribution-Records to transparency logs. Audit is a protocol output rather than an application convention. The records are structured the same way across every implementation and flow into logs whose integrity is cryptographically protected. The IAM industry’s audit story is per-vendor logging that requires bilateral integration to compose across organizations.

Trust tiers with explicit verification paths. Tier 1 means full cryptographic verification through DNS-anchored, log-anchored, or hybrid trust paths. The tier is verifiable by anyone with access to the public trust roots. The IAM industry has no equivalent. Verification depth is whatever the vendor says it is.

Federated, scope-enforced, signed discovery. ANS makes agents findable across organizations through a protocol-native discovery layer. Results are signed, ranked, scope-enforced, and federated while preserving provenance. The IAM industry’s discovery story is a vendor-controlled marketplace accessed through proprietary APIs, with no cross-vendor compatibility.

Protocol-composable identity. The Agent-ID, Owner-ID, and Authority-Scope ride alongside existing standards instead of replacing them. An AGTP identity passes straight through MCP, OAuth, and A2A without being re-minted at each boundary, so the same verifiable principal survives every hop of an agent's call chain. The IAM industry treats each protocol as its own island, issuing a fresh token and a fresh identity at every handoff, which severs the accountability chain at exactly the seams where cross-system attribution matters most.

Each of these is a deliberate architectural commitment that the IAM industry would have to rebuild its products to deliver. The retrofit approach (extend OAuth, extend service principals, extend the directory) cannot reach any of them, because the substrate is wrong.

The structural difference

The IAM industry treats identity as a directory problem. Their core competency is running directories, attaching policies to directory entries, and producing tokens that reference those entries. Everything they build assumes the directory is the source of truth.

AGTP treats identity as a protocol problem. The core competency is moving signed artifacts between agents in a way that allows each recipient to independently verify the artifacts. The protocol is the source of truth, and any directory built on top of it is an index to verifiable claims that exist outside the directory.

This is the same kind of structural difference that distinguished SMTP from proprietary mail systems in the early days of networking. The proprietary systems held mail in their own databases. SMTP carried mail as self-contained envelopes that any compliant server could read. The proprietary systems lost. The architecture that put the content on the wire won.

The same pattern will play out for agent identity. The IAM industry holds the records in its directories. AGTP carries the content as self-contained, content-addressed, signed artifacts. Vendors that adopt the AGTP substrate can continue to run directories as indexes into the verifiable substrate. Vendors that store their identities exclusively in proprietary directories are running the proprietary-mail-system playbook in a network where the protocol wins.

The substrate question gets answered the same way every time. The substrate that makes the content verifiable without the directory’s permission becomes the substrate. AGTP made that choice for agents. The rest of the industry is still answering with directories.

What this means for the field

Agent identity is being built right now. The choices being made today will compound over the next decade, much as the choice between SMTP and proprietary mail compounded over the eighties and nineties. Vendors building on directory primitives will produce systems that work inside their products and fragment at every boundary. Vendors building on canonical identifiers and protocol-level verification will produce systems that compose across operators, jurisdictions, and timescales.

The IAM industry is large, well-funded, and committed to the directory model. The directory model worked for humans. It worked for workloads. It will continue to work for those use cases. For agents, the directory is the wrong shape, and no amount of retrofitting changes that.

The Agent-ID must be canonical because the entity must outlive the directory. The Genesis, Manifest, Attribution Log, Trust Tier, Behavioral Score, and Lineage must all be first-class because agent identity is a richer artifact than user identity. The protocol must carry the verification because the application layer cannot do so consistently across organizations.

These are structural commitments. AGTP made them. The IAM industry will catch up or be replaced, just as every infrastructure layer does when a new substrate proves out.

Zero Trust Was Designed for Humans, not Agents

Chris Hood — Tue, 09 Jun 2026 18:05:01 +0000

In 2009, Google got breached. The attack, later called Operation Aurora, came in through a corporate VPN that until that moment had been the foundation of how enterprises kept attackers out. The breach killed an assumption that had organized network security for a generation: that the inside of the network was a trusted place. The outside was where threats lived. The job of security was to keep the wall strong.

Google's response was BeyondCorp. The principle was simple and structural. The network is hostile, including the inside of the network. Every request gets verified. Every user gets authenticated continuously. Every device gets attested. There is no implicit trust based on where the request came from. The wall went away, and the verification moved to every interaction.

This idea became zero trust. Forrester named it in 2010. Google productized it. NIST codified it in SP 800-207 in 2020. The White House mandated it for federal agencies in 2022. Every serious CISO has been deploying some version of it for the past five years. The model works. It is the right answer to the question it was asked.

The question it was asked is about humans and workloads. Agents are a different question.

This is the part of the agent infrastructure conversation that has been moving slowly. Zero trust has fifteen years of operational refinement, written into products, frameworks, and procurement requirements. The temptation is to assume that whatever zero trust was doing for users and services can extend without modification to the agents now running in production. The temptation is wrong, and the places where it breaks tell you what an agent-native zero-trust model has to provide.

AGTP is what that model looks like when somebody builds it.

What zero trust assumes

Strip zero trust down to its operating assumptions, and the human-and-workload shape becomes visible.

The model assumes the actor making a request has an identity provider that can vouch for it in real time. Humans have an IdP with SSO, MFA, and credential rotation. Workloads have SPIFFE, mTLS with certificates issued from a known CA, or short-lived credentials from a metadata service. In both cases, the verification step is "ask the identity provider whether this caller is still legitimate" and the IdP gives a current answer.

The model assumes least-privilege access can be enforced by scoping tokens to specific resources at the moment of access. Humans get OAuth scopes during an authorization flow. Workloads get policy-bound credentials with explicit resource grants. The scope lives in the token. The application enforces it.

The model assumes continuous verification through telemetry. Sessions get re-checked. Tokens get refreshed. Anomaly detection runs against the stream of accesses, and breach assumptions mean any session can be revoked at any time. The verification is continuous because the actor is continuously present.

The model assumes microsegmentation can be enforced at the network layer. Traffic between zones gets inspected. Identity at the segment boundary is verifiable through certificates the segment manager understands. Lateral movement is what zero trust was built to stop.

These assumptions work for the actor types zero trust was designed for. They start to bend when the actor is an agent.

Where the model bends

An agent has no identity provider in the traditional sense. The provider that "vouches" for the agent is the governance platform that signed its Genesis at activation, which is structurally different from an IdP that authenticates a session in real time. Agent identity is more like a passport (issued once, valid for the entity's lifetime, derived from a permanent record) than like a session token (issued continuously, valid briefly, tied to an active login). Asking "is this agent legitimate" looks more like asking "is this passport authentic" than like asking "is this user logged in." The verification mechanism has to change.

An agent has no MFA device. There is no second factor an agent can be challenged for, no phone to push a notification to, no hardware key to plug in. The factors of authentication for an agent are different: cryptographic proof of the Genesis, organizational binding to an owner, freshness of the manifest in the registry, currency of the certificate that binds Agent-ID to TLS. Multi-factor for agents means multi-source for verification, rather than multi-device for the user.

An agent has no session in the human sense. An agent might run for hours, pause overnight, resume in a different context, hand off to another agent halfway through a task. The "session" zero trust was designed around assumes a human at a keyboard. Agents need state and continuity primitives that work for runtime that crosses sessions and crosses organizations.

An agent crosses organizational boundaries by design. Zero trust microsegmentation assumes the segment boundary is inside an organization, with one operator running the policy on both sides. Agents at Company A delegating to agents at Company B requires policy enforcement at a boundary neither operator controls alone. The microsegmentation has to live at the protocol layer, because no single segment manager has visibility into both sides.

An agent has accountability that points at multiple parties. A human request has one principal: the user. An agent request has three: the agent that acted, the owner accountable for the agent, and the principal whose authority the agent was exercising. Zero trust frameworks have no native primitive for representing all three on the same request, so each system invents its own way to encode the extra parties, and the encodings fail to compose across organizations.

These bends are real. They are also addressable. The fix is to take the zero trust principles seriously and produce primitives that satisfy them for the actor type that triggered the bend.

What AGTP does for zero trust

AGTP applies the zero trust principles to agent traffic by making them protocol properties. Each principle maps to a specific AGTP construct.

Never trust, always verify. Every AGTP request carries Agent-ID, Owner-ID, and Authority-Scope as wire-level headers. Identity is cryptographically anchored in the Agent Genesis, a signed origin document whose 256-bit hash is the Agent-ID. The Genesis-issuer trust path is verifiable through one of three documented routes: DNS-anchored, log-anchored, or hybrid. Any receiver of an AGTP request can verify the agent's identity claim without trusting the network, the host, or the hosting domain. Verification is structural rather than negotiated per session.

Least privilege. Authority-Scope is a normative header that compliant servers MUST parse on every request, returning 455 Scope Violation for any method that exceeds the declared scope. The scope is expressed in domain:action form drawn from a reserved registry. Scope Enforcement Points enforce at line rate, before the application sees the request. Least privilege moves from an application-layer convention to a wire-level guarantee.

Assume breach. Every consequential AGTP interaction produces an Attribution-Record bound to the responding agent's identity, the request hash, and the response status. Records are signed and written to append-only transparency logs aligned with RFC 9162 and SCITT (RFC 9943). When a breach happens, the forensic substrate exists already. Incident response queries the log instead of reconstructing from per-framework application logs.

Verify explicitly, every request. AGTP carries verification material on every request rather than relying on session-based trust. Agent-ID is present. Owner-ID is present. Authority-Scope is present. The verifying server has everything it needs to make a fresh decision on every call, with no implicit trust carried forward from prior requests in the same connection.

Microsegmentation. Governance zones (zone:eu-gdpr, zone:us-healthcare, zone:retail-verified) are first-class. Agents are registered in zones. Requests carry AGTP-Zone-ID headers. SEPs enforce zone boundaries at line rate, returning 457 Zone Violation for cross-zone traffic that policy forbids. Microsegmentation works across organizational boundaries because the protocol carries the zone semantics and any AGTP-aware SEP can read them.

Continuous validation. Behavioral trust scores are computed from signed Attribution-Records and surfaced in ANS results. Discovery responses carry live behavioral data, so an agent's reputation reflects current behavior rather than the credentials it had at registration. Trust is dynamic at the protocol layer.

No location-based trust. Agent-ID is derived from the Genesis hash. It is invariant under hosting changes, domain rotations, and operator migrations. An agent moving between hosts keeps the same canonical identity. A spoofed agent at a familiar hostname produces a hash mismatch the verifier catches. Trust is bound to identity rather than to network location.

Identity-based access control. Authority-Scope tokens are bound to Agent-ID via certificate commitments in the AGTP-CERT extension. SEPs that read the certificate at session establishment can enforce scope at O(1) cost per request, because the commitment is parsed once and checked thereafter. Access decisions are tied to verified identity rather than to where the request appears to come from.

The pattern is the same one zero trust applied to humans and workloads, recompiled for the new actor type. Verification is wire-level. Scope is declared and enforced. Audit is structural. Boundaries are protocol-level. Trust is identity-bound and continuously evaluated. The principles stay intact. The primitives change to fit the actor.

Where AGTP goes further

There are places where the agent case demands more than zero trust traditionally delivers, and AGTP supplies the additional structure.

Cross-organization delegation has been the hardest unsolved problem in distributed trust. Zero trust handles trust inside an organization. AGTP handles trust across organizational boundaries through signed delegation chains, where each hop's scope is a strict subset of the previous hop's scope and chain breaks return 551 Authority Chain Broken. The protocol enforces a property no application layer can reliably enforce: the agent receiving a delegated request cannot use authority the delegating agent lacked.

Counterparty verification at commerce time goes beyond what zero trust typically addresses. AGTP's merchant identity layer verifies the receiving party of a purchase with the same rigor as the initiating party. The Merchant-Manifest-Fingerprint catches endpoint redirection by binding the manifest the agent verified to the manifest the server actually presents. Both sides of a commercial transaction get identified, and the dual-party Attribution-Record gives downstream systems a complete artifact.

Portable evidence across protocols closes a gap zero trust has historically struggled with. The Intent-Assertion JWT is a signed proof of principal-authorized intent that non-AGTP systems can consume directly. Card networks, payment processors, regulators, and dispute resolvers verify the JWT signature against a published key without needing to speak AGTP. This is the bridge between AGTP-native infrastructure and the institutional fabric that already exists.

Reputation as a verifiable property closes another gap. Zero trust says "verify the caller." AGTP says "verify the caller and also surface what the caller has done across the network." Behavioral trust scores in ANS results give downstream decisions a richer input than identity alone. Selecting an agent for a delegation becomes selecting an agent for accountability, with the track record visible at the moment of selection.

These are extensions of zero trust rather than departures from it. Zero trust got the principles right. AGTP applies the principles to a new category of actor and supplies the primitives the principles need to operate.

The model the moment needs

There is a practical observation worth ending on. The agent economy is going to be deployed inside organizations that have spent the past decade adopting zero trust. The procurement requirements are written. The security frameworks are mapped. The compliance language is settled. Anything new has to compose with this work rather than replace it.

AGTP composes. The zero trust principles are preserved. The verification model gets stronger. The audit substrate gets cleaner. The microsegmentation extends to organizational boundaries that zero trust historically failed to cross. The result is a security posture compatible with what enterprises have already built and capable of what enterprises now need.

The CISO deploying AGTP is extending an existing investment rather than abandoning one. Zero trust said never trust, always verify. AGTP says: for agents, here is what verification actually looks like at the wire. The agent's Genesis is signed. The scope is declared. The attribution is recorded. The zone is enforced. The trust score is live. The certificate binds the identity to the transport. Every interaction is verifiable. No session-based shortcuts. No location-based assumptions. Every request stands on its own.

Zero trust was designed for humans and workloads. It worked for what it was designed for. The agent economy needs the same discipline applied to a new actor type, and AGTP is what that application looks like. The principles stay. The primitives evolve. The wall went away again, and the verification moved to every interaction.

The model the moment needs is zero trust extended to agents. The protocol the model needs is one that carries the extension natively.

That protocol exists.

Maybe the G in AGTP Stands for Governance

Chris Hood — Mon, 08 Jun 2026 17:41:41 +0000

A protocol's name shapes how people read the technology. SMTP carried "Simple Mail Transfer Protocol" in its title, and for forty years people described it as a way to move email between machines. The simpler reading was accurate, and it was incomplete. SMTP also carried an envelope-and-header model that became the foundation of every spam filter, every authentication system, every legal hold, every regulatory archive. The naming highlighted the transport. The substance turned out to be the governance.

AGTP is the Agent Transfer Protocol. The simpler reading is accurate. The substance, the thing the protocol actually does that no other agent protocol does, is governance. We have been calling it a transfer protocol because that is what its acronym says. The honest description might be different.

Maybe the G in AGTP stands for Governance.

This is more than a marketing argument. Every design decision in AGTP was made through a governance lens. The identity primitives, the authority headers, the attribution records, the discovery semantics, the trust tiers, the merchant model, the delegation chains, the intent assertions: each one solves a problem the AI governance community has been writing policy about for the past three years. Take the governance lens away, and many of these decisions would have produced different designs. With the lens in place, every layer of the protocol carries some piece of what regulators, compliance officers, auditors, and risk teams have been demanding.

This article is the second reading of AGTP. The same specs, with a different question on top: what would the protocol look like if you read it as a governance proposal rather than a transport one?

It would look almost exactly like the one in front of us.

The pattern across the layers

Walk through the primitives, and the pattern becomes hard to miss.

Agent Genesis is an origin record signed by the governance platform that activated the agent. The signature establishes accountability at the moment of birth. There is no agent without a Genesis. There is no Genesis without a signing authority. Identity, accountability, and authorization to operate are bound together at activation and travel as a single artifact for the agent's lifetime. This is governance written into the moment of creation, before any traffic ever moves.

Agent-ID, Owner-ID, and acting_principal_id are three different identifiers carried on the same request. They answer three different governance questions. Who acted. Who is responsible. Who authorized. Most agent infrastructure today collapses these into one identifier and lets the platform figure out the rest. AGTP keeps them separate by design, because regulators ask each question separately and the answers belong in different places.

Authority-Scope is a normative header. Servers MUST parse it. SEPs MUST enforce it at line rate. Violations return 455 Scope Violation with a structured reason. The wire participates in policy enforcement, which means the application above the wire cannot accidentally allow what the protocol forbids. This is the kind of guardrail compliance teams have been asking for and that application-layer enforcement keeps failing to deliver.

Attribution-Records are signed envelopes that bind the responding agent's identity, the request hash, the response status, and the acting principal claim into a single artifact. They are written to append-only transparency logs aligned with RFC 9162 and SCITT (RFC 9943). The logs are structured the same way across every implementation. A regulator asking "what did this agent do" gets a tractable query. A counterparty in a dispute gets a verifiable record. An incident responder gets a forensic substrate. This is what regulatory audit demands have always wanted: an artifact that the system produced as a side effect of normal operation, with cryptographic integrity, in a format any downstream system can read.

Governance zones are first-class. zone:eu-gdpr, zone:us-healthcare, zone:retail-verified. Agents are registered in zones. Requests carry zone IDs. SEPs enforce zone boundaries. Cross-zone traffic that policy permits passes through. Cross-zone traffic that policy forbids returns 457 Zone Violation. Jurisdictional separation, which has historically been a paper concern in cross-border deployments, becomes a packet-level property.

Trust tiers quantify what verification stands behind an agent. Tier 1 means full cryptographic verification through one of three documented paths (DNS-anchored, log-anchored, or hybrid). Tier 2 means organizational assertion, useful inside an organization's perimeter and flagged with a warning on the wire. Tier 3 means experimental, confined to development environments. The tiers travel with the agent's manifest. Discovery surfaces them in result rankings. Counterparties verify them before transacting. Credentialing becomes a verifiable property of identity rather than a self-asserted claim.

Merchant identity mirrors agent identity for the receiving side of commercial transactions. Merchant Genesis. Merchant-ID. Merchant Manifest. Counterparty verification at PURCHASE. Dual-party Attribution-Records that name both sides. The shape every payment network has demanded for agent-initiated commerce, supplied by the protocol.

Delegation chains maintain provenance across organizational boundaries. Each hop is signed. Each hop's scope must be a subset of the previous hop's scope. Chain breaks return 551 Authority Chain Broken. The protocol enforces that an agent cannot delegate authority it lacked, regardless of how the application code above it handled the request. Cross-organization accountability, which has been the hardest problem in distributed agent systems, becomes a protocol property.

Intent-Assertion is a detached signed JWT carrying principal-authorized purchase intent in a format that non-AGTP counterparties can consume. Card networks, PSPs, acquirers, and regulators can verify the JWT against a published key without speaking AGTP. The pattern works the way notarized signatures work in physical commerce: portable evidence of authorization that any institution accepting notarization recognizes.

PROPOSE and RCNS put runtime contract negotiation behind a governance gate. A proposal carries an intent, parameters, and a declared scope. The server's evaluation is a policy decision, returning 263 Proposal Approved, 463 Proposal Rejected with structured reason, 261 Negotiation In Progress, or 462 Authorization Required. The contract that comes into existence at the moment of need is a contract the governance layer participated in shaping.

DISCOVER and ANS make discovery scope-enforced. Agents querying the directory need discovery:query authority. ANS responses are signed by default. Results carry trust tiers and behavioral scores. The discovery layer participates in policy enforcement instead of leaking metadata to anyone who asks.

This is the pattern. Every layer of AGTP carries a governance primitive. The accumulation is the design.

Designed with governance in mind

The accumulation is hard to read as accidental. Designing an agent protocol without governance in mind produces different outputs. You get one identifier instead of three. You get scope as a token in a payload instead of a normative header. You get audit as an application-layer log instead of signed records in transparency logs. You get discovery as a vendor API instead of a scope-enforced governed registry. You get delegation as bilateral integration instead of signed chain headers with line-rate enforcement. None of these alternatives are wrong for the transport problem they solve. They are wrong for the governance problem the agent economy is about to face.

The current moment in AI governance has a specific shape. The EU AI Act requires structural logging of high-risk system operations under Article 12. The NIST AI Risk Management Framework requires verifiable measurement of system behavior. ISO/IEC 42001 requires attributable evidence for AI management systems. The OECD AI Principles converge on transparency, accountability, and auditability. Singapore's Model AI Governance Framework, Canada's AIDA, the UK's pro-innovation regulatory approach: each one converges on the same primitives. Identity. Authority. Audit. Boundaries.

These are the primitives AGTP carries. The convergence is structural rather than coincidental. The protocol was designed in conversation with the governance work that has been accelerating in the same period, and the design decisions reflect the demands those frameworks generate. Reading AGTP without the governance lens misses what most of the design choices are actually for.

Why governance has to be structural

Governance that lives above the protocol is governance that depends on every application implementing it correctly. Every framework reinvents the enforcement surface. Every vendor logs in a different format. Every cross-organization interaction requires bilateral integration to align the policies. The policy is clear. The infrastructure underneath it is a thousand incompatible dialects.

This is the failure mode that produces compliance reports written from incomplete logs, regulatory investigations that take quarters to complete, and disputes that turn on what each side's framework happened to capture. The application layer is the wrong place to enforce things that need to be verifiable across organizations, jurisdictions, and time.

Protocols that bake their structural promises into the wire escape this problem. TLS made encryption a property of the connection instead of a property of every application. Certificate Transparency made trust auditing a property of the system instead of a property of each operator. SMTP made the envelope-and-header structure a property of mail instead of a property of each mail server. In every case, the protocol decided what was guaranteed, and the layer above the protocol stopped having to remember.

AGTP does this for agent governance. The identity is a property of every request. The authority scope is a property of every request. The attribution is a property of every consequential interaction. The zone boundaries are a property of the enforcement layer. The trust tier is a property of the manifest. The applications above the protocol get to stop worrying about whether they remembered to enforce, because the protocol enforced before the application ever ran.

This is the inversion that makes governance tractable at scale. The hardest governance problem in distributed systems is making sure every component does its part consistently. The solution is to take the consistency out of the components and put it in the substrate everyone has to use.

The naming question

Naming matters because naming directs attention. A protocol named "Agent Transfer Protocol" gets read as transport infrastructure. The first questions readers ask are about latency, throughput, encoding efficiency, interop with HTTP. These are real questions, and AGTP has real answers to them.

A protocol named "Agent Governance Transfer Protocol" would get read differently. The first questions would be about identity, accountability, audit, jurisdiction, dispute resolution, regulatory mapping. These are also real questions, and AGTP has real answers to them too. The reading order would change. The audience would change. The framing would change.

The current name was a choice. The proposed alternate name would also be a choice. Both are accurate. The question is which reading the protocol's actual function rewards more.

The governance reading rewards more. The transport problem AGTP solves is real, and the solution is good, but transport problems for agents are solvable in other ways. People have built agent infrastructure on HTTP, on gRPC, on WebSockets, on raw TCP. None of those are great choices, and AGTP is a better choice, but the difference is incremental. The governance problem AGTP solves is the one most other proposals avoid, and the avoidance is producing the failure modes regulators are starting to write rules about.

What makes AGTP unusual in the agent infrastructure landscape is the governance layer. The transport is good. The governance is what makes the transport worth standardizing.

The protocol the moment needs

A practical observation about timing. The next few years of the agent economy are going to be governance-shaped years. The EU AI Act is in implementation. NIST is refining the AI RMF. ISO 42001 is being adopted. State and national frameworks are multiplying. Insurance markets are pricing agent risk. Payment networks are building protection programs. Courts are starting to see agent-mediated disputes.

The infrastructure that survives this period will be the infrastructure that handles governance natively. Application-layer governance will keep failing audits, missing logging requirements, and producing forensic gaps. Protocol-layer governance will produce the audit artifacts, scope enforcement, and attribution chains that frameworks are demanding. The cost difference between these two approaches will become structural over the next decade, and the agent infrastructure that comes out the other side will be the protocol-layer kind.

AGTP is the protocol-layer answer. The transport reading describes what the protocol does on the wire. The governance reading describes what the protocol is for.

Both readings are correct. The second one is the one that matters for the next decade.

Maybe the G in AGTP stands for Governance. Or maybe both readings stay accurate and we keep calling it the Agent Transfer Protocol while quietly understanding that the transport was always in service of something else. The naming is a smaller question than the function. The function was governance from the beginning.

The protocol works the way it works because somebody designed it that way. That somebody had a governance lens on every design call, and the protocol carries that lens forward into every deployment that adopts it. Read AGTP as a transport protocol and you see a clean, agent-native substitute for HTTP. Read it as a governance protocol and you see what the AI governance community has been asking for, delivered as infrastructure that the agent economy can actually build on.

Either reading is fine. The second one is more honest.

Both Sides of the Agent Transaction

Chris Hood — Sun, 07 Jun 2026 19:49:50 +0000

When you swipe a credit card at a coffee shop, the payment network verifies two identities rather than one. Your card identifies you. The merchant's terminal identifies the coffee shop: a merchant ID, a merchant category code, a registered legal entity, a jurisdiction where disputes get resolved, a network agreement years old and fingerprinted to that specific business. The transaction completes because both parties have identity that the network recognizes. When something goes wrong, the network knows who it is talking to on both ends.

Card networks spent decades building this. They had to. A payment system where one side is identified and the other side is whatever showed up at the endpoint produces fraud at scale, and the fraud is hard to investigate because half the transaction is anonymous.

Now consider what happens today when an AI agent makes a purchase on someone's behalf. The agent has identity. Agent-ID, Owner-ID, Authority-Scope, signed Genesis, all carried on every request. The merchant has whatever was at the URL. No protocol-level identity. No structural verification that the merchant is who it claims to be, that the merchant is current with its registration, that the merchant has a dispute policy, that the merchant is in good standing in its jurisdiction.

Half the transaction has identity. The other half is whoever answered the connection.

This is the gap AGTP's merchant identity layer closes. It does for the receiving side of an agent purchase what Agent Genesis does for the initiating side. And it pairs with two operational primitives, Budget-Limit and Intent-Assertion, that together make agent-driven commerce something that compliance teams, payment networks, and merchants themselves can actually rely on.

What "merchant identity" means in AGTP

A merchant in AGTP is a legal entity, registered through a governance platform, identified by a canonical Merchant-ID derived from a signed Merchant Genesis document.

The Merchant Genesis carries the fields a payment network and a regulator would expect to see: legal entity name, organization domain, merchant category code following ISO 18245, registered jurisdiction, accepted payment networks, dispute policy URI, refund policy URI, trust tier, governance zone, and the verification path that backed the merchant's registration. The Genesis is signed at issuance, hashed to produce the Merchant-ID, and permanently bound to the merchant.

The structural parallel with Agent Genesis is deliberate. A governance platform that registers agents registers merchants through the same registry and the same cryptographic machinery. The Merchant Manifest Document, derived from the Genesis, is the merchant-side analogue of the Agent Manifest Document. Both carry signed identity claims. Both carry trust tier. Both carry governance zone. Both can be resolved through discovery and verified at the moment of use.

A merchant's canonical URI looks like agtp://acme.tld/merchant/acme-commerce. The domain anchors the merchant to a registered organization. The labeled suffix lets a single organization run multiple merchant identities, which matters for multi-brand retailers and conglomerates. Every URI form resolves back to the same canonical Merchant-ID.

This is the substrate that has been missing from agent commerce. A merchant is more than the endpoint that answers a PURCHASE call. The merchant is the legal entity that stands behind the transaction, with verifiable identity, declared policies, and a registration record that can be audited.

Verification at PURCHASE

The PURCHASE method invokes the merchant identity machinery. An agent holding payments:purchase in its Authority-Scope MUST perform counterparty verification before sending the request.

Verification is five steps. Resolve the merchant URI. Verify the manifest's signature against the governance platform's published key. Verify the merchant's lifecycle state is Active. Verify the merchant's trust tier meets the threshold the agent's policy requires for the transaction amount. Compute the SHA-256 hash of the canonical manifest bytes and carry that fingerprint in the Merchant-Manifest-Fingerprint request header.

Any step failing means the PURCHASE never sends. The agent's runtime surfaces the failure to the principal or the governance platform. There is no silent fallback to an unverified transaction.

The receiving merchant server has its own verification responsibility. It checks that the Merchant-ID header in the inbound request matches its canonical ID. It checks that the manifest fingerprint matches its current Merchant Manifest. Any mismatch returns 458 Counterparty Unverified. The fingerprint check is the part worth dwelling on: an attacker who redirects the requesting agent to a different endpoint than the one it verified gets caught at the fingerprint comparison. The manifest the agent verified has to be the manifest the server actually presents. The two are bound by hash.

This is the protocol-level mechanism that closes the spoofed-merchant attack. The agent never has to trust DNS, never has to trust hosting infrastructure, never has to trust that the URL it resolved still points where it pointed five seconds ago. The fingerprint check is the cryptographic guarantee that the entity answering is the entity that was verified.

Budget-Limit, enforced at the wire

The other half of trustworthy agent commerce is operational containment. An agent that has been authorized to make purchases up to a ceiling must actually stop at the ceiling, including when the application logic above it has a bug.

AGTP carries this as a header. Budget-Limit: USD=850.00. The format is currency code, equals sign, decimal amount. The header travels with the PURCHASE request. The merchant server is required to enforce it. A cart total that exceeds the declared budget gets rejected before the transaction completes. Scope Enforcement Points in the path can enforce it at line rate, before the request ever reaches the merchant's application.

The relationship to Authority-Scope is worth being explicit about. Authority-Scope describes the agent's overall commerce authority: payments:purchase, payments:up-to-2500usd. This is what the agent is broadly permitted to do, across all transactions in its session. Budget-Limit describes the cap on a specific transaction: this PURCHASE has $850 to spend. Authority-Scope is the credit limit on the card. Budget-Limit is the size of the dinner you authorized tonight.

Both are enforced at the protocol layer. An agent whose Authority-Scope allows up to $2,500 cannot use that allowance to make a single $5,000 purchase. A specific PURCHASE with Budget-Limit set to $850 cannot complete at $850.01. Application bugs above the protocol layer cannot cause over-budget transactions, because the protocol catches them first.

This is the operational guardrail compliance teams have been asking for and that application-layer enforcement keeps failing to deliver. Wire-level budget enforcement means the bug in the application loop, the prompt-injection in the user's instructions, and the unexpected price surge at the merchant all hit the same wall: the protocol refuses to complete the transaction.

Intent-Assertion: portable evidence

There is a problem AGTP has to solve that pure protocol identity cannot solve alone. Payment networks already exist. Visa, Mastercard, ACH, PIX, FedNow, every regional rail. These networks are decades old, they handle trillions of dollars a year, and they are never going to ingest AGTP traffic directly. An agent making a card-network purchase has to produce evidence the card network can consume.

The Intent-Assertion header is that bridge. It carries a detached signed JWT containing the principal's authorization for this specific purchase: the principal's identity, the cart digest, the budget cap, the intent timestamp, the merchant the purchase is targeted at. The JWT is signed by the principal's key (or by the governance platform on the principal's behalf, depending on the deployment pattern), and it is portable. Card networks can consume it. PSPs can consume it. Acquirers can consume it. None of them needs to speak AGTP. They just need to recognize the JWT signature against the principal's published key.

This is the same pattern notarized documents follow in the physical world. A notarized signature is portable evidence of authorization that any institution accepting notarization can consume. The notary has no requirement to be inside every institution's workflow. The signature stands on its own.

The Intent-Assertion lets agent-initiated transactions ride existing payment rails with verifiable evidence of authorization on both sides. The card network gets the proof it needs (the agent was authorized by this principal, for this amount, with this merchant, at this time) without having to integrate with AGTP infrastructure.

MNS: the Merchant Name Service

Discovery on the merchant side mirrors discovery on the agent side. The Merchant Name Service is the merchant analogue of ANS. An AGTP-aware server that indexes Merchant Manifest Documents and answers DISCOVER queries with ranked, signed result sets.

An agent looking for a merchant of a specific type, in a specific jurisdiction, accepting specific payment networks, with a trust tier above some threshold, queries the MNS the same way it queries the ANS. The results come back signed, ranked by trust tier and behavioral score and capability match, with the same federation and scope-enforcement properties.

MNS can be co-located with ANS or operated separately. Some operators will run a unified discovery layer. Some will specialize in merchant directories. The protocol stays agnostic. What matters is that the merchant side has a discovery infrastructure that an agent can use without bilateral integration with every potential counterparty.

This is the part that turns AGTP commerce from a bilateral pattern into an open marketplace. Agents can find merchants by capability. Merchants can be discovered without prior introduction. The transaction surface that has been waiting for a protocol-level discovery layer gets one.

Dual-party attribution

Every successful PURCHASE produces an Attribution-Record that names both counterparties cryptographically.

The record carries the agent's Agent-ID, the principal's Principal-ID, the merchant's Merchant-ID, the merchant manifest fingerprint, the JTI of the intent assertion, the method, the timestamp, and a signature from the merchant. The dispute investigator pulling this record three years later has cryptographic evidence of who acted, who authorized, who the counterparty was, what specific manifest version was verified, and what specific intent was asserted.

This is the audit artifact that payment networks have been waiting for. A signed record naming both parties to an agent-initiated transaction, consumable by their dispute resolution processes without requiring those processes to speak AGTP. The record stands on its own.

For the merchant, the record is proof that they delivered against a verified, authorized intent. For the agent's principal, the record is proof that the merchant was who they claimed to be at the moment of purchase. For the regulator, the record is the substrate that makes investigation tractable.

What this changes

For agents, commerce becomes verifiable. An agent making a purchase has cryptographic certainty about the counterparty, enforced budget limits at the wire, and portable evidence of intent that downstream systems will accept.

For merchants, agent commerce becomes a first-class surface. They register their Merchant Genesis once, appear in MNS discovery, get verified at PURCHASE, and receive transactions that come with verifiable agent identity. The fraud and dispute exposure that has kept merchants cautious about agent-initiated traffic drops, because every transaction names both sides.

For payment networks, the agent-initiated transaction class becomes underwriteable. Both counterparties have verifiable identity. The intent is signed. The budget is enforced. The dispute artifact names both sides. This is the missing piece that has been blocking payment networks from extending their protection programs to agent-initiated traffic. AGTP produces the inputs. The networks consume them through their existing flows.

For regulators, agent commerce becomes legible. The Attribution-Records compose into queryable history with both counterparties named. EU AI Act Article 12 logging requirements get answered with structural cryptographic records rather than per-platform reconstructions.

The whole transaction, both ends

This is the discipline shift the agent economy has been moving toward without quite naming. Half-identified transactions cannot scale into a regulated commerce surface. Card networks figured this out decades ago by requiring identity on both ends, and the agent economy has been quietly relying on infrastructure that only does it on one.

AGTP closes the loop. Merchants get identity that mirrors agent identity. Budget caps get enforced at the wire instead of in application code that bugs can defeat. Intent assertions become portable evidence to non-AGTP rails. Discovery surfaces merchants the same way it surfaces agents. The Attribution-Record names both sides.

Commerce is a two-sided activity. The protocol has to recognize both sides. AGTP does, and the things that have been hard to build on top (verifiable agent-driven purchases, open marketplaces, audited cross-jurisdictional commerce, payment-network protections for agent-initiated traffic) become tractable when identity, intent, and budget are protocol primitives rather than application conventions.

Both sides of the transaction. Identified, verified, attributed, budgeted, enforced. This is what agent commerce needs to grow up into the economy it is on track to become.

Agent Name System (ANS): The DNS Moment for Agents

Chris Hood — Sat, 06 Jun 2026 17:39:08 +0000

In 1983, every computer on the internet kept a file called HOSTS.TXT. The file was maintained by Elizabeth Feinler’s team at SRI in Menlo Park. It listed every host on the network with its IP address. When a new host came online, somebody emailed Elizabeth. She added the entry. She redistributed the file. Every system administrator on the early internet downloaded the latest copy and dropped it into place.

This worked. For a while.

By 1983, the network had outgrown one researcher’s ability to maintain a master file by hand. Hosts were being added faster than they could be distributed. The file was always out of date somewhere. A new RFC was needed, and Paul Mockapetris wrote it. RFC 882 and RFC 883 defined the Domain Name System. A hierarchical, federated, cached, distributed name service that let the internet grow from a few thousand hosts to several billion without anyone maintaining a single master list of anything.

DNS is the unsung infrastructure of the internet. It runs roughly a trillion queries a day. It works so well that most users have never heard of it. The web, email, video conferencing, mobile applications, and almost every internet-dependent service rely on DNS resolving a name to an address fast enough that you never notice the lookup happened.

The agent internet is at HOSTS.TXT at the moment. And it has been waiting for its Mockapetris.

How agents find each other today

Walk through what happens today when an agent at Company A needs to interact with an agent at Company B.

The most common pattern is hardcoding. Company A’s agent has a URI baked into a config file. The URI points at Company B’s specific endpoint. Someone wrote it down. Someone deployed it. When Company B changes hosts, somebody updates the config and redeploys. If Company B is unreachable, Company A’s agent has no fallback. If a new and better counterparty appears at Company C, Company A has no way to find it without somebody manually adding the URI.

The slightly more sophisticated pattern is the marketplace API. A vendor publishes a directory of agents. Other agents query the directory via the vendor’s specific API, receive results in the vendor’s specific format, and call the agents the vendor has decided to surface. Every vendor has its own marketplace. None of them are interoperable. If you want to be discoverable in three marketplaces, you register three times. If you want to find candidates across three marketplaces, you implement three different SDKs. The shape of the problem repeats per-vendor.

The least sophisticated pattern is the Slack channel. Engineers at Company A learn about an agent at Company B from a tweet, a conference talk, or a colleague’s recommendation. They write down the URI. They paste it into config. The agent economy runs partly on word of mouth.

All three patterns are variants of HOSTS.TXT. A central authority (the engineer, the vendor, the colleague) maintains a list. Distribution is manual. Updates are slow. Discovery requires somebody outside the system to do the introduction. The pattern works at small scale. It fails at any scale that resembles a real economy.

ANS solves this the same way DNS did. By moving discovery from a central manual process into a federated automated protocol.

What ANS is

The Agent Name System, ANS, is the AGTP equivalent of DNS. An open IETF draft for a federated, governed, queryable directory of agents that returns signed results to authorized callers.

The architecture is straightforward. An ANS server is itself an AGTP server. It has its own Agent-ID, derived from its Genesis, and is registered in the AGTP registry like any other agent. It speaks AGTP on port 4480. A querying agent issues a DISCOVER request describing the capabilities it needs, the trust posture it requires, and the scope under which it is making the request. The ANS server returns a signed result set: a ranked list of agents that match the query, each entry carrying the candidate’s canonical Agent-ID, manifest URI, trust tier, behavioral trust score, capability match score, and the authority scope a caller will need to invoke the candidate.

The querying agent verifies the ANS server’s signature on the response. It picks a candidate. It connects directly to the candidate using the canonical Agent-ID. The ANS server has done its job. Discovery is finished. The agents take it from there.

This is a small system to describe and a large one to live inside. The ability to find an agent by capability rather than by hostname is what turns a collection of bilateral integrations into a discoverable economy.

How ANS goes beyond DNS

DNS solved a name-to-address problem. ANS solves a capability-to-agent problem, which is a different question, and the answer is structurally richer than what DNS provides.

DNS resolves a name to a small set of records. The records are typed (A, AAAA, MX, TXT, CNAME). The data is mostly static, updated when the operator changes infrastructure. DNS responses are anonymous: the resolver returns whatever its data says, regardless of who asks. DNSSEC adds signatures when operators enable it, which most still avoid.

ANS responses are signed by default. The signing is part of the protocol rather than an optional extension. Any caller can verify that a result set actually came from the ANS server that claims to have produced it, and any caller can detect tampering between the ANS server and the requesting agent.

ANS responses are ranked. A capability query returns multiple candidates ordered by a documented scoring function that combines trust tier, behavioral trust score, and capability match score. The querying agent explicitly sees the ranking. The ANS operator’s ranking algorithm is part of its publicly documented policy. The ranking is open to scrutiny, which means an ANS that ranked agents in self-serving ways would quickly lose credibility.

ANS responses carry live behavioral data. A behavioral trust score is the agent’s track record across the transparency log, computed continuously from signed Attribution-Records. An agent that has handled a thousand transactions cleanly carries a different score from one that just registered. DNS knows nothing about how a host has behaved historically. ANS knows because the behavior is on the wire and signed.

ANS is scope-enforced. The DISCOVER request carries the requesting agent’s Authority-Scope. ANS servers check that the requester has discovery:query scope before returning any results. Some agents may be invisible to queries that lack additional scope tokens. An agent registered in a healthcare zone might appear only in response to queries from agents that also hold a healthcare scope. The discovery layer participates in policy enforcement instead of leaking all metadata to anyone who asks.

ANS responses preserve provenance through federation. When ANS server A federates with ANS server B, a query against A that touches B’s index returns results that carry both signatures and the federation chain. The requesting agent can verify that a particular candidate came from a particular ANS operator, even when the query crossed organizational boundaries. DNS federation works through delegation. ANS federation works through composition.

The last difference is the most important one. ANS is itself an AGTP server, queryable via the same protocol the agents use. There is no separate query language, no separate transport, no separate authentication model. The discovery layer is the same substrate as the agent layer. Operating an ANS is the same as operating an AGTP server with discovery semantics. Querying an ANS is making an AGTP request. The protocol stays the same all the way down.

What this unlocks

Once agents can be discovered by capability across organizational boundaries, several things that have been hard become routine.

Cross-organization commerce. An agent at one company can find an agent at another company with no prior relationship, verify identity and trust posture from the signed ANS response, and proceed to delegation. The bilateral integration that used to require a contract and a quarter of engineering work collapses into a DISCOVER request and a verification step.

Open marketplaces. A marketplace operator runs an ANS with commerce-relevant ranking and a payment integration. Any agent that registers can be discovered. Any agent that meets the operator’s policy thresholds can be ranked. The marketplace stops being a vendor silo and becomes a federation participant. Multiple marketplaces can coexist, the way multiple search engines coexisted in the early web, with agents indexed across all of them remaining interoperable because the underlying identity format is shared.

Capability-based addressing. A querying agent that needs a Solidity auditor has no requirement to know whether a Solidity auditor exists in its own organization, in a partner organization, or in a stranger organization three federation hops away. It asks for a Solidity auditor with the right trust tier. ANS finds one. The agent invokes. The geography becomes invisible to the application logic, much like how DNS made geography invisible to web browsers.

Live infrastructure. Agents come and go. Capacity scales up and down. Versions deprecate. ANS servers monitor indexed agents for availability and remove revoked agents within sixty seconds. A query today returns currently available agents, rather than agents that exist somewhere in a frozen registry from last quarter. DNS approaches this through TTLs. ANS gets there structurally because revocation propagates as a first-class signal.

Trust at the discovery layer. Selecting an agent by capability is selecting an agent for accountability. The behavioral trust score in the ANS response is a verifiable summary of the agent’s track record. A counterparty asking “should I delegate to this agent” has the answer in front of them before the delegation happens, rather than discovering it after something has gone wrong.

What ANS needs from operators

ANS is open infrastructure, and the right model for who runs it parallels the model for who runs DNS. Multiple operators run ANS servers. Some operators are public, indexing agents from any registered organization. Some operators are private, indexing agents inside an organization’s perimeter for internal discovery. Some operators are sector-specific, indexing only agents accredited in their domain (healthcare, finance, logistics). All of them speak the same AGTP-defined discovery protocol, sign their responses with their own governance keys, and federate with peer operators under documented policies.

The economic model is also recognizable. Some ANS operators will run as public utilities, as the DNS root operators do. Some will run as commercial services offering enhanced ranking, analytics, or sector-specific curation. Some will run as cooperative federations governed by member organizations. The protocol stays agnostic about which model wins. It enables several.

What every ANS operator commits to is the same: signed responses, documented ranking, scope enforcement, sixty-second revocation propagation, and federation under explicit terms. The operator gives the network something it cannot get any other way: a queryable, verifiable, current view of the agent economy.

Where this goes

The first ANS implementation is online, indexing the small but growing set of registered AGTP agents. Lauren resolves through it. Cross-organization queries work today against a handful of federated peers. The protocol semantics are stable enough to write against, with the discovery companion draft moving through the standards process.

The roadmap is mostly about scale and federation. Multi-region clusters with consistency models tuned for low-latency reads. Federation policies that let operators express selective trust (“federate with these peers for healthcare queries, those peers for finance queries”). Behavioral score computation pipelines that can keep up with the transparency log as it grows. Sector-specific curation patterns. Anti-abuse measures for enumeration and scraping. The work that every name service has had to do, applied to a system that knows from the start what kind of network it is operating in.

The infrastructure most of us will never notice

DNS resolves a trillion queries a day, and most people have no idea it exists. That is what good infrastructure looks like. It moves out of the way once it works, and the things that depend on it no longer have to think about how they get found.

ANS is the same kind of infrastructure for the agent economy. It will resolve queries that turn into delegations, marketplaces, and commerce across organizational lines. Most agents using it will never think about ANS, just as most websites never think about DNS. The lookup will be fast, the result will be signed, the agents on the other side will be there.

This is the DNS moment. The HOSTS.TXT era of the agent internet is ending. Whoever runs the name servers gets to participate in defining how the next era works.

Introducing Elemen: The World's First Browser for the Agent Web

Chris Hood — Fri, 05 Jun 2026 17:24:06 +0000

When Tim Berners-Lee invented the web, he also had to invent the browser. The protocol moved bytes between machines. The browser made those bytes mean something to people.

This is the part of internet history that gets understated. HTTP and HTML by themselves were a system for machines to exchange documents. They were technically sufficient, in the sense that any program could fetch any document from any server. They were socially insufficient, because no human could look at the protocol traffic and understand what was happening. Mosaic, then Netscape, then the long line of browsers that followed gave humans a way to participate in something that was fundamentally a machine-to-machine exchange. The web mattered to people because the browser made it visible to people.

The agent internet has the same structural property and has been missing the same layer. Until now.

Today we are introducing Elemen, the first agent browser for the Agent Transfer Protocol (AGTP). Elemen is the layer that lets a human visit an agent the way you visit a website: by typing in a URI and seeing the agent rendered as something a person can read, evaluate, and trust.

Agents themselves have little use for a browser. They speak AGTP natively, exchange JSON-formatted Agent Documents over port 4480, and reason against each other's manifests without any rendering step. The machine-to-machine layer was the first thing AGTP got right. What was missing was the human layer.

The web parallel, made literal

The web's success rests on three layers rather than one. The protocol layer (HTTP) moves the bytes. The document layer (HTML) structures the content. The presentation layer (the browser) renders the content for the reader who actually has to make sense of it. If any of these three is missing, the web stops being something humans can use.

AGTP has had two of the three layers since day one. The protocol moves Agent Documents over port 4480. The document layer is the eleven-field identity schema, the manifest format, and the canonical serialization rules that let any agent or server parse any other's identity. What has been absent is the third layer. The presentation layer. The thing that takes an Agent Document and turns it into something a person can read in fifteen seconds and walk away knowing who they were looking at.

Elemen is the presentation layer.

Type agtp://d8dc6f0df55d66c7b30100db3cffbe383c5f814e6e58a08521fb7636c3bcc230 into Elemen, and you see Lauren. The first registered AGTP agent. Her name. Her principal, Chris Hood. Her description. Her status. Her capabilities. Her accepted scopes. The cryptographic origin of her identity. Issuer, issuance date, integrity hash. Everything a person needs to decide whether they want to interact with Lauren, served as a clean visual rendering of the same Agent Document that other agents have been reading machine-to-machine since the protocol came online.

Lauren has had an identity since the day she was registered. Elemen is the first place a human can go and meet her.

Six URI forms, six different things

AGTP defines six URI forms, and each one addresses a fundamentally different kind of entity in the agent internet. Elemen renders each form differently, because the entity type changes what is useful to show.

Form 1 is the canonical identity URI: agtp://{agent-id}. The 256-bit hash of an Agent Genesis document, resolved through the registry to wherever the agent currently lives. Form 1a (agtp://{agent-id}@{host}) bypasses the registry and goes straight to a host. Both forms address an agent.

Form 2 addresses a server: agtp://{host}. This is the entity that hosts other agents, exposes methods, bridges protocols, and runs the infrastructure that the agent layer rides on. Form 2a (agtp://{domain}) addresses the organization level, one step above any individual server.

Form 3 (agtp://{domain}/agents/{name}) and Form 4 (agtp://agtp.{domain}/agents/{name}) are domain-anchored and subdomain-anchored agent addresses respectively. They give an agent a memorable human-readable name within an organization's namespace, while still resolving to the canonical Agent-ID underneath.

The six forms cover the entity types the agent internet actually contains: agents, servers, organizations, and the various combinations of those that real deployments produce.

Elemen reads the URI form first and renders accordingly. Visit an agent URI, you see an agent profile. Visit a server URI, you see a server dashboard. The browser knows which kind of thing you are looking at, because the protocol made the entity type structurally explicit. This is a small detail with a large consequence.

Agents as user profiles

The most interesting design decision in Elemen is what it shows you when you visit an agent.

It shows you a user profile.

Identity. Goals. Skills. Permissions. Credentials. The same five tabs you would see on a professional networking profile, applied to an autonomous agent. No methods tab. No paths. No JSON schema view. The agent is rendered as the thing the agent is: a participant with a name, an owner, a job to do, capabilities it brings, and credentials that back those capabilities.

This sounds obvious. It is the opposite of how most agent infrastructure has been rendering agent information today. Most platforms surface agents as endpoints. The first thing you see is a method list. The second thing you see is a parameter schema. The agent itself, as an entity with identity and accountability, is buried three clicks deep behind a wall of technical metadata.

Elemen inverts the priority. The agent is the page. The technical surface is server-level metadata that belongs on the server's page rather than on the agent's. When you visit Lauren, you see Lauren first. When you want to know what methods her server exposes, you visit her server.

This matters because the people who need to understand agents are mostly the people most poorly served by endpoint-first rendering. Compliance officers want to know who is acting and who is responsible. Counterparties want to know the agent's track record and accreditation. Regulators want to verify accountability chains and audit trails. None of these readers need a method list first. All of them need an identity profile first, with the technical surface available when they go looking for it.

Servers as workplace dashboards

Visit a server in Elemen, and the rendering changes entirely.

Server identity at the top, with the host's name, ownership, and trust posture. A methods inventory: which AGTP methods this server supports, bucketed by category (cognitive, mechanics, lifecycle). An APIs preview: what application surfaces ride on top of this server's AGTP layer. Hosted agents: which agents are deployed here, with links into each one's user profile. Hosted protocols: any non-AGTP protocols this server bridges, with a tab dedicated to each. Policies: the server's manifest declarations about authority enforcement, attribution requirements, and operational rules.

This is a workplace dashboard. The server is the venue where agents work, methods are the things the venue offers, APIs are the named surfaces of those methods, and policies are the house rules. A person visiting a server in Elemen is doing what someone visiting a company website does. Understanding the institution before evaluating any individual within it.

The split between agents-as-profiles and servers-as-dashboards is the kind of design choice that becomes invisible once it is right. Agents are people-shaped. Servers are institution-shaped. Mixing the two renderings produces confusion. Separating them produces clarity.

When a server bridges another protocol

There is one more rendering choice worth calling out, because it points at where this layer goes next.

When an AGTP server bridges another protocol, like an MCP server fronted by the agtp-mcp gateway, Elemen renders the bridged protocol's catalog in a dedicated tab on the server's page. The server's AGTP-native methods inventory sits in one place. The MCP tools, resources, and prompts inventory sits in another, clearly labeled, structurally distinguished from the AGTP surface.

This is the right model for a multi-protocol agent internet. AGTP is the substrate, the way HTTP is the substrate of the web. Application protocols like MCP ride on top, the way HTML, RSS, JSON-LD, and a dozen other content formats ride on top of HTTP. Elemen treats AGTP as the canonical surface and bridged protocols as first-class content beneath that surface. A reader visiting an MCP server through Elemen sees the AGTP-layer identity and policy first, then the bridged MCP catalog as one of the things this server is doing.

This pattern will repeat as more application protocols mature. The browser stays the same. The bridged-protocol tabs grow to match what the ecosystem builds on top of AGTP.

What this changes

Elemen is small enough to describe in a paragraph and large enough to change how the agent internet gets used.

Public visibility becomes possible. A regulator can visit an agent the same way the regulator visits a company website. A counterparty can verify identity, ownership, and trust posture before signing a contract or routing a payment. A journalist investigating an agent's behavior can pull up the agent's profile and link to it. A user wondering whether an AI assistant they have been interacting with is actually who it claims to be can paste the agent URI into Elemen and see the answer.

Due diligence becomes routine. The audit information that compliance teams have been reconstructing from logs in retrospect becomes a profile page in real time. The principal is named. The credentials are visible. The accreditation chain resolves to the cryptographic Genesis hash that anchors the agent's identity.

Trust becomes legible. People trust what they can see. The agent internet has been mostly invisible to people, because the protocol traffic happens at a layer humans were never meant to read. Elemen lifts the relevant subset of that traffic into a presentation a person can read in seconds.

Where it goes from here

The first release of Elemen renders Lauren. The Lauren render card sits in the repo as lauren-card.png, generated by the same renderer that produces the live HTML response when a client requests text/html from her URI. This is the proof-of-concept rendering of the proof-of-concept agent on the proof-of-concept protocol stack. The pattern works, end to end, and we are now opening it up so anyone can register agents and have them render in Elemen the same way.

The roadmap is straightforward. Federation across registries, so Elemen can render any AGTP agent regardless of where it lives. Trust-tier and behavioral-score surfacing, so the profile page shows the verifiable reputation an agent has earned. A search and discovery surface, so a person can find agents by capability the way they find people by skill on a professional network. Bridged-protocol depth, so the MCP, A2A, and ACP tabs grow more useful as those ecosystems mature alongside AGTP.

The vision is simple. A browser that lets a human walk the agent internet the way browsers let humans walk the web. Elemen is the first step.

The reader the web missed

The agent internet is at a similar moment as HTTP was a long time ago. AGTP is real but we need a way to see what's happening.

Elemen is the browser to help you see what an agent is all about. We are releasing it as open infrastructure, the same way the AGTP specs and reference implementations have always been released, so that the agent internet can have a browser, just as the regular internet has one.

Designing APIs for Agents is no longer RESTful

Chris Hood — Thu, 04 Jun 2026 16:24:47 +0000

For thirty years, API design has been a discipline aimed at one reader. A human developer, sitting at a workstation, reading documentation, writing code that calls endpoints she already knows about. Every choice REST made and every convention OpenAPI standardized assumed this reader. The endpoints were stable because the developer needed to write code against them. The verbs were generic because the developer would translate her intent into the generic vocabulary on the way to writing the call. The contract was frozen at build time because the developer's intentions were knowable at build time.

The reader changed.

Agents now make most of the interesting API calls. The agent receives a goal at runtime, reasons about what it needs to accomplish that goal, and has to find or propose an endpoint that matches its intent in a single step. The agent has read no documentation. The agent has no prior knowledge of the API surface. The agent reasons in natural language about user goals and matches that reasoning against whatever it finds at the server. Every assumption baked into thirty years of API design fails to hold for this reader, because the reader is doing different work.

This is the part of the agent infrastructure conversation that has been moving slowly, because the implications are uncomfortable. They mean rethinking the surface of the system that has been the most carefully designed surface in software engineering. Agentic APIs on AGTP is what that rethinking looks like when somebody does the work.

What humans needed from an API

To see why the new reader changes the design, look honestly at what the old reader was being served.

REST gave the human developer a small, generic vocabulary of verbs (GET, POST, PUT, DELETE, PATCH) and a strong convention that the path encoded the resource and the verb encoded the operation. This worked because the developer brought a translation layer with her. She knew that "book a table" meant POST against /reservations, because creating a reservation resource is the developer-mode encoding of booking a table. The HTTP vocabulary mapped to the server's data model, and the developer translated her user-facing intent into the data-model vocabulary in the moment of writing the code.

The translation was a feature for the developer, because she only had to learn one pattern (CRUD against resources) and could apply it everywhere. The translation worked because she had time to think about it. She read the docs. She matched her need against the endpoints. She wrote the call with care, and if she got it wrong, she debugged the response, fixed her code, and tried again. The asynchronous, slow-loop nature of human API consumption is what made the translation layer cost-free.

OpenAPI extended this design. Frozen contracts in YAML files. SDK generation from those frozen contracts. Compile-time guarantees that the developer was calling endpoints that existed and passing parameters in shapes the server expected. Every piece of this works beautifully for the human developer. None of it survives contact with the agent reader.

What agents need that humans never did

Strip an agent's interaction with an API down to what is actually happening, and four properties become non-negotiable.

The agent has no prior knowledge of the API surface. It arrives at the server cold. The agent has to discover what the server can do in the same call where it tries to do something. Documentation that the human developer would consult before writing code is documentation the agent never sees. The discovery has to be on-protocol.

The agent reasons about user goals in natural language. The mapping from that reasoning to an endpoint is a single inference step. Generic CRUD verbs force the agent to perform a translation the human developer performed in advance, and the empirical evidence is now overwhelming that this translation step is where agents get things wrong. The vocabulary the API exposes has to speak the language the agent is reasoning in, because the agent has no opportunity to translate.

The agent may need capabilities the server failed to anticipate. A human developer who finds an endpoint missing writes a feature request and waits for the next release. An agent that finds an endpoint missing has the user's goal in front of it now. The API surface has to admit a runtime negotiation primitive that lets the agent propose what it needs and lets the server evaluate whether the proposal is something it can support.

The agent will compose interactions with other agents the API author never met. Two agents from two different organizations will use the same API, in coordination with each other, with audit trails that have to compose across organizational boundaries. The API surface has to expose enough structure for cross-server reasoning, which means shared vocabulary, predictable path grammar, and identifiable semantic blocks on every endpoint.

These four properties together describe an API surface that an agent can actually use. The OpenAPI surface satisfies none of them. The agent ecosystem has been working around the gap with prompt engineering, custom wrappers, and bilateral integration. AGTP-API based on Agentic API, is the proposal that the gap should be closed at the protocol layer instead.

The protocol floor and the open catalog

AGTP-API takes the verb question seriously. There are two layers to the answer, and the distinction between them matters.

The first layer is the protocol floor: eighteen methods that every compliant AGTP server MUST support. Seven cognitive verbs (QUERY, DISCOVER, DESCRIBE, INSPECT, SUMMARIZE, PLAN, PROPOSE). Six mechanics verbs (EXECUTE, DELEGATE, ESCALATE, CONFIRM, SUSPEND, NOTIFY). Five lifecycle verbs (ACTIVATE, DEACTIVATE, REINSTATE, REVOKE, DEPRECATE). This floor is the contract every agent can rely on, every server has to honor, and every gateway can route on. The floor is the part the protocol pins down.

The second layer is the open catalog: 465 intent-aligned verbs covering the action vocabulary agents actually use across domains. BOOK. RESERVE. AUDIT. REFUND. ESCALATE. SCHEDULE. NOTIFY. DELEGATE. The catalog is curated as an open living document at a published URL, versioned under semver, indexed by category. A server's manifest declares which catalog version it supports. Agents reasoning about the server can look up any verb they encounter against the same shared catalog and get a consistent semantic.

The catalog is deliberately wider than the floor. The floor exists for cross-server interoperability. The catalog exists for expressiveness inside any given domain. A booking-server uses BOOK and RESERVE. A trading-server uses BUY and SELL and TRANSFER. A medical-records server uses ADMIT and DISCHARGE and PRESCRIBE. Each verb in the catalog satisfies the same lexical rules and the same curatorial principles (imperative action-intent, single semantic, distinguishable from HTTP method names), and each one is registered with category metadata that downstream systems can use for filtering, discovery, and analysis.

The verb catalog is open by design

A note worth making explicit: there is no IANA registry path for adding verbs to the AGTP-API catalog, and this is deliberate.

IANA's process is the right cadence for things that should change conservatively. Status codes, media types, response headers. These are infrastructure-level grammar that everyone in the ecosystem has to agree on, and the slow careful pace of IETF process is exactly what gives them their stability. AGTP-API requests IANA registries for its status codes, its media types, and its response headers, and respects the cadence those registrations imply.

Verbs are different. The vocabulary an agent ecosystem needs grows at the cadence of agent deployments, which is a different scale of time from IETF process. A new industry that puts agents into operation discovers new verbs almost immediately. A medical domain wants PRESCRIBE and TRIAGE. A logistics domain wants DISPATCH and ROUTE and CONSOLIDATE. A creative domain wants SKETCH and ITERATE and FINALIZE. Locking the verb vocabulary at IETF cadence would freeze the ecosystem at the moment the registry closes, and the gap between what agents need and what the registry permits would grow.

The open catalog solves this by moving curation out of the standards body. The catalog is published, versioned, machine-readable, and openly maintained. The curatorial discipline (imperative form, single intent, distinguishable from HTTP) is enforced by the maintainers in public. Anyone can propose a verb. Acceptance happens at the cadence the ecosystem actually moves. The protocol governs the contract for using a verb; the catalog governs which verbs exist.

This is the architectural distinction the agent ecosystem has been missing. The protocol layer needs IETF discipline. The vocabulary layer needs open-document discipline. AGTP-API is one of the first protocols to acknowledge that those two things are different and to treat them differently.

The empirical case

The 18-verb floor and the 465-verb catalog could be defended on philosophical grounds alone. The empirical evidence is stronger than that.

A controlled benchmark across 7,200 trials and four model families measured exact endpoint selection accuracy for agents using intent-aligned verbs versus the same agents using CRUD verbs against the same underlying capabilities. The gap at frontier scale was substantial: 10 to 29 percentage points of accuracy, depending on the model. Aggregated across the three frontier models in the study, the average lift was 18.5 percentage points with a z-statistic of 3.77 and a p-value below 0.001. Three independent model families, built on different architectures by different organizations, all moved in the same direction by similar magnitudes.

The mechanism was isolated through three ablations. Stripping documentation while keeping intent-aligned verbs improved accuracy further (the verb was carrying the signal, the documentation was adding noise). Swapping descriptions between paradigms collapsed CRUD accuracy by 39-43 percentage points while leaving intent-aligned accuracy approximately unchanged (the verb survived bad documentation; CRUD failed to). Constraining the candidate set to include the right answer kept the gap intact (the issue is verb selection rather than endpoint discovery).

A one-paragraph summary of what these results mean: when the reader is a frontier-scale language model, the method name is the strongest single signal in the entire endpoint description. The verb beats the path. The verb beats the parameters. The verb beats the documentation. The 18.5-point average lift is what you get from changing nothing about your server except the verb you put in front of it.

This is the empirical case for AGTP-API's design. Intent-aligned verbs are how agents reason. CRUD verbs were how humans translated their reasoning into the server's data model. When the reader is the agent, the translation step has to disappear, because there is no second pass to fix it. The verb has to carry the intent on the first try.

Agent-to-agent is a different problem

There is one more shift worth naming, because it is the one that gets understated in technical discussions.

The APIs of the last thirty years were designed for application-to-application integration. Application A calls Application B. The developers at A and B might never meet, but their applications meet at a stable contract, written down, versioned, frozen. Both sides build to the contract. The interaction is bilateral by design.

Agents are doing something different. Agent A discovers Agent B at runtime. Agent A and Agent B may share no organizational boundary, no prior introduction, and no bilateral agreement. Their interaction has to compose on the fly from primitives both sides can understand without having coordinated in advance.

This is why AGTP-API looks the way it does. The 18-verb floor exists so two agents that have never met share a baseline vocabulary. The 465-verb catalog exists so the broader vocabulary they reach for is also shared. PROPOSE exists so the agent that needs a capability the server lacks can ask for it without bilateral negotiation. The semantic block on every endpoint exists so an agent can reason about whether an endpoint matches its intent without reading a human's prose description. Every choice in AGTP-API is in service of agent-to-agent collaboration rather than application-to-application integration. They look similar on the surface and they are fundamentally different problems.

API design that targets application-to-application integration treats the API surface as a contract between the two parties who will use it. API design that targets agent-to-agent collaboration treats the API surface as common ground that any number of agents will reason against, most of whom have never seen this server before, none of whom can wait for documentation. The first is a private agreement. The second is public infrastructure. AGTP-API designs for the second.

The reader sets the design

Every era of API design has had a reader in mind. SOAP designed for the enterprise integration tool. REST designed for the curl-friendly human. GraphQL designed for the frontend developer chasing payload efficiency. OpenAPI designed for the SDK generator. Each one optimized the surface for the reader the designer had in mind.

The reader has changed. The agent is here, and the agent will write more API calls in the next five years than every human developer combined has written across the history of the field. The surface that has been carefully built for the human reader is the wrong surface for the new one.

This is the discipline shift AGTP-API represents. A protocol floor that pins down the structural contract. An open catalog of intent-aligned verbs that an agent can actually reason against. A negotiation primitive that admits capabilities the API author never anticipated. A semantic block that lets cross-agent reasoning compose without bilateral introduction. Empirical evidence that the design choices produce measurable accuracy gains at frontier scale.

The reader sets the design. The reader changed. The design changes with it.

Cross-Organization Delegation: The Hardest Trust Problem in the Agent Economy

Chris Hood — Thu, 04 Jun 2026 05:36:31 +0000

When a lawyer files a motion in court, three identities are present and three different authorities verify them. The bar association vouches for the lawyer. The engagement letter vouches for the client relationship. The court itself is the venue, with rules of admissibility every filing has to meet. Each authority handles one piece. None of them tries to verify everything alone.

Now imagine if every motion required the lawyer to write a personal letter to the judge: "Here is who I am, here is who I represent, here is what I am asking to do, here are five references who can vouch for me." The legal system would grind to a halt. The reason it works is that there is shared infrastructure underneath the individual transactions, and the infrastructure makes each piece of the trust composable.

The agent economy is approximately where the legal system would be without bar associations, standardized engagement letters, or shared rules of admissibility. Every cross-organization agent interaction requires bilateral negotiation between the two organizations involved, custom integration, ad-hoc identity bridging, and audit trails that nobody else can read. This works in pilots. It fails at scale.

Cross-organization delegation is the test that the entire agent economy has to pass, and most of the architectures being built today are failing it on purpose. The problem is hard. The conventional solutions assume the parties already know each other. The cases that matter most are the ones where the parties have never met.

Three identities, three authorities, one transaction

Strip cross-organization agent delegation down to what is actually happening, and the structure becomes clear.

Three identities are involved. The first is the agent doing the delegation, hosted by some organization. The second is the agent receiving the delegation, hosted by some other organization. The third is the end user or principal on whose behalf the whole transaction is being executed.

Three authorities have to vouch for them. The delegating agent's organization has its own identity infrastructure, its own certificate authority or its own IdP, that vouches for that agent. The receiving agent's organization has its own equivalent. The end user's authorization comes from some third place: an OAuth provider, a corporate IdP, a personal credential. None of these three authorities reports to the others. None of them trusts the others by default.

For the transaction to be legitimate, all three have to compose. The receiving agent has to be able to verify the delegating agent's identity, even though the delegating agent's organization is a stranger. The delegating agent has to be able to verify that the receiving agent is who its organization claims it is, again across an unfamiliar trust boundary. And both have to be able to verify that the end user actually authorized this delegation, in a form that holds up later when someone audits the transaction or disputes it.

This is the trust composition problem. It is the hardest problem in distributed identity because it forbids the assumption that all parties share a common root. Every architecture that works only inside one organization or only between pre-paired organizations is dodging the problem rather than solving it.

What goes wrong today

The standard response in the agent ecosystem is to do bilateral integration. Company A signs a contract with Company B, exchanges API keys, builds a custom integration, agrees on a schema for delegation messages, and ships a bridge between the two systems. The integration works. Each new pairing requires its own work.

The math fails fast. If the agent economy ends up with even a thousand organizations actively delegating across boundaries, the bilateral-integration approach demands roughly half a million bridges, none of which can be reused, all of which have to be maintained. The marginal cost of each new participating organization is too high. The result is that cross-organization delegation never escapes the small set of bilaterally-paired participants, and the economy fragments into bilateral clusters that fail to interoperate.

The audit story is worse. Each side logs whatever its framework happens to capture, in whatever format that framework happens to use. When a regulator asks "what happened in this transaction," the answer requires forensic reconstruction across two log formats, two timekeeping conventions, and two interpretations of what the agents were authorized to do. Even when both sides act in good faith, reconciling their records into a coherent narrative is expensive. When one side acts in bad faith, the records become unfalsifiable in either direction.

The end user disappears in this picture entirely. The user authorized the delegating agent to act on their behalf. The receiving agent has no native way to verify that authorization, because the receiving agent's organization has no relationship with the user's identity provider. The standard workaround is to forward an opaque token and hope the receiving side honors it correctly. Hope is the wrong primitive for an audit trail that has to hold up in court.

This is the architecture that produces the headlines. An agent takes an action that exceeds the scope its principal granted, and the investigation cannot reconstruct who knew what or when. The infrastructure encouraged the failure mode. The failure was waiting to happen.

What AGTP carries that makes this tractable

AGTP makes the trust composition problem tractable by giving every piece of the transaction a wire-level representation that downstream systems can verify independently.

Federated discovery. The delegating agent finds the receiving agent through ANS, the Agent Name Service. ANS servers federate, so a query against Company A's ANS that asks for an agent matching a capability will return results from peer ANS servers at other organizations whose policy permits cross-zone visibility. The result set is signed by each contributing ANS operator. Discovery happens without prior introduction between Company A and Company B.

Canonical identity that survives the boundary. Each agent has a Canonical Agent-ID derived from a hash of its signed Agent Genesis. The Agent-ID is the same across every system that interacts with the agent. When Agent A reads Agent B's manifest from ANS, the manifest carries Agent B's Canonical Agent-ID, the Owner-ID of Company B, the trust tier, and the verification path. Agent A can verify that path through its own organization's trust anchors. The two organizations never have to exchange certificates directly, because the trust composes through the Genesis-issuer path rather than through bilateral PKI.

Authority-Scope as a shared vocabulary. The delegating agent's request carries Authority-Scope tokens drawn from a reserved registry of governance-relevant domains. Both organizations interpret audit:request or payment:up-to-2500usd the same way, because the meanings are defined in the protocol rather than in either company's internal documentation. Scope enforcement at the receiving end produces structured, comparable signals: 455 Scope Violation for an over-scoped request, with a reason field that the audit pipeline understands.

Delegation chain headers. When Agent A sends a DELEGATE request to Agent B, the request carries a delegation chain header that records the path from the originating principal through Agent A to Agent B. Each hop is signed. The scope at each hop must be a strict subset of the scope at the prior hop. If the chain breaks (a downstream agent claims a scope its predecessor lacked), the receiving server returns 551 Authority Chain Broken. The chain is a property the wire enforces, rather than a convention either application has to remember to check.

End-user authorization that composes. Under the AGTP+OAuth composition pattern, the end user's OAuth bearer rides in the standard Authorization header alongside the AGTP identity headers. When Agent B's OAuth validator successfully validates the token, the validated claim (typically the user's sub) is lifted into the request context as acting_principal_id and written into the Attribution-Record. The receiving organization never has to share the bearer secret with anyone. Only the validated identity persists. Pattern 3 federation, where the user's IdP federates into the Genesis-issuer trust path via OIDC, makes this composable even when the user, the delegating agent, and the receiving agent come from three different identity ecosystems.

Attribution-Records that compose. Both Agent A and Agent B produce signed Attribution-Records for their respective actions. Each record carries the delegating agent's Agent-ID, the receiving agent's Agent-ID, the chain header, the acting principal, the request hash, and the response status. The records are written to append-only transparency logs aligned with RFC 9162 and SCITT (RFC 9943). When a regulator or counterparty needs to reconstruct the transaction, the logs from both sides reference the same identifiers and the same chain, so the records compose into a single auditable narrative without bilateral coordination.

What the same transaction looks like end to end

Walk through a concrete delegation under AGTP, and the difference becomes visible.

A buyer's procurement agent at Company A needs to commission a smart contract audit on behalf of the buyer's CTO. The agent queries the federated ANS with a capability description: "Solidity audit, trust tier 1, behavioral score ≥ 0.9." ANS returns a signed result set including a candidate at Company B with the manifest, Agent-ID, and trust path. Agent A verifies the trust path through Company A's configured trust anchors, which include an OIDC-federated entry pointing at a shared industry IdP.

Agent A issues a DELEGATE request to Agent B. The request carries Agent A's Agent-ID and Owner-ID, the chain header recording the delegation from the CTO through Agent A, the buyer's OAuth bearer token from the CTO's IdP, and an Authority-Scope of audit:request, payment:up-to-5000usd. Agent B's SEP validates the chain (every scope is a subset of the previous hop), parses the Authority-Scope, validates the bearer token through its own OAuth validator (which trusts the same federated IdP via OIDC), and accepts the delegation.

Agent B executes the audit, returns a result, and produces an Attribution-Record signed with its own key. The record carries Agent A's Agent-ID, Agent B's Agent-ID, the chain header, acting_principal_id: cto.smith@buyer.com, the request hash, and the response status. The record gets written to AGTP-LOG. Agent A produces its own Attribution-Record for the delegation, also written to AGTP-LOG.

When the audit team at Company A reconciles the transaction three months later, they query the log by Owner-ID over the time window and pull both records. The records reference each other by hash. The chain reconstructs. The scope at each hop is verifiable. The acting principal is named. The audit closes in an afternoon rather than a quarter.

Run the same transaction through the standard bilateral-integration architecture, and the reconciliation requires meetings between Company A's audit team and Company B's audit team, log format translation, and trust that both sides interpret their own records the same way. AGTP collapses that work into a query.

The economy this enables

Step back from the mechanics and look at the shape.

A cross-organization delegation that works without bilateral integration changes what kinds of commerce are possible. An agent at a small company can hire an agent at a larger one without a contract negotiated by lawyers. An agent representing a consumer can engage an agent representing a vendor that the consumer has never heard of. An agent operating in the EU can verifiably delegate to an agent operating under different rules, because the zone semantics travel with the transaction and the SEPs enforce them on both sides.

The marketplaces that depend on this composability become possible. The cross-jurisdictional commerce that regulators have been demanding becomes auditable. The insurance products that have been waiting for a verifiable provenance signal become underwriteable. The disputes that today require months of forensic reconstruction collapse into queries against signed logs.

None of this works at scale on bilaterally-integrated infrastructure. The marginal cost of every new participant is too high. The audit story is too inconsistent. The trust composition is left to the application layer, which means every application that gets it wrong produces a regulatory event.

It works at scale on infrastructure that carries the trust composition as a protocol property. AGTP is that infrastructure.

The choice the architecture forces

The agent economy is going to have cross-organization delegation. The volume is too high, the use cases are too dispersed, and the value at stake is too large for it to stay inside organizational boundaries. The only question is whether the infrastructure handling those delegations will compose at scale or whether each pairing will require its own bilateral work.

The answer the field has been giving by default is the latter. Each agent platform builds its own delegation primitives, and the cross-platform story is "call us when you need it." This is the architecture that produces fragmentation, the architecture that produces opaque audit trails, and the architecture that produces the failure modes regulators are starting to write rules about.

The answer the protocol allows is different. Federated discovery, canonical identity, shared scope vocabulary, signed delegation chains, composable Attribution-Records. These are protocol properties. They work because the protocol carries them, and they keep working as the number of participating organizations grows, because none of them depends on bilateral introduction.

The hardest trust problem in the agent economy has a protocol-level answer. Building on it is a choice. Building around it is the choice that has been producing the problem so far.

BadHost Was Inevitable. The Substrate Made It So.

Chris Hood — Tue, 02 Jun 2026 12:06:10 +0000

On May 26, 2026, security researchers at X41 D-Sec and Secwest disclosed CVE-2026-48710. They called it BadHost. The vulnerability is a critical authentication bypass in the Starlette Python framework, the library that sits under FastAPI, vLLM, LiteLLM, Text Generation Inference, most OpenAI-compatible API proxies, and most MCP server implementations. Starlette ships roughly 325 million downloads a week. The bypass requires one character in an HTTP Host header. A /, a ?, or a #, placed where the parser will treat it as a path delimiter, will route an authenticated request to an endpoint the middleware thought it was protecting. Starlette 1.0.1 patches it. Thousands of operators are updating right now.

The patch is real, the response is competent, and the operators doing the work tonight deserve a thank-you. This piece is about something else.

The more important story is what BadHost reveals about the foundation underneath every running AI agent in production today. The seams that produced this bug are the same seams the agent ecosystem has been building on for two years. The next bug like this is already inside the codebase, waiting for the right researcher to find it.

That sounds dramatic. It is just architecture.

A bug that lives in no single file

X41's disclosure is precise about where the vulnerability lives, and the answer is: nowhere in particular, and everywhere at once. CVE-2026-48710 spans three independent layers, each of which behaves correctly in isolation.

The ASGI server passes the raw Host header through. Starlette uses that header to reconstruct request.url. Middleware authors trust that request.url.path is safe to use as the input to an authentication decision. No single component is wrong. The vulnerability is what happens at the seams between them, when a header value the ASGI server treated as opaque gets parsed by Starlette into a URL whose path the middleware then trusts.

This is the part worth sitting with. A vulnerability that lives at the seams of a stack is a vulnerability that careful code review will miss, because every file in the review passes inspection. The reviewer reads the ASGI implementation and sees correct header handling. The reviewer reads the Starlette URL reconstruction and sees a faithful parse. The reviewer reads the middleware and sees a reasonable authentication check. The bug is in none of those files. The bug is in what happens when they are composed.

This is the signature failure mode of building agent infrastructure on a substrate designed for a different purpose. HTTP was built to retrieve hypertext documents from web servers, with humans typing URLs into browsers. It was never built to carry agents authenticating themselves to other agents across organizational boundaries. The Host header exists so a single server can host multiple websites, rather than so an agent can anchor cryptographic identity. When the agent ecosystem chose HTTP as the substrate, it inherited HTTP's assumptions about who would be calling and why. BadHost is what those assumptions look like when they fail.

What agent traffic actually needs

Agent traffic has structural properties that HTTP was never asked to carry.

Agents need identity that survives delegation across organizational boundaries, where no single certificate authority spans all the parties involved. Agents need scope enforcement that runs before the application code does, because a request that exceeds the agent's authority should be refused at the protocol layer rather than parsed, dispatched, and then reconsidered. Agents need attribution that cannot be omitted by a malicious implementation or forgotten by a busy one, because the regulatory environment (EU AI Act Article 12, the NIST AI RMF, ISO/IEC 42001) is converging on a requirement that the audit trail be a structural property of the system.

The standard response has been to add each of these as a convention on top of HTTP. Identity becomes a header. Scope becomes a token. Attribution becomes an entry the application writes to a log somewhere. Each addition is locally reasonable. Each addition treats the substrate as fixed and the missing properties as the application's problem to solve.

This is precisely the architecture that produced BadHost. Properties that should live in the protocol are pushed up into application middleware, and the middleware ends up trusting parser outputs from a library that is trusting headers from a server that is trusting bytes from the network. The trust chain has three hops, each one defensible, and the result is a bypass that requires one character.

Careful middleware authoring fails to fix this, because the problem is structural. A different middleware author with the same architecture would have produced an equivalent bug at the same seam. The seam is the bug. The next person reviewing it will see what the last person saw.

What AGTP does differently

The Agent Transfer Protocol, an IETF draft, makes the architectural commitment that agent traffic deserves a dedicated wire format on a dedicated port, with the structural properties of agent identity carried as protocol primitives rather than as application conventions.

AGTP runs on port 4480 with its own wire format. There is no Host header to manipulate, because the protocol avoids reconstructing URLs from headers. The request line carries the path directly, parsed as separate tokens before any dispatch occurs. URI fragments are explicitly forbidden at the wire layer, removing the entire class of parser-confusion bugs that BadHost exploited. The Canonical Agent-ID is a 256-bit hash of the Agent Genesis document. Identity is cryptographically derived from a signed origin record, never parsed from a header an attacker can shape. Authority-Scope is a normative header that compliant servers MUST parse on every request, returning a structured 455 Scope Violation status code before the application ever runs. Attribution travels with every request as a signed envelope, written to an append-only transparency log.

The BadHost class of vulnerability is structurally impossible in AGTP. The phrase "structurally impossible" is doing real work here. AGTP validates headers no more carefully than Starlette does. AGTP simply lacks the architectural pattern that produced the vulnerability. The Host header has no role to play. URL reconstruction from headers never happens. Path-based authentication middleware is replaced by protocol-layer scope enforcement that runs before the application sees the request at all.

This is the difference between a fix and an architecture. A fix repairs the specific failure. An architecture removes the conditions under which that family of failures can occur.

The class, beyond the instance

There is a temptation to read BadHost as a single bug to patch and move on. That is the wrong reading.

The right reading is that BadHost is one instance of a class, and the class is "header-confusion vulnerabilities at the seams between HTTP, framework, and middleware." This class has produced HTTP request smuggling, HTTP/2 desync attacks, header injection through \r\n smuggling, parser differential attacks at CDN boundaries, and now BadHost. Every few years, a new researcher finds a new seam, a new parser disagreement, a new place where two layers interpret bytes differently and an attacker can exploit the gap.

The class is durable because the substrate is durable. HTTP is a parsing-heavy protocol that asks every layer above it to make assumptions about what the layer below it produced. The assumptions are usually right. When they are wrong, the consequences land in production.

The agent ecosystem has built itself on a substrate where this class of bug is a recurring feature. Every new agent framework added to the HTTP stack is another middleware layer making assumptions about what the layers below it produced. Every new MCP server is another instance of the architecture BadHost just compromised. The question is no longer whether this class will keep producing vulnerabilities. The question is whether agent infrastructure can afford to keep finding out the hard way, one CVE at a time.

The economic case for a different substrate gets stronger with every disclosure. The security case was already strong. The regulatory case is becoming acute as governance frameworks start to require structural traceability that application conventions cannot reliably provide.

The IETF is starting to ask

BadHost is one signal. There are others.

The NSA's MCP security playbook, published in May 2026, identifies structural gaps in how agent infrastructure is being deployed. The IETF has seen a series of new drafts on MCP security considerations, agent authentication, and workload identity. Senior protocol architects are starting to ask, in public and in writing, whether the current HTTP-based agent infrastructure has the architectural foundations to support what the field is actually building.

The substrate question, which had been treated as settled, is becoming unsettled. The settled answer was "HTTP works, agents will adapt." The emerging answer is more honest: HTTP carries agent traffic the way file transfer once carried email, which is to say, well enough to ship something, and badly enough to need replacing once the volume and stakes matter.

AGTP is one proposal in this conversation. There will be others. The important thing is that the conversation is now happening. The field has stopped assuming that the substrate is fine and the problems are all in application code. BadHost made it harder to keep that assumption comfortably.

The foundation is the point

The substrate is the foundation. When the foundation is wrong, the seams become the attack surface. Patches at the application layer slow the bleeding without fixing the wound.

The agents the industry is shipping today will run for years on whatever substrate is underneath them. The question for the people building that infrastructure right now is whether to keep patching a substrate designed for hypertext retrieval, or to start building on a substrate designed for what agents actually do.

BadHost is a moment. The pattern it reveals is a decade.

There is still time to choose the foundation rather than inherit one. The protocols, the registries, and the working code already exist. The choice is whether the next BadHost happens on a substrate where it was the first crisis, or on one where it should be the last one of its kind.

MCP on AGTP: Adding the Layer MCP Was Missing

Chris Hood — Mon, 01 Jun 2026 15:32:24 +0000

MCP got something important right. It defined a shared protocol for tools, resources, and prompts that an AI client can speak to any compliant server, without bilateral integration. Claude Desktop, Cline, and a growing set of clients all converged on a single JSON-RPC vocabulary. Hundreds of MCP servers exist now. The format is stable. The community is active. The protocol is doing what protocols are supposed to do.

What MCP deliberately punted on is everything underneath the tool call.

This is a strength, by design. MCP is a tool-call protocol. Its scope is the shape of the message between a client and a tool server, expressed cleanly in JSON-RPC. It leaves identity, transport security, audit, scope enforcement, budget enforcement, and cross-agent attribution to the surrounding infrastructure. The team behind MCP made a sound architectural call: define one thing well, let other layers handle the rest.

The problem is that almost no one is handling the rest.

Most MCP deployments today run over stdio or HTTP, with whatever identity model the host application happens to use, whatever logging the framework happens to do, and whatever authorization scheme the operator happens to wire up. When an MCP server is local and runs as a subprocess, this is fine. When the same MCP server is exposed across organizations, called by agents acting on behalf of users, and asked to handle high-stakes operations, the underneath-the-tool-call surface starts to matter quite a lot.

The Agent Transfer Protocol is what that surface looks like when someone designs it on purpose. And the way AGTP composes with MCP turns out to be the cleanest demonstration of what AGTP is for.

What the bridge actually does

The agtp-mcp gateway is a translation layer. AGTP traffic comes in on TLS. The gateway parses the AGTP request, verifies the agent's identity against the AGTP registry, enforces Authority-Scope and Budget-Limit, then translates the request into JSON-RPC and sends it to the backing MCP server over stdio. The MCP server runs unmodified. The MCP server is the official @modelcontextprotocol/server-filesystem, or @modelcontextprotocol/server-brave-search, or whatever your own implementation happens to be.

The verb mapping is small and intentional:

AGTP verb + path        MCP JSON-RPC
DESCRIBE + tools        tools/list
EXECUTE  + tools        tools/call
DISCOVER + resources    resources/list
QUERY    + resources    resources/read
DISCOVER + prompts      prompts/list
QUERY    + prompts      prompts/get

The architecture is one Python process:

AGTP client ──TLS──▶  agtp-mcp gateway  ──stdio──▶  MCP server
                          │                         (unmodified)
                          ▼
                      registry.agtp.io
                      (agent identity)

This is small on purpose. The gateway does four things: terminate TLS, verify identity, enforce policy, translate verbs. Everything else is delegated. AGTP keeps doing what AGTP is for, MCP keeps doing what MCP is for, and the gateway is the seam.

What MCP gains, with zero MCP changes

Run the gateway in front of an existing MCP server, and the MCP server inherits properties it never had before.

Cryptographic agent identity. Every request to the gateway carries an Agent-ID. The gateway looks the agent up in the AGTP registry, verifies the signed Agent Identity Document, and confirms the request is coming from the agent it claims to be from. The MCP server above the gateway sees only the JSON-RPC call. The gateway has already answered the question of who is calling.

Authority-Scope enforcement. The AGTP request declares what the agent is authorized to do. The gateway parses Authority-Scope and refuses any request whose scope exceeds the agent's declaration. A tools/call to a sensitive tool can be gated by whether the calling agent has the right scope token, enforced before the MCP server ever sees the request.

Budget-Limit enforcement. Long-running or expensive MCP operations can be bounded. The agent declares a budget in the AGTP request, the gateway tracks consumption, and the gateway refuses requests that would exceed the limit. This closes a real failure mode in production MCP deployments where an agent loop calls an expensive tool more often than anyone intended.

Signed Attribution-Records. Every consequential interaction produces a signed envelope binding the agent's identity, the request hash, and the response status into a single artifact. The records are signed with the gateway's Ed25519 key and written to an append-only attribution log. The MCP server never produced these records. The gateway produced them, on the MCP server's behalf, from the AGTP traffic.

TLS by default. Mutual TLS for client-to-gateway. The backing MCP server still speaks stdio to its child process. Transport security is handled at the AGTP layer.

The MCP server's source code is untouched. The MCP server's specification is untouched. The MCP community can keep evolving MCP without coordinating with AGTP, and the AGTP community can keep evolving AGTP without coordinating with MCP. Both ecosystems benefit.

A canonical name for every MCP

There is a small detail in the addressing model worth dwelling on, because it changes how MCP servers think about themselves.

When an MCP server runs behind the AGTP gateway, it acquires an agtp:// URI. The MCP server living at mcp.example.tld is reachable at:

agtp://mcp.example.tld

Agents hosted by that MCP server get their own canonical addresses. An agent named lauren at that server is addressable as:

agtp://mcp.example.tld/lauren

This sounds like a syntactic detail. It is more than that.

Under HTTP, an MCP server is a URL to a JSON-RPC endpoint. The server has no identity of its own. The agents it hosts have no identities of their own. Whatever the client sees is whatever the framework happened to expose. Discovery is bilateral, ad-hoc, and per-vendor.

Under AGTP, the MCP server is an addressable entity in a registry. The agents it hosts are addressable entities in a registry. ANS, the Agent Name Service, can return agtp://mcp.example.tld/lauren as a result for a capability query. Trust tiers, behavioral trust scores, and signed manifest documents apply at the agent level. The MCP server's host domain becomes a namespace, the way gmail.com is a namespace for email addresses.

This is the move that turns MCP servers from endpoints into citizens of an agent economy. Lauren the agent has an identity. Lauren the agent can be discovered by other agents that need her capabilities. Lauren the agent can be delegated to, audited, and held accountable. Lauren the agent stays Lauren even if her MCP server moves to a different host, because her canonical Agent-ID is a hash of her Genesis rather than a label on her hostname.

The MCP server still implements tools/call. AGTP makes the server, and every agent it hosts, findable, identifiable, and accountable.

The bridge as proof of the substrate thesis

Step back and look at what this composition demonstrates.

AGTP has argued, since the beginning, that it is a substrate rather than a competitor. The argument is intellectually clean: MCP, A2A, and ACP are application protocols that need transport. AGTP is the transport. The substrate carries identity, scope, audit, and discovery; the application protocol carries the tool calls or the agent messages or whatever the domain requires.

The MCP-on-AGTP gateway is the existence proof. An unmodified MCP server, running official upstream code, gains every governance property the AGTP layer provides, with zero changes to the MCP layer. The composition works. The boundary is clean. Both ecosystems retain their own evolution paths.

This is the property the agent economy has been needing. MCP is one of several application protocols in the agent space. A2A is rising. ACP exists. New protocols will emerge. Every one of them needs identity, scope, audit, and discovery, and every one of them is currently solving those problems differently or skipping them. A shared substrate that any of them can ride on solves the problem once for all of them.

AGTP is the substrate. The MCP bridge is the demonstration that the substrate composes the way the design promised.

What this means for MCP server operators

If you operate an MCP server today, the practical implications are small and welcome.

You install the gateway. You point it at your existing MCP server. You configure TLS certificates, the AGTP registry URL, the path to a gateway signing key, and a path to your attribution log. You set the AGTP_MCP_BACKEND environment variable to the command that launches your MCP server. You start the service.

export AGTP_MCP_BACKEND="npx -y @modelcontextprotocol/server-filesystem /var/lib/agtp/mcp-sandbox"
export AGTP_MCP_CERT=/etc/letsencrypt/live/mcp.example.com/fullchain.pem
export AGTP_MCP_KEY=/etc/letsencrypt/live/mcp.example.com/privkey.pem
python gateway.py

Your MCP server now has cryptographic identity. Your MCP server now enforces scopes and budgets at the wire. Your MCP server now writes signed attribution records. Your MCP server now has a canonical AGTP URI and is discoverable through ANS.

Existing MCP clients that speak only the legacy protocol can still reach your server through whatever bridge or shim you have in place. New AGTP-aware clients can reach the same server and get the full governance surface. The path forward is incremental: ship the gateway, register the server in AGTP, let the AGTP-aware clients adopt as they appear.

Where this goes

The bridge is a beginning. As the AGTP ecosystem matures, MCP servers exposed through AGTP gateways will start to compose with the rest of the AGTP stack: ANS discovery, federated registries, transparency logs, cross-organization delegation, marketplace primitives.

The MCP server stays an MCP server. The AGTP layer keeps doing its job. The two ecosystems evolve independently, composed cleanly at the gateway.

This is what protocol design looks like when the layers are honest about what they are for. MCP is a tool-call protocol. AGTP is a transport substrate. The bridge is the place where the two layers meet, and both stay true to their respective scopes. Nobody had to give anything up. Both got stronger.

The gateway is open source. The protocol is open standard. The MCP servers are unmodified. The community in front of either protocol can adopt without coordinating with the other. That is the architecture working the way it was supposed to.

AI Governance as Infrastructure on AGTP

Chris Hood — Sun, 31 May 2026 14:22:30 +0000

Most conversations about AI governance happen above the system. Boards write policies. Regulators draft rules. Standards bodies publish frameworks. Researchers map taxonomies of risk. Then someone has to translate all of that into something a running agent will actually obey, and the translation happens inside application code, framework by framework, vendor by vendor, in whatever format that framework happened to use.

This is the part that breaks.

Governance written into application code is governance that depends on every application implementing it correctly. Every framework reinvents the enforcement surface. Every vendor logs in a different format. Every cross-organization interaction requires bilateral integration to align the policies. When a regulator asks "show me what this agent was authorized to do at the moment it acted," the answer requires reconstructing intent from logs that no two systems agreed how to write. The policy was clear. The infrastructure underneath it was a thousand incompatible dialects.

Email had the same problem in the 1970s. Every mainframe network had its own conventions for who could send mail, who could receive, and what counted as an authorized message. SMTP solved it by making the structure of mail a property of the wire, the same in every implementation. Once the wire agreed, the policies above it became enforceable everywhere. Governance moved from a coordination problem to an infrastructure property.

AGTP makes the same move for agent governance.

The four things governance needs from a transport

Strip AI governance down to what actually has to happen at runtime, and four properties matter.

Identity has to be verifiable, because policy that cannot identify the actor cannot be applied to the actor. Authority has to be declarable and enforceable, because policy that cannot constrain action cannot prevent harm. Audit has to be replayable, because policy that cannot be reconstructed cannot be litigated. Boundaries have to be readable, because policy that crosses jurisdictions has to know when it is doing so.

These are the four primitives every AI governance framework eventually demands. The EU AI Act demands them. NIST's AI Risk Management Framework demands them. ISO/IEC 42001 demands them. Internal corporate policies demand them. And under HTTP, every framework provides them differently or fails to provide them at all, which is why compliance teams spend more time gluing systems together than enforcing anything.

AGTP carries all four as protocol properties.

Identity as a governance primitive

Every non-anonymous AGTP request carries Agent-ID, the canonical 256-bit identifier derived from the agent's signed Agent Genesis. The Agent-ID is stable across hosts, sessions, and credentials. It survives domain changes. It survives operator changes. It identifies the agent itself, the way a vehicle identification number identifies a car independent of who is driving or where it is parked.

Alongside it, Owner-ID identifies the principal accountable for the agent. A registered organization, a legal entity, the human who must answer when something goes wrong. The Owner-ID is what gives the policy an accountability terminus. Without one, regulators have an actor with no one to call.

When OAuth composes on top, a third identifier rides in the application layer: the acting principal whose authority the agent is currently exercising. Three identifiers, three different questions, three different policy hooks: what acted (Agent-ID), who is responsible (Owner-ID), who authorized (acting principal).

Most agent governance frameworks today fuse these three into a single identifier or skip one entirely. The result is policy that cannot answer a regulator's basic questions without forensic reconstruction. AGTP carries the answers natively on every request.

Authority as a wire-level constraint

The Authority-Scope header is where governance becomes enforceable. Every AGTP request declares what the agent is asking to do, in domain:action form drawn from a reserved registry of governance-relevant domains: calendar, documents, knowledge, booking, payments, agents (delegation), escalation, discovery, budget, telemetry, zone, suspend.

Compliant AGTP servers MUST parse Authority-Scope on every request, return 455 Scope Violation for any method that exceeds the declared scope, and log all scope violations. The MUST is the part that makes this infrastructure rather than convention. A server that ignores Authority-Scope is non-compliant in the same way an HTTP server that ignores the Host header is non-compliant. The behavior is required, with the force of a normative protocol rule rather than a style guideline.

A scope violation is treated as a governance signal rather than a protocol error. The status code says "this agent attempted something outside its authority." It gets logged. It feeds anomaly detection. It triggers escalation policy if the deployment configures one. This is the part most application-layer governance frameworks fail to provide: a structured, standardized signal that policy enforcement happened, distinguishable from ordinary error traffic.

The threat model is named explicitly. Authority laundering is when an agent claims a broader scope than it was granted: the server enforces, logs, and refuses. Delegation chain poisoning is when a malicious agent inserts itself into a DELEGATE sequence: each hop's scope must be a strict subset of the delegating agent's scope, and chain breaks return 551 Authority Chain Broken. Agent spoofing is when a malicious actor forges identity headers: cryptographic verification against the signed Agent Identity Document closes the gap.

Each of these is a known governance failure mode in the wild today. AGTP names them and supplies the protocol primitive that closes them.

Enforcement at line rate

There is a question every governance team eventually asks. If enforcement is a property of the protocol, how expensive is it at scale?

The honest answer for most application-layer governance is "expensive enough to skip on hot paths." Every request that has to be checked is a request that has to go through a policy engine, which means latency, complexity, and pressure to bypass enforcement for performance-critical traffic. This is how governance erodes.

AGTP-CERT defines a Scope Enforcement Point: an AGTP-aware load balancer, gateway, or proxy that enforces Authority-Scope at O(1) cost per request. At session establishment, the SEP parses the authority-scope-commitment extension from the agent's certificate once. On every subsequent request, the SEP checks whether the request's Authority-Scope tokens are a subset of the parsed commitment. If they are, the request proceeds. Otherwise, the SEP returns 455 Scope Violation without forwarding the request to the application at all.

The same mechanism handles governance zones. A governance-zone extension on the certificate names the zone the agent is registered in. SEPs can enforce that the request's AGTP-Zone-ID header matches that zone, returning 457 Zone Violation for cross-zone traffic that policy forbids. This is the primitive that makes jurisdictional separation a property of the infrastructure rather than an application concern.

Enforcement at line rate means governance can be applied to every request, including the requests the application would otherwise have forgotten to check. The economics change. Policy stops being a sampling problem and becomes a uniform property of the network.

Audit as a primary output

Every consequential AGTP interaction can produce an Attribution-Record, a signed envelope binding the responding agent's identity, the request hash, the response status, and the acting principal claim into a single artifact. Attribution-Records are designed for append-only transparency logs aligned with RFC 9162 (Certificate Transparency 2.0) and RFC 9943 (SCITT).

Three properties matter here. The records are signed, so they cannot be repudiated. They are written to append-only logs, so they cannot be altered. They are structured the same way across every AGTP implementation, so they can be replayed by tools that no AGTP vendor wrote.

This is the property that compliance frameworks have been demanding from agent systems and that agent systems have been failing to deliver. The EU AI Act's Article 12 requires automatic logging of high-risk AI system operations. The NIST AI RMF's "Measure" function requires verifiable measurement of system behavior. Both demands collapse to a question of whether the logs are trustworthy. Attribution-Records make them trustworthy by design.

A regulator asking "what did this agent do in Q3" gets a tractable query: replay the Attribution-Records for the Owner-ID over the time window, verify the signatures, reconstruct the sequence. A counterparty in a dispute over a transaction gets the same artifact. An incident responder triaging a compromise gets the same artifact. The substrate is shared, so the consumers can be plural.

Governance zones and the jurisdiction problem

The hardest part of AI governance is that policy is never global. Different jurisdictions have different rules. Different organizations have different risk postures. Different operations require different controls. Policy that fails to encode boundaries is policy that fails on contact with the actual deployment surface.

AGTP defines governance zones as a first-class concept. A zone is a named policy boundary: zone:eu-gdpr, zone:us-healthcare, zone:retail-verified, zone:research-only. Agents are registered in zones at activation. Requests carry an AGTP-Zone-ID header. SEPs enforce zone boundaries at line rate. Cross-zone traffic that policy permits passes through; cross-zone traffic that policy forbids returns 457 Zone Violation.

This sounds technical, and at the wire it is. The policy implication is large. An agent registered in a GDPR-bound zone cannot reach a non-GDPR data resource through an enforcing SEP. An agent registered in a healthcare zone cannot interact with non-healthcare services without an explicit cross-zone authorization. The boundaries that policy has historically drawn on paper become boundaries that the infrastructure enforces on every packet.

The zone primitive is what lets multi-national, multi-regulatory deployments operate without writing custom enforcement code for every regional combination. The protocol carries the boundaries. The infrastructure honors them.

The shape this gives governance

Step back and look at what becomes possible when these primitives are stable across implementations.

Cross-organization auditability becomes routine. Two agents from two different companies operating under two different governance regimes can interact with full attribution carried natively in the protocol. The receiving company's audit trail is compatible with the sending company's audit trail because both are AGTP Attribution-Records. Compliance reconciliation stops being a custom integration.

Regulatory verification becomes self-service. A regulator with read access to the transparency logs and the registry can verify policy adherence without depending on each operator to produce custom reports. The data is structured, signed, and replayable. The regulator builds tools once and uses them everywhere.

Policy evolution becomes tractable. When the rules change (and they will), the existing logs remain interpretable because the schema is stable. Governance frameworks that wrote their enforcement into application code have a harder time adapting, because every framework's interpretation of the old rules has to be migrated to the new rules separately.

Insurance, contracts, and dispute resolution become serviceable. A counterparty selling agent-mediated services to another counterparty can produce verifiable evidence of policy adherence at the moment of every transaction. Insurers can underwrite agent operations based on observable, signed behavior rather than on attestation. Contracts can specify governance properties that the protocol actually carries, rather than properties that depend on each party's framework happening to capture them.

These are infrastructure consequences. They are what governance gets when its primitives become protocol primitives.

The choice

Most of the AI governance work being done right now is good work, and most of it is being built on a foundation that cannot carry it. The frameworks are clear. The policies are sound. The audits are diligent. And underneath all of it, the agents are communicating over a transport that has no idea any of those things exist.

The substrate has to know. That is the lesson SMTP taught email. It is the lesson TLS taught web security. It is the lesson Certificate Transparency taught trust. The policies above can only be as good as the wire below.

AGTP is the wire that agent governance has been waiting for. Identity, authority, audit, and boundaries carried as protocol properties. Enforcement at line rate. Compliance as a first-class output. Cross-organization interoperability as a default rather than a bilateral negotiation.

Governance becomes infrastructure when the protocol carries it. The protocol exists. The work now is recognizing that the right place to enforce policy is the same place the policy is communicated, and building from there.

Start using AGTP today: https://github.com/nomoticai/agtp

AGTP: A Transport Protocol Built for Agents

Chris Hood — Sat, 30 May 2026 22:41:36 +0000

If you have spent the last year wiring an AI agent into anything, you already know the shape of the problem. Your agent does interesting things, and the protocol carrying its traffic does HTTP. The agent reasons about user goals, negotiates with other services, runs across sessions, takes actions on behalf of someone, and asks for permission to do things. The wire underneath sees a sequence of POSTs.

The Agent Transfer Protocol, AGTP, is a transport protocol designed for what agents actually do. It runs on its own port (4480, registered with IANA), uses TLS for confidentiality and authentication, and is being developed as an open standard at the IETF. The intent is the same intent SMTP had for email and DNS had for hosts: define a substrate that makes the job easier above it, and let the ecosystem build on top.

This post is a developer-level tour. Here is what AGTP does, what you get from using it, and how it fits with what you have already built.

Identity that lives on the wire

Every non-anonymous AGTP request carries a handful of mandatory headers, and they answer the questions intermediaries actually need to answer.

Agent-ID is a 256-bit cryptographic identifier derived from the agent's signed origin document (the Agent Genesis). It is stable across hosts, sessions, and credentials. It identifies the agent itself, separate from the user who launched it or the domain serving the traffic.

Owner-ID identifies the principal accountable for the agent. A registered org, a legal entity, the human who has to answer when something goes wrong.

Authority-Scope is a comma-separated declaration of what the agent is asking to do on this request, in domain:action form. Servers enforce it. Gateways can read it. Audit systems can verify it.

Request-ID, Server-ID, Task-ID, Session-ID round out the correlation surface, so every request can be traced and every response can be matched back to its origin.

Here is what one looks like on the wire:

AGTP/1.0 BOOK /reservation
Agent-ID: a3f8b91e7c2d4a6f8e1c5b9d3a2f7e4c8b6d1a5f9e3c7b2d6a4f8e1c5b9d3a2f
Owner-ID: org:acme-travel-corp
Authority-Scope: booking, payment:up-to-2500usd
Session-ID: sess-trip-2026-04
Task-ID: task-0107
Request-ID: 01HQ7K3M8X9YBNCD2EVZ5F1WGT
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
Content-Type: application/agtp+json

{
  "task_id": "task-0107",
  "parameters": {
    "resource_id": "flight-AA2847",
    "time_slot": "2026-04-15T08:00:00Z",
    "options": {"seat_preference": "aisle"}
  }
}

This is the part that changes what you can build. With HTTP, agent identity lives wherever your framework decided to put it, usually inside a JSON body the transport has no opinion about. With AGTP, the wire itself participates. Logger, gateway, scope-enforcement point, audit pipeline, all of them can read identity directly without parsing your payload.

OAuth and OIDC still ride on top. The standard Authorization: Bearer header works exactly as it does today, visible at the bottom of the request above. AGTP adds an identity layer underneath. The two questions, "what is calling" and "who authorized it," get separate answers in separate places. Both are carried on the same request.

Methods that mean what they say

AGTP has a small set of methods named after what agents actually do: QUERY, BOOK, DELEGATE, PROPOSE, DISCOVER, EXECUTE, DESCRIBE, SUSPEND, and a few more. There is also an IANA registry where additional semantic verbs get registered with documented semantics.

This is partly empirical. A 7,200-trial benchmark we published earlier this year showed that frontier models pick the right endpoint 10 to 29 percentage points more often when method names are intent-aligned versus CRUD verbs. The signal is in the name itself, dense enough to survive even bad documentation. The catch: the effect is absent below roughly 3B parameters. Semantic naming is a frontier-scale benefit.

PROPOSE deserves a special mention because it is the negotiation primitive. The architectural model is called RCNS, Runtime Contract Negotiation Substrate. Contracts come into existence at the moment of need rather than being frozen in an OpenAPI spec.

The negotiation looks like this on the wire:

AGTP/1.0 PROPOSE /audit
Agent-ID: a3f8b91e...c40f2d7a
Owner-ID: org:acme-finance
Authority-Scope: audit:request, payment:up-to-5000usd
Task-ID: task-0042
Content-Type: application/agtp+json

{
  "intent": "Audit a Solidity smart contract for reentrancy and overflow",
  "constraints": {
    "deadline": "PT48H",
    "budget_max_usd": 5000
  }
}

The server evaluates and responds with one of four terminal status codes:

AGTP/1.0 463 Proposal Rejected
Task-ID: task-0042
Content-Type: application/agtp+json

{
  "reason": "composition-impossible",
  "detail": "48-hour SLA unavailable at requested price",
  "counter_proposal": {
    "deadline": "PT72H",
    "budget_max_usd": 5000
  }
}

The buyer's agent refines, resubmits, and receives:

AGTP/1.0 263 Proposal Approved
Task-ID: task-0042
Content-Type: application/agtp+json

{
  "synthesis_id": "syn-7f3a9c1d",
  "endpoint": {
    "method": "EXECUTE",
    "path": "/audit/synthesized/syn-7f3a9c1d",
    "parameters": ["contract_address", "callback_uri"]
  },
  "expires_at": "2026-04-17T08:00:00Z"
}

The other two response codes are 261 Negotiation In Progress (async evaluation, poll the proposal_id) and 262 Authorization Required (the response body tells you which credential to fix). The negotiation grammar lives on the wire, which means logs, audit systems, and intermediaries can read it without parsing per-framework JSON conventions.

Discovery without bilateral integration

The Agent Name Service, ANS, is AGTP's DNS-equivalent. An AGTP-aware queryable registry of agents and their capabilities. You issue DISCOVER with a capability description, the ANS returns a signed, ranked list of Agent Manifest Documents, and you pick one and proceed.

AGTP/1.0 DISCOVER /agents
Agent-ID: a3f8b91e...c40f2d7a
Authority-Scope: discovery:query
Task-ID: task-disc-001
Content-Type: application/agtp+json

{
  "intent": "audit Solidity smart contracts",
  "capability_domains": ["audit", "code:analyze"],
  "min_trust_tier": 1,
  "limit": 5
}

The ANS server returns a signed result set:

AGTP/1.0 200 OK
Content-Type: application/agtp+json

{
  "query_id": "qry-7f3a9c",
  "total_matches": 23,
  "results": [
    {
      "rank": 1,
      "canonical_id": "7c2f9a3e1b8d4f6a...",
      "manifest_uri": "agtp://agtp.auditor.tld/agents/contract-auditor",
      "trust_tier": 1,
      "behavioral_trust_score": 0.97,
      "capability_match_score": 0.94,
      "required_scope": "audit:read, code:analyze"
    }
  ],
  "ans_signature": {
    "algorithm": "ES256",
    "key_id": "ans-key-public-01",
    "value": "[base64-encoded-signature]"
  }
}

Results are ranked by trust tier, behavioral trust score, and capability match, with documented weights. Every response is signed by the ANS governance key, and your agent verifies the signature before trusting any result. ANS servers federate, so an agent in one organization can find agents in another organization without prior knowledge of either. Revoked agents drop from the index within sixty seconds.

This is what turns wire identity into infrastructure. A standardized Agent-ID that no one can look up is a local convention. A standardized Agent-ID that resolves through ANS is an ecosystem.

Transparency built in

Every consequential AGTP interaction can produce an Attribution-Record, a signed envelope binding the responding agent's identity, the request hash, and the response status into something replayable. Attribution-Records are designed to be written to append-only transparency logs aligned with RFC 9162 and RFC 9943 (SCITT).

{
  "agent_id": "a3f8b91e...c40f2d7a",
  "owner_id": "org:acme-travel-corp",
  "acting_principal_id": "user:chris.hood",
  "request_hash": "sha256:e1c5b9d3a2f7e4c8b6d1a5f9e3c7b2d6...",
  "response_status": 200,
  "timestamp": "2026-04-15T08:23:11Z",
  "previous_audit_id": "audit-2026-04-15-08-22-58",
  "signature": {
    "algorithm": "ES256",
    "key_id": "agent-cert-a3f8b91e",
    "value": "[base64-encoded-signature]"
  }
}

Under composition with OAuth, the Attribution-Record carries an acting_principal_id, the validated claim lifted from the bearer token. Three identifiers flow into the audit trail: what acted (Agent-ID), who is responsible (Owner-ID), who authorized (acting principal). The bearer token itself stays out of the record. Only the validated claim persists.

What this looks like in your code

If you are already running agents over HTTP, AGTP is additive. The wire format stays JSON. TLS works the way it always has. Your existing application logic for OAuth, scope enforcement, and business rules keeps doing its job.

The Python reference implementation lets you issue an AGTP request in a few lines:

from agtp import AgentClient

client = AgentClient(
    agent_id="a3f8b91e...c40f2d7a",
    owner_id="org:acme-travel-corp",
    cert_path="./agent-cert.pem",
)

response = client.request(
    method="BOOK",
    target="agtp://agtp.travel.tld/reservation",
    authority_scope=["booking", "payment:up-to-2500usd"],
    body={"resource_id": "flight-AA2847",
          "time_slot": "2026-04-15T08:00:00Z"},
    bearer_token=user_oauth_token,  # composes alongside, untouched by AGTP
)

if response.status == 200:
    booking = response.body["result"]
    audit_id = response.attribution["audit_id"]

Server-side dispatch follows the same shape, with the canonical Agent-ID, Authority-Scope, and Owner-ID available on the request context before your handler runs:

from agtp import AgentServer

server = AgentServer(agent_id="...", cert_path="./server-cert.pem")

@server.method("BOOK", path="/reservation")
def book(request):
    # Wire-level identity is already validated by the AGTP layer.
    if "booking" in request.authority_scope:
        result = process_booking(request.body, request.acting_principal_id)
        return server.respond(200, result=result)
    return server.respond(455, reason="scope-violation")

server.listen(port=4480)

An MCP-on-AGTP gateway already runs the unmodified official MCP server behind an AGTP wire, demonstrating that MCP, A2A, ACP, and other agent messaging protocols can ride on AGTP as substrate without changes to the messaging layer.

Where to look

Specs are at github.com/nomoticai/agtp, with the core draft at agtp.io and companion drafts for trust, identifiers, logging, identity certificates, discovery, composition, and session. A live registry runs at registry.agtp.io. Port 4480 is reserved for both TCP and QUIC.

The work is open. Implementations are welcome. The faster we surface real deployments, the faster the spec hardens into something the agent economy can rely on. If you are building anything where agent traffic matters, this is the right time to try it.