Episode 153 - GluuFederation/identerati-office-hours GitHub Wiki
Title: AI Agent Trust via Decentralized Machine Identity
- Host: Mike Schwartz, Founder/CEO Gluu
- Guest: Nicola Gallo, Co-founder / CTO Nitro Agility
Channels
Description
True AI agent trust comes from binding actions to verifiable agent identities, enabling attested, decentralized execution rather than fragile token-passing models. Join us for a deep authz discussion with one of the lead contributors of the PermGuard open source authorization solution.
Lately there has been a lot of discussion about the “trust” of AI agents. At a high level, the real challenge is that integration and security are often conflated. MCP essentially addresses integration—an orchestration layer—but it does not solve the problem of trust. The first step is to clearly separate security from integration and coordination.
When implementing integration, orchestration can work, but it may introduce a single point of failure. Even with redundancy, state and tokens still need to be persisted, and if every AI agent in every security domain handles this in the same way, we risk drifting toward an “Internet of Shared Credentials.” An alternative is choreography, where coordination is distributed and transactions can be built across peers.
Take the simplest distributed transaction: two workers exchanging a single message. Passing a token in the message may look simpler, but it is really just a compromise: it avoids a central orchestrator yet still leaves weak guarantees—tokens can be replayed, lost, or detached from the actual executor. A more sustainable path is to anchor trust in the verifiable identities of the executors themselves, enabling decentralized chains of attested actions. Without this, impersonation models that lack strong binding to executor identity risk leaving the true actor unclear, making trust fragile and harder to govern.
Homework
- Nicola's Linkedin Post
- Building AI Trust at Scale: Authorising Autonomous Agents at Scale by Misha Deville
- https://lists.identity.foundation/g/taawg/topic/use_case_booking_a_flight/115356400
Takeaways
-
⚡ DIDs might make better identifiers then URIs for agents. DIDs give you built-in discovery--e.g. you can resolve a DID to a DID document by implementing the DID method. But I was hoping to hear more about how to connect the dots. What claims would the DID document contain? Would the DID document also contain public keys? Which DID method is best for agentic identity?
-
⚡ There are a lot of ways to use OAuth incorrectly that will result in bad things happening. OAuth has 33 RFCs and at least half a dozen active drafts, so the categorization of "OAuth" is not precise, and makes it hard to understand what part of OAuth is problematic for what use case.
-
⚡ Attestations accumulate from the hardware, operating system, network, domain federation, application and data layers. At some point, an agent (or infrastructure workload) needs to trade these assertions to obtain (or self-assert) some kind of globally unique identifier (which is needed to correlate the agent's activity). That could be a URI, DID, public key fingerprint, guid or anything else. But for authorization purposes, what generally matters more then identifier are the claims associated with that identifier.
-
⚡ If they are short lived (e.g. one minute), cryptographically bound to a client, exchanged for transactionally scoped purposes, and checked for revocation for high value transactions.... are OAuth tokens actually static?
-
⚡ Zero Trust Networking--of course we want that. But Zero Trust is more challenging at the edges than in the middle (i.e. the network). Specifically, zero trust networking doesn't help you in the application layer or database layer--and that's where AI is pushing the boundaries of authorized access.