Global AI Agent Identification and Governance Framework (GAID)

Abstract

The Global AI Agent Identification and Governance Framework (GAID) is a normative identity, badging, and traceability standard for AI agents. It defines how an agent is named, how its governance and capability claims are expressed, how its public and private identities relate to each other, and how its actions are traced across system boundaries.

The problem GAID addresses is not naming alone. The problem is that AI agents are increasingly expected to act with durable identity, delegated authority, tool access, and external impact, while the market still relies on ad hoc metadata, undocumented prompts, trial-and-error capability discovery, and weak audit trails. In practice, organizations cannot reliably inventory, compare, govern, or trust agents at scale without a stronger identity and assurance model.

GAID is intentionally complementary to TAK. GAID defines who an agent is, what claims can be made about it, and how those claims are verified and traced. TAK defines how a trustworthy runtime MUST govern the agent in operation.

1. Scope

This standard specifies requirements for:

• stable agent identifiers in private and public namespaces
• issuer, registry, and accreditation expectations
• agent identity resolution
• the Agent Identity Document (AIDoc)
• badging and assurance claims
• portable authorization classes
• chain-of-custody and action receipt records
• public validation, revocation, and reassignment controls
• interoperability profiles for emerging agent protocols

This standard applies to:

• enterprise-private agents
• public-facing business-to-business and business-to-consumer agents
• government and regulated-environment agents
• single-agent and multi-agent systems
• embedded, routed, orchestrated, and externally callable agents

This standard does not define:

• runtime execution controls, memory governance, or human-in-the-loop enforcement
• internal model architecture
• organization-wide AI management systems

Those concerns are addressed respectively by TAK and broader governance frameworks such as ISO/IEC 42001.

2. Conformance

An implementation conforms to this standard only if it satisfies all requirements identified as MUST for its claimed conformance profile.

This standard defines three conformance profiles:

• GAID-Private
• GAID-Federated
• GAID-Public

An implementation:

• MUST declare the highest conformance profile it claims
• MUST NOT claim a higher profile if any mandatory control for that profile is absent
• MUST distinguish between self-asserted, organization-attested, independently-assessed, and accredited-certified claims
• SHOULD publish an implementation statement showing how each control is met
• MAY implement controls beyond those required by its claimed profile

2.1 Standard Versioning, Lifecycle, and Conformance Assertions

This standard SHOULD be versioned using a semantic-style scheme:

• major versions for normative incompatibilities
• minor versions for additive normative capabilities or profiles
• patch versions for clarifications, errata, or non-substantive corrections

Implementations claiming conformance SHOULD declare:

• the supported GAID version
• the claimed conformance profile
• any declared public-trust profile such as private-only, federated, certificate-backed, or decentralized-portability

Each normative MUST statement in this standard SHOULD map to one or more explicit conformance assertions in a companion test suite or implementation statement. This document does not require one central verifier implementation, but it does require that conformance claims be testable rather than rhetorical.

A suggested companion assertion rubric for this revision is published in gaid-conformance-tests.md.

The intended lifecycle of GAID is open standards progression through multistakeholder implementation and liaison rather than indefinite treatment as an internal white paper.

The preferred near-term disposition is publication as an open industry specification with explicit liaison to OpenID AIIM, the W3C Agent Identity Registry Protocol Community Group, CoSAI, and relevant IETF OAuth / GNAP work, with later venue-specific profiles or registrations preserving the same identity and evidence semantics.

3. Normative References

The following references are relevant to this standard and informed its design:

4. Terms and Definitions

For the purposes of this standard:

5. Design Principles

An implementation of GAID:

• MUST treat agent identity as a governance artifact, not merely a UI label
• MUST separate stable identity from mutable runtime configuration
• MUST distinguish enduring subject identity from versioned operating state
• MUST preserve a durable mapping from agent identity to issuing authority
• MUST distinguish declared capability from verified capability
• MUST distinguish local authorization from portable authorization class
• MUST preserve chain-of-custody for consequential actions
• SHOULD support both private and public operation without forcing them to share a single namespace
• SHOULD expose enough structured metadata that relying parties do not need trial-and-error to determine whether an agent is fit for purpose
• MAY support additional badge vocabularies, sectors, or regulatory overlays so long as the core identity and receipt semantics are preserved

6. Namespace and Issuer Model

6.1 Core Requirement

Every materially distinct AI agent subject MUST have a stable identifier.

The identifier MUST be:

• unique within its issuing scope
• durable across routine configuration and model-version changes
• resolvable to a current identity document
• non-ambiguous about whether it is private or public

6.2 GAID Syntax

This standard defines the following canonical identifier form:

gaid:<scope>:<issuer-prefix>:<agent-local-id>

Where:

• <scope> MUST be either priv or pub
• <issuer-prefix> MUST identify the issuing namespace authority
• <agent-local-id> MUST be unique within that issuer prefix

Examples:

• gaid:priv:contoso.internal:hr-onboarding-coordinator
• gaid:pub:example.ai:claims-review-agent

An implementation MAY maintain additional internal identifiers, but the canonical GAID MUST remain the primary interoperable identifier.

Public standardization of the identifier form remains an open deployment task. A future public profile SHOULD either register GAID as a URI scheme or profile it as a URN namespace in line with the relevant IANA process, rather than leaving the colon-delimited form permanently informal.

An early public-federation work item SHOULD therefore include an explicit IANA registration plan, naming authority expectations, and backward-compatibility rules for private deployments that began before a public namespace decision was finalized.

Figure 1. GAID separates private and public namespaces while preserving governed mapping between them.

6.3 Public Namespace

A GAID-Public implementation MUST operate under a namespace that is globally recognizable and administratively governed.

For public identifiers:

• the issuer prefix MUST be controlled by the issuing authority or its delegate
• the issuing authority MUST publish its validation material and status process
• the identifier MUST resolve to a current AIDoc
• the issuer MUST support revocation and status inquiry

An issuer prefix SHOULD be derived from or bound to a verifiable public namespace such as:

• an internet domain under the issuer’s control
• a recognized government or industry registration namespace
• a delegated sub-namespace allocated by an accredited root or federation

6.4 Private Namespace

A GAID-Private implementation MAY issue internal identifiers without global registration.

For private identifiers:

• the issuer MUST ensure uniqueness within its boundary
• the issuer MUST maintain a local resolution mechanism
• the issuer SHOULD maintain an internal status and revocation record
• the issuer prefix MUST include a stable installation, domain, or equivalent namespace discriminator so future federation does not require subject renaming
• the identifier MUST NOT be represented as publicly accredited unless it has passed through a recognized public issuance process

6.5 Boundary Mapping

An agent exposed outside its original administrative boundary MUST NOT rely solely on a private identifier.

Where a private agent is exposed publicly:

• a public GAID MUST be assigned
• the relationship between the private and public identifiers MUST be recorded
• the mapping MUST be visible to authorized auditors
• the mapping SHOULD NOT disclose internal-only identifiers to general public consumers unless policy requires it

6.6 Delegation, Accreditation, and Root Governance

Public GAID operation depends on recognized issuer governance.

Therefore:

• a GAID-Public ecosystem MUST define one or more root registries or a recognized federation of roots
• public issuers MUST be accredited directly or indirectly under that governance model
• accredited issuers MUST publish allocation, status, and revocation policies
• accredited issuers MUST be auditable
• accredited issuers MUST be able to prove control of the prefixes they allocate

The point is not to centralize all issuance in one institution. The point is to ensure that public trust is anchored in recognized governance rather than private assertion alone.

6.7 Revocation, Suspension, and Reassignment

An issuer MUST support status values that distinguish at least:

• active
• suspended
• revoked
• retired
• superseded

A public GAID:

• MUST NOT be silently reassigned to a materially different agent subject
• SHOULD remain tombstoned after revocation or retirement
• MUST preserve historical receipts and evidence even when the current status is no longer active

Private GAID reassignment SHOULD NOT occur. If it does occur under local policy, the reassignment MUST be explicitly recorded, and prior evidence MUST remain distinguishable from the new subject.

6.8 Subject Identity, Exposure State, and Continuity

GAID identifies the enduring AI subject, not merely one ephemeral runtime instance.

Accordingly:

• routine changes to model binding, prompt bundles, tools, badges, or autonomy posture MUST NOT mint a new GAID by default
• the same GAID SHOULD remain valid when an internal-only agent later becomes federated or publicly exposed
• identity continuity and exposure-state continuity MUST be treated as separate concerns

An implementation SHOULD distinguish at least the following exposure states:

• private
• federated
• public

Changing exposure state:

• MAY require stronger verification or publication controls
• MUST NOT silently break subject continuity
• SHOULD preserve auditable mapping from earlier internal usage to later external usage

6.9 Subject Identity Versus Operating State

This standard distinguishes:

• subject identity — the enduring GAID-identified agent subject
• operating state — the currently governed version of the agent’s operational form

The operating state SHOULD include materially relevant elements such as:

• model and provider binding
• prompt and instruction bundle references
• tool surface
• autonomy posture
• verification references
• current badges and authorization posture

A change to operating state SHOULD create a new governed version or state record beneath the same GAID, rather than replacing the GAID itself.

6.10 Public Verification Architecture Options

For cross-organizational or public trust, this standard recognizes several viable authority architectures:

• directory-first private only
• public PKI and domain-anchored issuer model
• federated trust-list model
• decentralized identifier and verifiable credential model
• hybrid model

The standard does not require one monopoly authority architecture. It does, however, require that a public GAID ecosystem clearly specify:

• who the recognized issuers are
• how issuer status is validated
• how revocation and suspension are published
• how relying parties verify current trust status

6.11 Preferred Public Architecture

The preferred public architecture under this standard is a hybrid model:

• private enterprise identity remains directory-native
• public identity is issuer-accredited and publicly verifiable
• verifiable credential and decentralized identifier projections MAY be supported as optional portability profiles
• transparency publication SHOULD exist regardless of whether the underlying authority model is centralized, federated, or decentralized

This preference is based on current adoption and operational precedent:

• directory systems remain the practical enterprise anchor for internal identity
• certificate and domain-controlled trust models remain the most deployable public-trust pattern
• decentralized profiles remain useful, but should not be the only available public-validation path

This standard is intended to be complementary to, and in active liaison with, adjacent identity efforts rather than competitive with them. In particular:

• OpenID AIIM occupies the transaction, authentication, authorization, and identity-modularization layer
• the W3C Agent Identity Registry Protocol Community Group occupies an adjacent verifiable identity-infrastructure lane
• CoSAI occupies a practical control-framework lane for enterprise deployment

GAID focuses on the compositional identity, badge, receipt, and issuer-governance semantics that these efforts can consume, profile, or align around.

Figure 2. Preferred hybrid GAID verification composes private identity, accredited public identity, status, and verifier workflows rather than collapsing trust into one mechanism.

6.12 Staged Adoption Model

GAID is designed for staged adoption.

The expected path is:

1. enterprise-private foundation
2. federated or accredited cross-boundary trust
3. global public trust fabric

In the first stage:

• private GAID issuance
• internal AIDoc resolution
• enterprise directory projection
• organization-attested badges
• internal receipts

In the second stage:

• public or partner-facing GAID
• accredited issuer or recognized federation participation
• signed public AIDoc
• public status and revocation
• stronger assurance and transparency publication

In the third stage:

• broader public verifier interoperability
• optional decentralized portability profiles
• stronger cross-jurisdiction governance and dispute handling

This staged model is not a sign of incompleteness. It follows the historical pattern by which durable identifier systems such as ISBN, DNS, and public certificate ecosystems became operationally trusted at scale.

6.13 Governance Dependencies and Economic Model

Public GAID operation depends on recognized governance and sustainable funding.

Therefore a GAID-Public ecosystem MUST define:

• root or federation authority responsibilities
• issuer accreditation requirements
• audit and dispute processes
• status and revocation publication responsibilities
• funding and fee policies for the operating trust system

The preferred funding posture is:

• no mandatory public-fee dependency for private enterprise GAID
• issuer accreditation and operating fees for public issuance
• optional certification fees for higher-assurance badges
• transparency and status infrastructure funded primarily by issuers or federation participants rather than by per-action usage charges

The standard SHOULD NOT assume a per-receipt or per-agent-action public fee model because that scales poorly for high-volume operational use.

6.14 Open Questions for Global Adoption and Scale

The following questions remain important for global-scale adoption and SHOULD be treated as governance work items rather than ignored ambiguities:

• whether one root, many roots, or federated trust lists should dominate
• how cross-jurisdiction disputes, fraud, and reassignment are handled
• how public transparency avoids creating unnecessary surveillance or correlation risk
• how small issuers, open-source communities, and public-interest organizations participate affordably
• how sector overlays and badge vocabularies are governed without fragmentation
• how platform migrations, mergers, or provider changes preserve durable identity

These open questions do not block private or early federated adoption. They do, however, matter for credible global public operation.

6.15 Optional Decentralized Portability Profile

GAID MAY support a decentralized portability profile using VC, DID, or another recognized controlled-identifier model.

If such a profile is used:

• the core GAID semantics MUST remain unchanged
• sensitive or rapidly changing operating metadata SHOULD NOT be forced into an immutable public ledger
• off-chain status, receipt, and evidence services MAY still remain necessary
• ledger or registry anchoring SHOULD be used primarily for proof commitments, status references, or key material rather than for full public disclosure of agent internals

6.16 Bootstrap and Recognition Path

Early public GAID ecosystems SHOULD support a bootstrap model in which:

• organizations or sector alliances publish mutual-recognition trust lists
• recognized issuers publish their validation material, status endpoints, and policy references
• relying parties can adopt one or more roots or trust lists without waiting for a single global authority

This mirrors the way durable trust systems often mature in practice: through interoperable recognition and policy alignment first, and tighter accreditation convergence later.

7. Agent Identity Document (AIDoc)

7.1 Core Requirement

Every conforming GAID implementation MUST provide an AIDoc for each issued agent identity.

The AIDoc:

• MUST be structured and machine-readable
• MUST be signed or otherwise cryptographically protected
• MUST represent current status
• MUST identify the issuer
• MUST disclose the operating surface relevant to relying-party trust

The AIDoc MAY be represented in JSON, JSON-LD, or another interoperable encoding, provided the semantics in this standard are preserved.

Figure 3. Public trust depends on being able to resolve an agent identifier into current, signed identity metadata.

7.2 Minimum AIDoc Fields

At minimum, an AIDoc MUST contain the following fields:

7.3 Disclosure Expectations

The AIDoc MUST NOT fabricate precision that the issuer does not have.

If an issuer does not know a field such as:

• training-data disclosure
• benchmark evidence
• effective context limit
• provider-side memory behavior
• model bias assessment

then the field MUST be marked as:

• undisclosed
• not assessed
• not independently verified
• not applicable

The point is not to force perfect disclosure. The point is to make missing evidence explicit.

For adoption, a GAID-Private implementation SHOULD be able to publish a minimum viable AIDoc using only the MUST fields plus the smallest set of local accountability fields needed to inventory and govern the subject.

7.4 Minimum Viable Private AIDoc

A minimum viable private AIDoc SHOULD usually be sufficient if it contains:

• gaid
• subject_name
• issuer
• status
• subject_type
• owner_organization
• versioning
• model_binding
• tool_surface

Most enterprises will also want at least one local accountability field such as owner_of_record, responsible_team, or directory_bindings.

7.5 Operating Surface Declarations

The AIDoc SHOULD declare the surfaces that materially affect trust, including:

• exposed tools and connector families
• external protocols such as MCP, A2A, HTTP APIs, queues, or event streams
• prompt or instruction classes
• skills or callable specialties
• data stores or retrieval classes
• memory and context persistence posture

An implementation MUST NOT claim that an agent is narrowly scoped if its declared operating surface is materially broader.

7.6 Validation Continuity

An AIDoc SHOULD make it possible for a relying party to distinguish between:

• the same enduring agent subject
• the same currently validated operational subject

This means an implementation SHOULD expose enough state to answer:

• is this still the same GAID?
• is this still the same materially validated operating state?

The answer to the second question MAY change even when the answer to the first remains yes.

7.7 Enterprise Directory and Lifecycle Projection

For enterprise-private operation, the AIDoc SHOULD make it possible to project the enduring agent subject into directory and lifecycle systems without fragmenting identity.

At minimum, an enterprise projection SHOULD make visible where policy allows:

• the canonical private GAID
• display name and subject type
• owner, sponsor, or responsible team
• directory or tenant-local lifecycle identifiers
• coarse access or group posture
• current validation or restriction state

The purpose is not to turn LDAP or SCIM into GAID. The purpose is to let internal IAM, access review, and inventory systems reason about agent identity using familiar enterprise carriers.

7.8 Example Machine-Readable AIDoc Pattern

An AIDoc SHOULD be rich enough that a relying party can answer basic trust questions without trial-and-error probing.

Those questions include:

• who owns and sponsors this agent
• what identity systems it is bound to internally
• what kinds of systems and data it can reach
• what protocols it exposes
• what evidence exists for the current claims

This standard does not require one single serialization format, but it SHOULD encourage a predictable JSON-based baseline so enterprises can inventory, compare, and validate agents programmatically.

8. Badge and Assurance Model

8.1 Core Principle

Badging is an integral part of agent identity under this standard. A GAID without a structured claim model is insufficient for scalable trust.

Badges exist to answer questions that organizations and consumers repeatedly face in practice:

• What can this agent do?
• What is it allowed to touch?
• What evidence supports that claim?
• Has anyone independent assessed it?
• Is it suitable for the purpose for which it is being offered?

8.2 Badge Categories

A conforming implementation SHOULD support badge categories at least sufficient to express:

8.3 Badge Payload Requirements

Each badge MUST identify:

• badge type
• claim statement
• claim scope
• issuer
• assurance level
• issuance date
• expiry or review date where applicable
• evidence reference or explicit statement that evidence is absent

For scoped claims, the badge SHOULD structure scope explicitly rather than leaving it as prose.

At minimum, scoped fit-for-purpose or governance badges SHOULD make it possible to express:

• applicable business archetypes or sectors
• applicable operating-model classes
• applicable workflow or task classes
• applicable data classes
• required oversight or HITL posture
• excluded uses or prohibited contexts
• jurisdictional or regulatory overlays where relevant

8.4 Assurance Levels

At minimum, the following assurance levels MUST be supported:

An issuer MUST NOT present a self-asserted claim as if it were independently-assessed or accredited-certified.

8.5 Benchmark and Disclosure Claims

If a badge claims a measured capability or operating limit, the badge SHOULD identify the basis for that claim, such as:

• benchmark or evaluation suite
• test date
• model version
• tool set under test
• token or context assumptions
• failure rate, calibration threshold, or success threshold

Examples include:

• maximum recommended task horizon
• observed tool-use success rate
• effective context-window utilization under declared conditions
• hallucination or fabrication rate under defined tests
• known limits or exclusions

Where possible, the evidence model SHOULD reuse adjacent standards and recognized evidence artifacts such as:

• model cards
• benchmark or evaluation reports
• VC-carried attestations
• SPDX, CycloneDX, or purl references for software and component identification
• SLSA or equivalent provenance statements
• signed receipts and transparency-log references

8.6 Badge Freshness

Capability, safety, and fit-for-purpose badges SHOULD expire or be reviewed on a defined cadence.

An issuer MUST NOT continue to advertise stale badges as current once the underlying model, runtime, or tool surface has materially changed.

8.7 Badge Scope and Version Specificity

Badges SHOULD attach to a governed operating state or profile version, not permanently to the GAID in the abstract.

This is important because:

• model behavior can improve
• model behavior can degrade
• tool-use capability can materially change
• prompt or runtime changes can alter risk posture
• a provider can silently alter behavior under the same marketed model line

An implementation SHOULD therefore preserve:

• the enduring GAID
• versioned operating-state history
• badge history by operating-state version

8.8 Material Change and Badge Invalidation

When a material change occurs, affected badges MUST NOT silently remain current unless policy and evidence explicitly justify doing so.

At minimum, a conforming implementation SHOULD support badge states such as:

• active
• pending-revalidation
• stale
• restricted
• revoked

Material changes include, at minimum:

• model or provider changes
• prompt or instruction bundle changes
• tool-surface changes
• autonomy or governance changes
• verification key, certificate, or credential-binding changes that affect identity, signing, or delegated authority
• runtime dependency drift that alters practical capability or risk

8.9 Practical Capability Drift

This standard recognizes that provider-side or dependency-side behavior may change without a neatly versioned public release signal.

An implementation MUST NOT assume that a stable model marketing name alone guarantees capability continuity.

Where meaningful drift is detected:

• the relevant badge state SHOULD change
• the validation state SHOULD become visible to relying parties
• the prior capability claim MUST NOT continue to be represented as fully current without revalidation

Figure 4. GAID separates identity from the strength of evidence behind claims about that identity.

8.10 Archetype, Workflow, and Data-Scope Scrutiny

GAID fit-for-purpose claims MUST NOT be treated as universal simply because an agent performs well in one narrow context.

For materially consequential badges, a conforming implementation SHOULD scrutinize claims against:

• the business archetypes or sectors in which the claim is intended to apply
• the workflow classes the agent is expected to perform
• the data sensitivity and jurisdiction classes in which the claim will operate
• the oversight posture required to keep the claim valid
• explicitly excluded or higher-risk scenarios where the claim does not apply

This is especially important where organizations are trying to govern broad families of internal and public AI agents. A badge that is useful for a low-risk intake workflow in one archetype MUST NOT be implied to cover high-risk approval or regulated decision support in another.

9. Authorization Classes

9.1 Purpose

Authorization classes are portable declarations of intended action scope. They are not a substitute for local runtime authorization.

This distinction matters. A relying party needs to know what class of actions an agent is designed to request or perform, while a runtime still needs its own live policy model such as RBAC, ABAC, or TAK execution gating.

9.2 Minimum Class Vocabulary

A conforming implementation SHOULD support at least the following portable classes:

9.3 Mapping Rule

An implementation:

• MUST map portable authorization classes to local runtime policy
• MUST NOT treat a declared authorization class as proof of present authorization
• SHOULD include the active authorization class reference in receipts for consequential actions

10. Chain-of-Custody and Agent Action Receipts

10.1 Core Requirement

Consequential agent actions MUST produce a receipt or an equivalent evidence record.

Consequential actions include:

• state-changing tool calls
• approvals or rejections
• cross-agent delegation
• cross-boundary requests
• publication, deployment, or deletion events
• actions involving sensitive data

10.2 Minimum Receipt Fields

At minimum, a receipt MUST contain:

10.3 Trace Context and Delegation

For multi-step or multi-agent flows:

• the initiating trace context SHOULD be preserved end to end
• delegated actions MUST retain a parent-child receipt relationship
• the delegated agent’s GAID MUST be recorded
• the delegating agent’s GAID MUST remain visible in the chain

10.4 Integrity and Non-Repudiation

For GAID-Federated and above:

• receipts MUST be tamper-evident
• signatures SHOULD use RFC 9421, JOSE, COSE, DSSE, or an equivalent standard mechanism
• verification material MUST be discoverable through the AIDoc or issuer metadata
• sender-constrained token or proof-of-possession binding such as DPoP SHOULD be used where receipts depend on bearer-style access tokens across trust boundaries
• content artifacts produced or transformed by agents SHOULD support provenance mechanisms such as C2PA where the relying-party context expects content-level authenticity or AI-origin disclosure
• implementers SHOULD prefer working evidence stacks such as in-toto attestations and Sigstore verification or transparency services where they fit the deployment model, rather than inventing proprietary receipt envelopes

10.5 Privacy and Minimization

Receipts MUST minimize unnecessary disclosure.

Accordingly:

• raw prompt text SHOULD NOT be included by default in public receipts
• sensitive user content SHOULD be referenced by digest, pointer, or protected evidence store rather than copied directly
• internal-only context MAY be redacted in public-facing receipts while remaining available to authorized auditors

Implementations handling identifiable human context SHOULD align receipt and AIDoc retention with applicable privacy controls such as GDPR and ISO/IEC 27701, including minimization, retention, and accountability expectations.

Figure 5. GAID receipts preserve the chain from principal to agent to delegate to resulting evidence.

11. Protocol Profiles and Interoperability

11.1 General Rule

GAID does not replace agent protocols. It provides the identity and governance layer that those protocols can carry.

An implementation SHOULD declare how GAID claims are surfaced across the protocols it uses.

11.2 Core, Extensions, and Profile Pattern

GAID implementations SHOULD follow a stable-core and protocol-profile pattern rather than redefining each transport or directory protocol around AI agents.

In that pattern:

• the core GAID model defines the enduring subject, issuer lineage, AIDoc, badge semantics, receipt semantics, and continuity rules
• extension vocabularies define additional sector, enterprise, or protocol-specific fields without altering core subject semantics
• protocol profiles define how core and extension claims are projected into a particular carrier such as LDAP, SCIM, MCP, A2A, or HTTP APIs

An implementation MUST NOT create protocol-specific subject identifiers that fragment the canonical GAID identity merely because the carrier format differs.

11.3 Extension Registry Model

A conforming ecosystem SHOULD maintain a registry or equivalent catalog for extension vocabularies and protocol profiles.

That registry SHOULD identify at least:

• the extension or profile name
• the fields or claims it defines
• whether those fields are normative, optional, or implementation-specific
• what underlying GAID core concepts each field maps to
• any privacy or disclosure constraints on publication

This allows enterprise and public ecosystems to add agent-specific semantics without destabilizing the core identity model.

11.4 MCP Profile

For MCP environments:

• the agent SHOULD expose its GAID and relevant AIDoc reference in connection or server metadata where possible
• declared tools in the AIDoc SHOULD align with the actual exposed tool surface
• remote tool invocation receipts SHOULD preserve acting agent identity and trace context
• protected MCP deployments SHOULD align their verifier and authorization metadata with the MCP authorization profile and RFC 9728 discovery model rather than inventing parallel discovery semantics

11.5 A2A Profile

For A2A environments:

• the Agent Card SHOULD carry or reference the agent’s GAID
• the published skills and capabilities SHOULD align with AIDoc claims
• task and artifact events SHOULD preserve chain-of-custody identifiers
• public agents SHOULD bind Agent Card metadata to issuer-controlled verification material
• where A2A agent cards advertise securitySchemes or authenticated extended cards, the published GAID projection SHOULD remain consistent across both public and authenticated card variants

11.6 HTTP and API Profile

For direct HTTP APIs:

• GAID SHOULD be carried in request or message metadata
• signatures SHOULD bind the identity claim to the request
• trace context SHOULD follow W3C Trace Context

11.7 LDAP Profile

GAID does not replace LDAP, but a conforming implementation SHOULD define how agent identity is projected into enterprise directory systems.

For LDAP projections:

• the enduring GAID SHOULD be published as a stable agent identity attribute
• standard structural directory classes SHOULD be preserved for broad client compatibility
• agent-specific semantics SHOULD be added through auxiliary object classes or clearly namespaced attributes rather than replacing standard directory structure
• agent entries SHOULD remain distinguishable from human and service principals by explicit type attributes and not only by directory placement
• profile fingerprint and validation state SHOULD be publishable to authorized relying parties
• issuer, exposure state, and verifier references MAY be projected where downstream trust decisions require them
• group membership MAY be used as the primary coarse authority surface for downstream compatibility

An implementation MUST NOT rely only on directory placement or display labels to distinguish agent identity type.

11.8 SCIM Profile

GAID likewise does not replace SCIM, but a conforming implementation SHOULD define how the enduring agent subject and its selected metadata are projected through lifecycle provisioning interfaces.

For SCIM projections:

• the canonical GAID SHOULD remain the stable subject reference
• mutable operating-state references, validation state, and selected badge data MAY be mapped through appropriate profile extensions
• lifecycle updates SHOULD revise the operating-state projection without minting a new enduring subject identifier
• lifecycle operations such as activation, suspension, and deprovisioning SHOULD preserve GAID continuity rather than fragmenting subject identity

11.9 Async and Queue Profile

For queue-based or event-driven systems:

• the acting GAID MUST be preserved in message metadata
• the receipt relationship MUST survive retries and delayed processing
• replay or duplicate-delivery handling SHOULD be explicit

11.10 UI and Human Interaction Profile

Where agent interactions are surfaced to humans through approvals, task cards, or dynamic interfaces:

• the visible agent identity SHOULD map to the canonical GAID
• approval prompts SHOULD disclose enough badge and assurance information that the human can make an informed decision
• approval prompts SHOULD disclose the relevant receipt_id or proposed receipt reference so the approval can later be audited and referenced precisely
• any generated UI SHOULD NOT obscure who the acting agent is, what class of action is proposed, or what evidence exists

11.11 Public Verifier Profile

For public verification flows, a conforming implementation SHOULD make it possible for a relying party or verifier to:

1. resolve the canonical public GAID
2. retrieve the current AIDoc
3. verify issuer signature or equivalent cryptographic protection
4. verify issuer accreditation or federation trust status
5. verify current suspension, revocation, or retirement status
6. verify current badge validity and assurance level
7. inspect or validate receipt or trace evidence where a consequential action is in question

The verifier profile SHOULD support this flow without requiring disclosure of internal-only prompts, secrets, or sensitive enterprise-only entitlement details.

The verifier profile SHOULD also:

• support either HTTPS issuer resolution or approved decentralized-resolution profiles where applicable
• resolve issuer trust through an explicit trust anchor or trust-list source
• enforce freshness policy for cached status material

12. Security and Privacy Considerations

An implementation conforming to this standard:

• MUST defend against agent identity spoofing
• MUST support key rotation and status updates
• MUST distinguish hidden-instruction disclosure from hidden-instruction publication
• MUST treat prompt injection, tool injection, and connector compromise as identity-relevant risks, not merely runtime bugs
• SHOULD bind public agent identity to organizational certificates or equivalent verification material
• SHOULD use transparency logging for public issuance and revocation events
• SHOULD minimize personally identifiable information in public identity documents and receipts
• SHOULD align threat analysis and control mapping with public catalogs such as OWASP Top 10 for Agentic Applications, CSA MAESTRO, and MITRE ATLAS
• SHOULD consider applicable privacy and transparency obligations under frameworks such as the EU GPAI Code of Practice, enterprise privacy programs, and sector-specific disclosure rules
• MAY support selective disclosure for regulated or classified environments

A shared starter artifact for this work MAY be published as agent-standards-threat-model.md, provided implementations still adapt it to their real issuer, verifier, and deployment boundaries.

An issuer MUST NOT imply that identity proof alone guarantees behavioral safety. Identity enables accountability. It does not replace runtime controls.

13. Conformance Profiles

13.1 GAID-Private

A GAID-Private implementation:

• MUST issue stable private identifiers
• MUST maintain local AIDoc resolution
• MUST record status
• SHOULD project the identity into enterprise directory or lifecycle systems where relevant
• SHOULD carry owner, sponsor, or responsible-team accountability metadata
• SHOULD issue receipts for consequential actions
• MAY omit public accreditation and external certificate validation

13.2 GAID-Federated

A GAID-Federated implementation:

• MUST meet all GAID-Private requirements
• MUST support delegated issuer governance
• MUST support signed AIDoc publication
• MUST support receipt integrity and status checking
• SHOULD maintain a transparency log
• SHOULD support organization-attested, independently-assessed, and accredited-certified badges
• SHOULD support verifier-facing trust-list or federation publication

13.3 GAID-Public

A GAID-Public implementation:

• MUST meet all GAID-Federated requirements
• MUST use an accredited issuer model or recognized federated equivalent
• MUST expose public verification material
• MUST support public revocation and status checks
• MUST provide public-facing badge and assurance disclosures appropriate to relying-party trust
• SHOULD support certificate-backed identity binding for public endpoints and organizational ownership
• SHOULD support hybrid verification in which domain or certificate control, issuer status, and optional decentralized portability can coexist without fragmenting the canonical subject identity

Implementations claiming any GAID profile SHOULD publish an assertion mapping, evidence pack, or equivalent rubric such as the companion gaid-conformance-tests.md document.

14. Informative Annexes

Annex A: Relationship to TAK

GAID and TAK solve different but related problems:

• GAID identifies the agent, its claims, and its evidence
• TAK governs the runtime in which that agent acts

An implementation with TAK but no GAID may be locally well governed but externally opaque.

An implementation with GAID but no TAK may be well labeled but behaviorally under-governed.

The standards are therefore complementary.

Annex B: Suggested AIDoc Skeleton

{
  "gaid": "gaid:pub:example.ai:claims-review-agent",
  "subject_name": "Claims Review Agent",
  "issuer": {
    "name": "Example AI Public Issuer",
    "prefix": "example.ai"
  },
  "status": "active",
  "subject_type": "specialist",
  "owner_organization": "Example Insurance Group",
  "versioning": {
    "agent_release": "2026.04.3"
  },
  "owner_of_record": {
    "type": "person",
    "display_name": "Director of Claims Operations"
  },
  "responsible_team": "Claims Automation Team",
  "controlling_humans": [
    {
      "role": "sponsor",
      "display_name": "Director of Claims Operations"
    },
    {
      "role": "approval_authority",
      "display_name": "Claims Governance Board"
    }
  ],
  "directory_bindings": [
    {
      "system": "entra",
      "tenant_ref": "contoso-tenant",
      "subject_ref": "11111111-2222-3333-4444-555555555555"
    }
  ],
  "model_binding": {
    "provider": "example-provider",
    "model_family": "frontier-assistant",
    "model_version": "2026-04"
  },
  "operating_profile_fingerprint": "sha256:3d034b7f46c7b3b4adf8d2f6e7027fe4967963f4b7091d988b41b0d4fcf25e8b",
  "tool_surface": [
    "claims.lookup",
    "policy.lookup",
    "note.create"
  ],
  "entitlement_scope": [
    "claims_read",
    "policy_read",
    "case_note_create"
  ],
  "reachable_systems": [
    "claims-platform",
    "policy-system"
  ],
  "reachable_data_classes": [
    "internal-confidential",
    "customer-pii"
  ],
  "least_privilege_posture": "org-attested",
  "blast_radius_profile": {
    "system_impact": "bounded",
    "data_impact": "moderate",
    "requires_hitl_for_side_effects": true
  },
  "mcp_surfaces": [
    "claims-tools-server"
  ],
  "a2a_surfaces": [
    "https://agents.example.ai/cards/claims-review-agent"
  ],
  "authorization_classes": [
    "observe",
    "analyze",
    "create"
  ],
  "badges": [
    {
      "badge_id": "badge-fit-claims-triage-v3",
      "category": "fit-for-purpose",
      "claim": "claims-triage-support",
      "assurance_level": "org-attested",
      "claim_scope": {
        "business_archetypes": [
          "insurance-claims"
        ],
        "workflow_classes": [
          "triage",
          "summarization"
        ],
        "data_classes": [
          "customer-pii"
        ],
        "required_hitl_tier": "approve-before-execution",
        "excluded_uses": [
          "claims-approval",
          "coverage-denial"
        ]
      },
      "evidence_refs": [
        "https://issuer.example.ai/evidence/model-card/claims-review-agent",
        "https://issuer.example.ai/evidence/evaluations/claims-review-agent-v3"
      ]
    }
  ],
  "evidence_refs": [
    "https://issuer.example.ai/evidence/policy/claims-review-agent",
    "https://issuer.example.ai/evidence/runtime-profile/claims-review-agent"
  ],
  "verification_material": {
    "certificate_ref": "https://issuer.example.ai/certs/current"
  },
  "status_endpoint": "https://issuer.example.ai/status/claims-review-agent",
  "transparency_log": "https://issuer.example.ai/log/claims-review-agent"
}

Annex C: Governance Implication

The strongest lesson from adjacent systems such as DNS, ISBN, PKI, and software provenance is that syntax alone is not enough.

Identity works at scale only when:

• the namespace is governed
• issuers are recognized
• relying parties can validate claims
• status changes are visible
• historical evidence is preserved

The staged adoption model in this standard follows that precedent:

• core identifier and semantics first
• private or local operational use second
• delegated or accredited public issuance third
• broader public verification, transparency, and portability after that

That is the governance posture GAID is intended to establish for AI agents.

Annex D: Suggested Public Verifier Pseudocode

function verifyPublicGAID(gaid, expected_fingerprint = null, max_status_age = "PT15M"):
  aidoc = resolveAIDoc(gaid, resolution_profiles = ["https", "approved-decentralized"])
  if aidoc is null:
    return failure("aidoc_not_found")

  trustAnchor = resolveIssuerTrustAnchor(aidoc.issuer)
  if trustAnchor is null:
    return failure("issuer_not_trusted")

  if not verifySignature(aidoc, trustAnchor):
    return failure("invalid_aidoc_signature")

  if not verifyIssuerStatus(aidoc.issuer, trustAnchor):
    return failure("issuer_status_invalid")

  if not verifyCurrentStatus(aidoc.status_endpoint, aidoc.status, max_status_age):
    return failure("subject_status_invalid")

  if expected_fingerprint is not null:
    if not verifyOperatingProfileContinuity(aidoc.operating_profile_fingerprint, expected_fingerprint):
      return failure("operating_profile_mismatch")

  if not verifyBadgeValidity(aidoc.badges):
    return failure("badge_posture_invalid")

  if not verifyTransparencyReference(aidoc.transparency_log):
    return failure("transparency_reference_invalid")

  return {
    subject_identity_valid: true,
    issuer_valid: true,
    status_valid: true,
    badge_posture: summarizeBadges(aidoc.badges)
  }

Annex E: Suggested Receipt Verifier Pseudocode

function verifyReceipt(receipt, aidoc, max_receipt_age = "P30D"):
  if receipt is null:
    return failure("receipt_not_found")

  if receipt.gaid != aidoc.gaid:
    return failure("receipt_subject_mismatch")

  if not verifyReceiptSignature(receipt, aidoc.verification_material):
    return failure("invalid_receipt_signature")

  if not verifyReceiptFreshness(receipt.timestamp, max_receipt_age):
    return failure("receipt_stale")

  if receipt.parent_receipt is not null:
    if not verifyParentReceiptLink(receipt.parent_receipt, receipt.trace_context):
      return failure("parent_receipt_invalid")

  if not verifyTraceContext(receipt.trace_context):
    return failure("trace_context_invalid")

  if not verifyAuthorizationClass(receipt.authorization_class, aidoc.authorization_classes):
    return failure("authorization_class_invalid")

  return success("receipt_verified")