PaperlayerView exact revision on arXiv

Source-linked AI summary

A Novel Zero-Trust Identity Framework for Agentic AI: Decentralized Authentication and Fine-Grained Access Control

Ken Huang, Vineeth Sai Narajala, John Yeoh, Jason Ross, Ramesh Raskar, Youssef Harkati, Jerry Huang, Idan Habler, Chris Hughes

arXiv:2505.19301v2cs.CRcs.AIcs.MA

TL;DR

Traditional IAM protocols are a poor fit for autonomous, ephemeral, interacting agents, whose identities and permissions must account for changing capabilities and delegated actions. The paper proposes an Agentic AI IAM framework built around DIDs, VCs, discovery, dynamic access control, and global session enforcement. Its supported contribution is an architecture and operational lifecycle for managing agent identity and access; governance remains a substantial challenge.

  • Problem

    Traditional IAM protocols’ coarse permissions, single-entity assumptions, and limited contextual adaptability do not fit the dynamic, interacting agents of MAS.

    Source: §I · pp. 1–2, 2) Fundamental Insufficiencies for… · p. 3

  • Method

    The paper proposes a layered framework using rich Agent IDs based on DIDs and VCs, capability-aware discovery, dynamic access control, and global session management and policy enforcement.

    Source: §I · p. 2

  • Results

    The paper presents an Agentic AI IAM architecture and lifecycle covering identity creation and attestation through runtime authorization, logging, monitoring, and incident response.

    Source: §I · p. 2

  • Takeaways & Limitations

    The proposed framework is intended to establish trust, accountability, and security for agentic AI systems and their complex ecosystems.

    Source: §I · p. 2

    Governance of a global, decentralized, or federated IAM infrastructure remains a monumental task amid unresolved questions of credential authority, DID or ANS disputes, liability, and evolving regulation.

    Source: C. Governance Models, Trust… · p. 23

Abstract

from arXiv · show

Traditional Identity and Access Management (IAM) systems, primarily designed for human users or static machine identities via protocols such as OAuth, OpenID Connect (OIDC), and SAML, prove fundamentally inadequate for the dynamic, interdependent, and often ephemeral nature of AI agents operating at scale within Multi Agent Systems (MAS), a computational system composed of multiple interacting intelligent agents that work collectively. This paper posits the imperative for a novel Agentic AI IAM framework: We deconstruct the limitations of existing protocols when applied to MAS, illustrating with concrete examples why their coarse-grained controls, single-entity focus, and lack of context-awareness falter. We then propose a comprehensive framework built upon rich, verifiable Agent Identities (IDs), leveraging Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs), that encapsulate an agents capabilities, provenance, behavioral scope, and security posture. Our framework includes an Agent Naming Service (ANS) for secure and capability-aware discovery, dynamic fine-grained access control mechanisms, and critically, a unified global session management and policy enforcement layer for real-time control and consistent revocation across heterogeneous agent communication protocols. We also explore how Zero-Knowledge Proofs (ZKPs) enable privacy-preserving attribute disclosure and verifiable policy compliance. We outline the architecture, operational lifecycle, innovative contributions, and security considerations of this new IAM paradigm, aiming to establish the foundational trust, accountability, and security necessary for the burgeoning field of agentic AI and the complex ecosystems they will inhabit.

I. INTRODUCTION

The paper argues that human- and static-machine-oriented IAM mismatches the autonomy, ephemerality, evolving capabilities, and delegation of agents in multi-agent systems. It proposes a purpose-built framework and explains where traditional protocols remain useful and where their assumptions fail.

I. INTRODUCTION

  • The framework combines rich agent identities, DIDs and VCs, an Agent Naming and Discovery Service, dynamic access control, and unified global session management and policy enforcement.It also covers the IAM lifecycle and compares centralized, decentralized, and federated deployments while analyzing security considerations.Source: §I · p. 2

1) Lingering Utility for Constrained Scenarios:

  • Traditional OAuth, OIDC, and SAML remain useful for human access to platforms and constrained single-agent interactions, but their assumptions break down in autonomous MAS.They can also bootstrap initial agent context through human-derived attributes and permissions.Source: 1) Lingering Utility for Constrained… · pp. 2–3, §II · p. 2

2) Fundamental Insufficiencies for Multi-Agent Systems (MAS):

  • OAuth and SAML scopes or roles can be too broad and static for task-specific permissions that change with an agent’s context and mission.The disaster-response example shows how multiple agents need changing, granular permissions; broad scopes risk overprivileging, while re-authenticating for each permission change is untenable.Source: 2) Fundamental Insufficiencies for… · p. 3
  • Single-principal protocols struggle to represent auditable, fine-grained authority across delegation chains, blurring accountability when agents spawn sub-agents.The paper illustrates the problem with an agent delegating financial-planning tasks to market-analysis and tax-optimization agents.Source: 2) Fundamental Insufficiencies for… · p. 3
  • Traditional IAM relies largely on static scopes or roles, with limited awareness of runtime context, intent, or risk as circumstances change.The paper’s inventory example contrasts routine stock updates with recalled products or anomalous zeroing of inventory.Source: 2) Fundamental Insufficiencies for… · p. 3
  • MAS also strain traditional identity operations through secret sprawl, fragmented revocation, token-management volume, and absent native peer-to-peer trust across domains.The examples include many service credentials per agent, lingering sessions after compromise, and thousands of short-lived agents.Source: 2) Fundamental Insufficiencies for… · pp. 3–4

B. Unique Challenges Posed by Agentic AI in MAS Further Exacerbating IAM Deficiencies

  • Agent autonomy, ephemeral lifecycles, evolving capabilities, provenance needs, privilege-escalation risks, and cross-agent collaboration compound IAM’s limitations.Actions may also no longer map directly to human requests, complicating the attribution of agent decisions.Source: B. Unique Challenges Posed by Agentic… · p. 4

III. DEFINING THE AGENT IDENTITY (AGENT ID) FOR A NEW ERA

The paper defines an Agent ID as a verifiable digital representation of an agent’s origin, purpose, capabilities, behavior, relationships, and attestations. It proposes DIDs and VCs as foundations for representing agents and their runtime instances, with agent or controller ownership.

III. DEFINING THE AGENT IDENTITY (AGENT ID) FOR A NEW ERA

  • An Agent ID is a rich, verifiable, dynamic, cryptographically secured profile that supports trust, access control, and accountability.It represents origin, purpose, capabilities, behavior, relationships, and attestations rather than merely labeling an agent.Source: §III · p. 4, A. What Constitutes an AI Agent’s… · p. 4

A. What Constitutes an AI Agent’s Identity? Beyond Static Identifiers

  • An agent instance is a runtime instantiation of its software and model combined with unique state, memory, and interaction history at a given time.Agent IDs should distinguish cloned or ephemeral agents and support verification of claims, enabling traceability and attribution.Source: A. What Constitutes an AI Agent’s… · p. 4, Table I · p. 5

B. Essential Components of an Agent ID

  • The proposed Agent ID uses a DID as its root identifier and VCs to carry verifiable claims about an agent.DIDs are described as globally unique, persistent, and resolvable; linked key pairs support signing actions, encryption, and authentication.Source: B. Essential Components of an Agent ID · p. 5

C. Agent ID Ownership and Control

  • Self-sovereign identity places DID private-key and VC management with the agent or its designated controller, decoupling identity from a single centralized provider.The paper says this moves away from centrally managed identities and gives the agent or controller greater control and portability.Source: C. Agent ID Ownership and Control · pp. 5–6

D. ID Generation, Assignment, and Lifecycle Management: From Birth to Revocation

The proposed framework combines cryptographic identity and credentials with discovery, dynamic authorization, and cross-protocol session enforcement. It describes agent identity issuance, runtime adaptation, and revocation as parts of the identity lifecycle.

D. ID Generation, Assignment, and Lifecycle Management: From Birth to Revocation

  • Agent IDs may be platform-issued or self-issued, then adapted at runtime through temporary role- or task-specific credentials or derived short-lived DIDs.The described runtime flow requests an identity or credential, verifies the primary DID and policies, issues a scoped or time-bound credential, then revokes it or lets it expire.Source: D. ID Generation, Assignment, and… · p. 6
  • Identity updates include changing DID Documents when capabilities or keys change and revoking invalid credentials or deactivating a DID when an agent is decommissioned.The paper identifies VC Status Lists as one revocation mechanism.Source: D. ID Generation, Assignment, and… · p. 6

A. Foundational Pillars

  • DIDs and VCs support self-sovereign identity and signed attestations, while ZKPs enable proof of attributes or policy compliance without revealing underlying information.The paper presents these as foundational pillars for decentralized, cross-organizational agent interactions and privacy-preserving disclosure.Source: A. Foundational Pillars · p. 6
  • The Agent Naming and Discovery Service enables secure discovery by capability, protocol, provider, and version, resolving agent names to DIDs.Its proposed naming structure can include protocol, agent function, capability domain, provider, and version.Source: A. Foundational Pillars · p. 6

B. Core Architectural Layers

  • The architecture separates identity and credential lifecycle management, agent discovery and trust establishment, dynamic access control, and unified session enforcement.The access-control layer evaluates agent identity, resource attributes, action, and context, and can use ABAC, PBAC, and just-in-time access with temporary scoped VCs.Source: B. Core Architectural Layers · pp. 6–7
  • A unified global session and policy enforcement layer supports real-time session establishment, tracking, management, and policy enforcement across heterogeneous agent protocols.The layer includes global logout and session invalidation.Source: B. Core Architectural Layers · p. 7

C. Applying Zero Trust Principles

This section applies Zero Trust principles to agent identities and access decisions through capability-aware discovery, dynamic fine-grained authorization, and secure agent-to-agent communication. Its examples cover narrow, time-limited credentials, verifiable message context, and enforcement across heterogeneous agents and protocols.

C. Applying Zero Trust Principles

  • Zero Trust requires explicit identity and authorization checks, least-privilege access, rapid revocation, micro-segmentation, and policies tied to data sensitivity and agent capabilities.The framework proposes just-in-time verifiable credentials (JIT VCs) as one way to grant minimum necessary permissions.Source: C. Applying Zero Trust Principles · p. 7

V. AGENT IDS IN THE IAM PROCESS

  • The Agent Name Service (ANS) supports secure, capability-aware agent discovery and enables fine-grained access control, non-repudiable logging, real-time monitoring, anomaly detection, and targeted incident response.The section describes patterns involving A2A and MCP,, [40] in multi-agent systems.Source: §V · p. 7

A. Fine-Grained Access Control in Action

  • Dynamic access control in multi-agent systems combines attribute-based, policy-driven decisions with ANS discovery, then re-verifies discovered claims during authorization.The DID links the entity discovered through ANS to the entity being authorized.Source: A. Fine-Grained Access Control in Action · p. 7, §2 · p. 10
  • Access decisions can check an agent’s role, capability, and compliance credentials against resource sensitivity, requested action, declared toolset, and request context.The example evaluates a request for a high-sensitivity sales database using credentials and contextual attributes.Source: §2 · p. 9
  • For temporary tool access, ANS can locate an available tool instance, after which a JIT VC scopes the ephemeral agent’s permitted tool, action, and validity period.The example presents the credential in an MCP tool call.Source: §2 · p. 10
  • For MCP tools, ANS identifies the appropriate instance while a JIT VC grants narrow, time-bound permission for a specific job and data, reducing risk from broader, longer-lived credentials.Source: §2 · p. 11
  • In A2A alerting, policy checks the sender’s valid credential and source scope, while message signatures support integrity and non-repudiation, providing stronger guarantees than IP whitelisting or pre-shared API keys [43].Source: §2 · p. 12
  • ANS discovery followed by DID-based authentication and VC-based authorization at interaction provides a robust sequence for fine-grained access control across diverse MAS scenarios.Source: §2 · p. 12
  • The four-phase lifecycle combines ANS discovery, dynamic attribute-based authorization using agent and resource context, JIT credentials for ephemeral MCP agents, and signed A2A messages with verifiable authorization presentations.Source: §2 · p. 12

B. Secure Logging, Auditing, and Non-Repudiation

The framework treats logging as an accountability mechanism: DIDs identify agents, ANSNames add interpretable context, and VCs record authorization. Signed messages and privacy-preserving proofs support non-repudiation and audits across agent workflows.

Non-repudiation

  • The A2A communication example uses signed messages with verifiable presentations to prove authorization for specific message types and support real-time security alerts.The caption identifies Google’s A2A protocol as the setting for critical security alerts.Source: Figure 5 · p. 13

Enriched audit logs

  • DID-anchored, VC-enriched logs pair persistent agent identities with human-readable ANSNames and the authorization context for each action, making audits more precise.The paper says the DID provides a cryptographic link to the agent, while the ANSName makes logs more interpretable to human auditors.Source: B. Secure Logging, Auditing, and… · pp. 12–13

Non-repudiation

  • DID-keyed signatures on critical agent actions or their outputs provide non-repudiation, while the A2A example verifies signed order payloads against the sender’s resolved DID key.The supplier’s log can include the sender and receiver identities, order ID, payload hash, and signature object.Source: B. Secure Logging, Auditing, and… · pp. 13–14

Verifiable provenance

  • A chained MCP trace links the user prompt, agent decisions, tool calls and results, and final answer to support audits of errors and accountability.The paper says this lets investigators trace whether an incorrect answer arose from the LLM, tool execution, accessed data, or ANS discovery.Source: B. Secure Logging, Auditing, and… · pp. 14–15

Privacy-preserving audits

  • A ZKP can establish that allowed PII Strict requests met credential and network conditions without disclosing individual access events or raw logs to auditors.The example’s proof concerns valid, non-revoked credentials from approved issuers and an approved source network.Source: B. Secure Logging, Auditing, and… · p. 15

C. Real-time Monitoring and Anomaly Detection

The framework uses DIDs, ANS profiles, credentials, and interaction context to monitor agent behavior against declared purposes and attested capabilities. Detected deviations can inform trust scores and risk-adaptive access decisions.

Behavioral baselines

  • Monitoring tied to DIDs and ANS profiles can assess whether agent activity aligns with its intended and attested purpose, beyond tracking opaque identifiers or simple resource metrics.The paper proposes behavioral baselines for each DID and associated ANSName profiles.Source: C. Real-time Monitoring and Anomaly… · p. 15
  • Comparing actual behavior with declared scope, authorized tools, and typical collaboration patterns can flag out-of-scope queries, tool use, or communication links as anomalies.Examples include a support agent querying financial-data capabilities and an ETL agent attempting to use an unauthorized external API.Source: C. Real-time Monitoring and Anomaly… · pp. 15–16

Anomaly signals

  • Attempts to exceed VC-attested capabilities, unjustified JIT credential requests, or interactions lacking expected counter-attestations are described as signals for monitoring.The examples include an unauthorized bulk-download request and requests for increasingly broad JIT scopes.Source: C. Real-time Monitoring and Anomaly… · p. 16

Dynamic trust scoring

  • Trust scores can incorporate task performance, policy violations, credential validity, peer feedback, and ANS-related anomalies to inform risk-adaptive enforcement.In the payment example, reduced trust can prompt stricter checks or a lower transaction limit even when the agent presents its usual VCs.Source: C. Real-time Monitoring and Anomaly… · p. 16

D. Agile Incident Response: Precision Targeting, Rapid Containment, and Discoverable Impact

The framework uses verifiable identities, credentials, and ANS context to identify compromised agents, investigate their activity, and target revocation. Its unified session layer propagates termination across active sessions and protocols.

Identification and context

  • Alerts referencing a DID and ANSName can identify the specific agent instance, its declared purpose and owner, and its attested capabilities and dependencies.The example alert identifies a particular backup-agent instance and its association with critical database backups.Source: D. Agile Incident Response: Precision… · p. 16

Targeted revocation

  • Revocation can target one compromised capability VC while leaving an agent’s other credentials usable, or revoke the agent DID if its private keys are stolen.The paper also describes updating or removing the corresponding ANS entry after whole-DID revocation.Source: D. Agile Incident Response: Precision… · pp. 16–17

Global session invalidation

  • The unified session layer propagates a confirmed compromise to the SSS, allowing AEMs to block new requests and terminate active local sessions across A2A, MCP, and ACP/HTTP.The example applies termination to an active MCP tool session as well as A2A messages.Source: D. Agile Incident Response: Precision… · p. 17

Forensic analysis

  • DID-anchored logs, VCs, and ANS context support forensic analysis of an agent’s expected role, dependencies, discovery history, collaborators, and potential incident blast radius.The paper also describes clustering incidents by ANS provider and capability metadata to investigate possible shared attack vectors.Source: D. Agile Incident Response: Precision… · p. 17

E. Other Potential Uses Building on Verifiable Agent IDs and Discoverable ANS Profiles

The paper extends verifiable identities and ANS profiles to potential ecosystem functions beyond core IAM, including reputation, service billing, supply-chain attestations, coalition formation, and ethical governance discovery.

Decentralized reputation

  • Agents can issue task-specific reputation VCs linked to DID identities and ANS capabilities, letting future discoverers consult relevant community feedback when selecting agents.The paper describes storing these credentials with the agent or publishing them to a decentralized reputation ledger.Source: E. Other Potential Uses Building on… · p. 17

Billing and quotas

  • ANS service metadata can expose pricing or rate limits, while providers can log consuming-agent DIDs to enforce quotas and attribute billing to controllers.The example gives a monthly character quota for a translation tool.Source: E. Other Potential Uses Building on… · p. 18

Supply-chain attestations

  • ANS registrations could include model, software-component, and secure-build VCs, allowing discoverers to prioritize agents with verifiable supply-chain attestations.The resolver could return indicators of these attestations or links to the credentials.Source: E. Other Potential Uses Building on… · p. 18

Coalition formation

  • An orchestrator can discover candidate agents through ANS, negotiate their capabilities and availability, then issue a CoalitionCharter VC defining the mission, roles, resources, and duration.The paper suggests negotiation messages over A2A or ACP.Source: E. Other Potential Uses Building on… · p. 18

Ethical governance

  • Agents or users could discover ethical-compliance and bias-reporting services through ANS, with service DIDs and VCs providing verifiable links to those services.The paper describes these services as tools for agent self-assessment or user reporting of problematic behavior.Source: E. Other Potential Uses Building on… · p. 18

Framework extension

VI. DEPLOYMENT MODELS & GOVERNANCE CONSIDERATIONS

The framework is architecturally comprehensive but not a one-size-fits-all implementation; organizational needs, MAS scope, trust requirements, and existing infrastructure shape deployment choices.

VI. DEPLOYMENT MODELS & GOVERNANCE CONSIDERATIONS

  • Deployment of core components such as DID registries, VC issuers, ANS, Policy Engines, Session Authority, and Session State Synchronizer must fit each organization’s needs.The passage identifies organizational and MAS scope, trust requirements, and existing infrastructure as relevant factors.Source: §VI · p. 18
  • The framework is not a monolithic, one-size-fits-all practical implementation.Different deployment models may be needed for its core components.Source: §VI · p. 18
  • Adaptable, well-defined governance is described as paramount to long-term viability, trustworthiness, security, and interoperability.Source: §VI · p. 18

A. Deployment Model Analysis

The paper analyzes three deployment models and describes centralized deployment as placing most core IAM components under one administrative authority.

A. Deployment Model Analysis

  • The analysis assesses centralized, decentralized, and federated deployment models for their characteristics, advantages, disadvantages, and suitability.Source: A. Deployment Model Analysis · p. 18
  • In a centralized deployment, one organization, platform provider, or designated administrator controls all or most core IAM components.These can include the Agent ID registry, VC issuers, ANS, policy decision and administration points, and cross-protocol session components.Source: 1) Centralized Approach · p. 19
  • Agents in the centralized model typically belong to or are tightly managed by the central entity, and trust decisions ultimately flow from it.Source: 1) Centralized Approach · p. 19

1) Centralized Approach:

The supplied passages describe centralized deployment’s advantages, disadvantages, and use cases, alongside a description of decentralized IAM components.

1) Centralized Approach:

  • Centralized deployment offers policy cohesion, unified control and audit, potentially easier enterprise integration, optimized performance, and clear accountability.Source: 1) Centralized Approach · p. 19
  • Centralized deployment carries single-point-of-failure and control risks, scalability bottlenecks, lock-in, limited cross-organizational trust and interoperability, and potential censorship or abuse of power.Source: 1) Centralized Approach · p. 19
  • The centralized model is presented for enterprise-internal MAS, specific AI platforms, early-stage deployments or controlled experiments, and highly regulated settings with a single auditing authority.Source: 1) Centralized Approach · p. 19
  • The described decentralized design uses DLT-registered DIDs, diverse VC issuers, decentralized revocation options, extensive ZKP presentations, and potentially DLT-based ANS and session-state mirroring.Policy enforcement may use smart contracts for on-chain resources or verifiable presentations bundling credentials required by a verifier’s policy.Source: 2) Decentralized Approach · p. 19

2) Decentralized Approach:

The passages contrast decentralized and federated approaches and note that deployments can combine elements of both with centralized components.

2) Decentralized Approach:

  • Decentralized deployment offers agent sovereignty, resilience from a single point of control, and transparency in public DLTs, but incurs governance, security, performance, cost, key-management, privacy, and trust-bootstrapping challenges.Source: 2) Decentralized Approach · p. 19
  • Decentralized deployment is suited to open permissionless ecosystems, cross-organizational collaboration without a central trusted party, and settings prioritizing censorship resistance or user identity control.Source: 2) Decentralized Approach · p. 19

3) Federated Approach:

  • Federated domains retain autonomous IAM while establishing mutual trust and interoperability through cross-certification, shared trust lists, federated ANS resolution, interoperable DID methods, and standardized VC profiles.Source: 3) Federated Approach · p. 19
  • Federation balances autonomy and interoperability, but brings trust-management and technical or semantic interoperability complexity, potential lowest-common-denominator security, discovery challenges, and governance overhead.Source: 3) Federated Approach · p. 19
  • Federated deployment is proposed for industry consortia, institutional alliances, multinational organizations, transitions from siloed systems, and as a practical ANS model.Source: 3) Federated Approach · p. 19

4) Hybrid Approaches:

  • Hybrid deployments may combine centralized internal IAM with federated partner access, anchor VC issuers in decentralized ecosystems, or consortium-operated DLT for global session coordination.Source: 4) Hybrid Approaches · pp. 19–20

B. Decision Matrix for Choosing an Implementation Model

The section presents implementation choice as requirement-driven and pairs the framework with governance processes and MAESTRO-layer threat analysis and mitigations.

B. Decision Matrix for Choosing an Implementation Model

  • Choose a deployment model by identifying the MAS context, prioritizing requirements, comparing models, and considering whether a hybrid approach best balances them.Examples of requirements include agent sovereignty and centralized auditability; a hybrid could combine decentralized DIDs with a federated or centrally managed Session Authority.Source: B. Decision Matrix for Choosing an… · p. 20

C. Governance Considerations; 1) Identity Governance (DIDs, VCs, ANS):

2) Security Policy Governance (for PDPs and SA):

3) Operational and Security Governance for IAM Infrastructure:

4) Data Privacy and Ethical Use Governance:

  • Data privacy and ethical-use governance includes impact assessments, Agent ID data minimization, bias review in credentialing and reputation, and ethical oversight.Source: 4) Data Privacy and Ethical Use… · p. 20

5) Evolution and Standards Governance:

  • Standards governance requires change management and liaison with external standards bodies, while adapting through collaboration among industry, standards developers, and potentially government.Governmental oversight is identified as potentially appropriate for public-facing or critical-infrastructure components.Source: 5) Evolution and Standards Governance · p. 20

VII. SECURITY CONSIDERATIONS; A. The MAESTRO 7-Layer Reference Architecture for Agentic AI; B. Threat Analysis of the Proposed Agentic AI IAM Framework using MAESTRO Layers

B. Threat Analysis of the Proposed Agentic AI IAM Framework using MAESTRO Layers

  • For L5–L7, proposed mitigations include immutable signed logs, instrumentation, masking, privacy-by-design and ZKPs, policy-as-code, HSMs and revocation, secure ANS resolution, and trust diversification.Source: B. Threat Analysis of the Proposed… · pp. 20–21

C. Cross-Layer Threats Affecting the IAM Framework

The framework combines lifecycle-wide agent identity, capability-aware discovery, dynamic access control, and cross-protocol enforcement, with Zero Trust principles applied to agentic IAM. Its proposed design also faces unresolved challenges in scalability, interoperability, governance, security, usability, and societal impact.

C. Cross-Layer Threats Affecting the IAM Framework

VIII. INNOVATIVE CONTRIBUTIONS OF THIS FRAMEWORK

  • The end-to-end framework integrates identity issuance, credentialing, capability-aware discovery, dynamic access control, and cross-protocol enforcement across an agent’s lifecycle.It addresses agents that spawn others, change roles, and need fine-grained, context-sensitive authorization at scale.Source: §VIII · pp. 21–22
  • DID-anchored Agent Identities use Verifiable Credentials for attributes, capabilities, compliance, roles, and provenance, while Zero-Knowledge Proofs support selective, private claim presentation.The identity can include behavioral scope, authorized tools, and model hashes, with re-attestation as agents evolve.Source: §VIII · p. 22
  • The Agent Naming Service discovers agents by name or attested capability, while context-based access control adapts authorization to real-time environmental, behavioral, and task conditions.Verifiable toolsets and behavioral scope support least-function enforcement and limit the blast radius of compromised or misbehaving agents.Source: §VIII · p. 22
  • The cross-protocol session layer propagates global session termination, DID revocation, and capability downgrades across heterogeneous agent interactions.It is designed to enforce policy decisions and revocations immediately and uniformly, regardless of transport.Source: §VIII · p. 22
  • Agent-controlled DIDs and credentials remain subject to trusted-issuer checks and Session Authority revocations or policy overrides, while signed identities, claims, and actions support verifiable audit trails.The provenance trail can link an agent to its creator, models, dependencies, training data, or safety audits.Source: §VIII · p. 22

IX. DISCUSSION AND FUTURE WORK

Loading 2505.19301v2…