Agent Gateway: A new era of governed AI agents interactions. Agent Gateway introduces new capabilities that enable trusted, governed, and accountable AI agent interactions across connected ecosystems. Anja Obradovic & Michael Yih - July 24, 2026 Today, Affinidi is introducing a major upgrade to Agent Gateway that helps organisations establish trust, enforce governance, and maintain accountability across increasingly connected agent ecosystems. Already used by organisations to govern interactions between AI agents, users, services, and external systems, Agent Gateway now introduces new capabilities that make governance more visible, interoperable, and operationally scalable. Built around open standards, these enhancements enable teams to embed trust and policy controls directly into the flow of agent interactions, helping them move from experimentation to production with greater confidence. This upgrade introduces Agent Surfaces, a visual governance framework for managing agent interactions, alongside new operational capabilities that improve interoperability, observability, and accountability. A new way to govern agent interactions. At the core of this upgrade is Agent Surfaces. Agent Surfaces provide a workflow-based approach to configuring and governing how requests move between agents and the systems they interact with. Supporting both Agent-to-Agent (A2A) and Model Context Protocol (MCP) interactions, Agent Surfaces allow organisations to define governance controls at critical decision points throughout the lifecycle of an agent request and response. Rather than building governance logic into every individual application or service, organisations can define controls once and apply them consistently across agent interactions. Three capabilities introduced in this upgrade form the foundation for governed agent interactions. Caller Context & Credential Delegation: preserving identity across agent interactions. Agent interactions often involve multiple parties. An agent may be acting on behalf of a user, another application, or even another agent. Before policy decisions can be made, systems need to understand who initiated the request. The new Caller Context capability captures and preserves authentication and identity context from inbound requests before governance controls are evaluated. This enables the original caller's identity to travel with the request, allowing agents to inherit and present the context of the human on whose behalf they are acting. In Gateway-to-Gateway interactions, this portable identity helps downstream services and organisations make decisions based on the original caller, rather than only the immediate requesting agent or system. Building on this identity context, Credential Delegation enables credentials received through source authentication to be securely propagated to downstream services. This allows agents to act on behalf of users while maintaining governance controls, accountability, and visibility into how delegated authority is exercised across systems. The capability also includes support for masking personally identifiable information where appropriate, helping organisations balance usability with privacy requirements. Together, Caller Context and Credential Delegation create a more secure and transparent model for agent-driven interactions. By preserving identity and delegated authority throughout the interaction flow, organisations gain better visibility, stronger accountability, and greater trust across agent-driven processes, even when interactions span multiple gateways, systems, and organisational boundaries. Trust Registry: establishing trust before interaction. As agent ecosystems expand across organisations, platforms, and partners, trust can no longer be assumed. The new Trust Registry capability enables Agent Gateway to verify whether an individual, partner, application, or agent has been authorised to perform a specific action on a particular resource before a request is allowed to proceed. Rather than relying solely on static integrations or pre-configured allowlists, organisations can make decisions using verifiable trust and authorisation records. This provides a trusted way to answer questions such as: * Has Company A authorised Agent B to perform Action X on Resource Y? * Does Company X recognise Agent B as having the authority to approve or authorise Action X on Resource Y? By making authorisation and delegation verifiable across organisational boundaries, Trust Registry helps organisations reduce fraud, strengthen inter-organisational trust, improve auditability, and enable secure partner ecosystems where delegated authorities can be recognised and trusted with confidence. Auditability by design. As AI agents take on more responsibility, organisations need more than operational monitoring. They need verifiable record of how decisions were made, what policies were enforced, and who was authorised to act. The Audit capabilities in Agent Gateway provide end-to-end traceability across agent interactions, governance controls, delegated credentials, and trust verification processes. Audit records allow teams to demonstrate which policies allowed or denied a request, investigate which credentials were used and when, and trace how identity, authorisation, and governance decisions flowed through the system. By correlating audit events through shared trace IDs, organisations can connect interactions across gateways, services, and external systems. This supports compliance audits, security investigations, policy debugging, credential lifecycle tracking, and Trust Registry verification, while providing a stronger foundation for accountability through verifiable and tamper-evident records. Start building governed agent interactions. Ready to explore what's new in Agent Gateway? Log in to the Affinidi Portal to discover the latest capabilities, experiment with Agent Surfaces, and start building trusted and governed agent experiences today.

Significant donations from did:webvh community. Juan Caballero, Community Manager at Decentralized Identity Foundation Stephen Curran, Principal at Cloud Compass Computing Inc. The did:webvh work item in the Identifiers & Discovery WG is a quiet but steadily progressing item within DIF, addressing the essential work driving wider adoption of DIDs. If you've been following over the last year via Slack, PRs, and agendas, you know there has been steady progress and disciplined ongoing design at higher layers, working on different witnessing systems and federation/registry mechanics. One of the key improvements is on the core "Verifiable Data Registry," that is, the web server that hosts and manages webvh DIDs. The Verifiable Data Registry is a formidable HTTP server that has been re-implemented in multiple languages and cross-tested rigorously. The server now incorporates sophisticated cryptography, queueing and load-balancing, and support for complex endpoints. Not since did:ion (a project led by DIF's original executive director and adopted by Microsoft!) have this many independent implementations been donated and cross-tested. This degree of community activity is a testament to how did:webvh has attracted attention and is being used in diverse deployments. DID:webvh approaching "every major language" territory. As Identity Hubs reported last year, at the time of the v1.0 specification finalization, the three donated implementations were in Python, Typescript and Rust. This third implementation, relatively recent at the time of v1.0 feature freeze and testing blitz, was driven by long-time DIF Member Affinidi, a startup that both develops software and deploys it at such a scale as to stretch its mental model of a "startup". Affinidi is a long-term contributor to DIF, having also contributed a mature implementation of another DIF-incubated DID method and contributed to Verifiable Credential tooling. Based on the need for wide-scale adoption, Affinidi has added a Java implementation which will be DIF-maintained on Java's package manager, Maven. Depending on your feelings about Go, the backend-language Google invented to power its own microservices and cloud, one might even say did:webvh is already available (or reasonably wrappable/ABI-able) in every major language that developers might need to architect did:webvh into their production deployments. The personal twist: webvh-dart. As if all this weren't impressive enough, Affinidi's Reza Maghoul, the main developer of the Java implementation, also made a hobby/weekend project implementing it in parallel in a branch of the Java family tree called Dart. Independent from Affinidi's production usecases for the didwebvh Java server, Reza is also donating the Dart variant, rounding out the portfolio interestingly. Dart is best known as the ergonomic and idiomatic language powering "Flutter", a mobile application framework and packaging tool that can package both iOS and Android applications from a single Dart codebase. Dart has also found a strong following for being far easier and more fun to code with than Java or C#. In fact, without much fanfare, server-side Dart tooling has matured considerably in recent years, following the precedents of TypeScript and JavaScript frameworks that make it easier for individual or casual developers (and their agents) to code front- and back-end idiomatically in a shared language. The Dart implementation makes did:webvh accessible to additional developers. But what about interop? With 5 DID:webvh implementations available and another outside of DIF, how does the community make sure all the implementations are interoperable? A test suite is the obvious answer. The did:webvh test suite includes some interesting AI-driven contributions. The DIF did:webvh-test-suite repository contains a canonical set of DID creation and update tests (based on YAML steps in a simple Domain Specific Language) and a driver for every known implementation to run the tests. Each test run for a given implementation: * Generates all of the test DIDs, creating DID Log and resolution result test vectors, * Runs a set of "negative" tests with DIDs constructed to NOT follow the spec (more below), and * Resolves all of the Test DIDs from all of the implementations. The Test Suite produces Pass/Fail results for all six implementations interoperability .The tests run nicely in Docker, so they can be run against every PR of every implementation to prevent regressions. On top of the functioning Test Suite, Anthropic's Project Glasswing and Mythos made the test suite even more valuable. Through Affinidi's involvement in using did:webvh with the Linux Kernel Group to verify that PRs to the kernel are from real, known contributors, Affinidi was given early access to Anthropic's Mythos LLM to hunt for vulnerabilities in the Rust did:webvh implementation. The bad news was that vulnerabilities were found - in fact there 40 across all of the DIF implementations. The good news: * All vulnerabilities have been fixed across all implementations. * Negative test cases have been added to the didwebvh-test-suite to make sure they don't resurface. * An update to the specification was generated, revised and applied - that didn't change any of the specification's normative behaviors, but expressed them more unambiguously for future implementers. That last point was quite interesting. The vulnerabilities weren't in the definition of the specification, but in implementing the spec as it was written. The ability to rapidly improve the implementations was a major boost for the did:webvh community! To get involved in the did:webvh community: * Check out the information site: https://didwebvh.info * Use one of the did:webvh implementations to power your DID use cases, and integrate regression testing with the official test suite if you fork one. * Join the biweekly meetings, Thursday at 9:00 Pacific / 18:00 Central Europe, Agenda and Zoom info and help Identity Hubs to continue to evolve the did:webvh. Roadmap items: * did:webvh DIDs without a web address. * PQC support in did:webvh. * Extract the "vh" from did:webvh for use in other areas. * Request your did:webvh implementation or deployment/use case be added to the list. * Request your implementation be added to the did:webvh Test Suite. To get involved in the Identifiers & Discovery Working Group at DIF