Agent Registry Specification

White Paper | 2026-03-27 | Status: draft

Agent Registry Specification

Executive Summary

The enterprise deployment of AI agents has advanced substantially faster than the governance infrastructure required to manage them safely. Organizations operating agent-based workflows in 2026 routinely encounter a set of interrelated problems that share a common root cause: there is no authoritative record of which agents exist, what they are permitted to do, how they came to exist in their current form, or whether their behavior at runtime matches the behavior that was reviewed and approved. Security teams cannot enforce least-privilege for entities they cannot enumerate. Audit teams cannot trace incidents to responsible parties without chain-of-custody records. Compliance teams cannot satisfy regulatory demands for AI system documentation when the documentation does not exist in any structured form. Platform teams cannot implement automated discovery and attestation when agents lack cryptographically verifiable identities.

This document defines the Agent Registry Specification: a comprehensive technical framework for the creation, maintenance, and consumption of authoritative agent records across the enterprise. The specification consists of five interconnected components. First, an Agent Profile Schema that defines the mandatory and optional fields required to describe an agent fully, including its unique identifier, capability declarations, tool access authorizations, permission boundaries, organizational ownership, deployment context, version lineage, and behavioral fingerprints. Second, a Trust Profile format that encodes an agent’s certification status, evaluated capability set, known limitations, and re-certification conditions in both machine-readable and human-readable forms, with explicit integration to the CSA STAR for AI certification levels. Third, a Lineage Tracking model that records the chain of custody from foundation model through agent framework to deployed agent and into runtime action logs, providing the forensic substrate necessary for incident response and compliance attestation. Fourth, Registration and Discovery Protocols that define how agents register themselves or are registered by their operators, how other agents and systems discover and verify agent records, and how attestations are used to establish trust dynamically. Fifth, an API Specification that provides RESTful endpoints for registry operations, discovery, and verification, with authentication and authorization requirements for each endpoint type.

The specification is explicitly designed for composition with existing standards rather than replacement of them. SPIFFE/SPIRE provides the workload attestation layer on which agent cryptographic identities are anchored. The IETF SCIM agents extension draft provides an existing interoperability model for cross-domain agent provisioning. W3C Verifiable Credentials provide the format for portable, cryptographically verifiable trust attestations. The CSA AI Controls Matrix and STAR for AI certification program provide the governance and audit framework within which registry data is consumed. Organizations that have already invested in any of these foundations will find the Agent Registry Specification additive rather than disruptive.

The central argument of this document is straightforward: agents are not users, and they are not traditional software services. They require an identity governance framework that reflects their distinctive characteristics — autonomous action, tool invocation authority, multi-agent delegation chains, behavioral variability, and dynamic deployment — while remaining compatible with the IAM infrastructure that organizations have already built. The Agent Registry Specification provides that framework.

1. Introduction: Why Agents Need a Registry

The governance of AI agents presents a challenge that is structurally different from any prior category of enterprise identity management. Human users have identities anchored in HR systems, authenticated through directory services, and governed by role-based access control policies that were designed with human cognition and accountability in mind. Service accounts and workload identities — managed through platforms like SPIFFE/SPIRE, HashiCorp Vault, or cloud provider IAM systems — were designed for deterministic software processes whose behavior is fully specified by their code and configuration. AI agents occupy neither category. They are autonomous, goal-directed entities whose behavior emerges from the interaction of a foundation model, a set of tools, a runtime context, and an objective — and whose actions can produce outcomes that no single developer or operator explicitly programmed [1].

This behavioral distinctiveness creates governance requirements that existing identity infrastructure was not designed to meet. A SPIFFE SVID tells a relying party that a workload is the specific process it claims to be, attested through node and workload checks; it says nothing about what that workload is authorized to reason over, which tools it may invoke, or whether its behavior was validated through independent testing [2]. A SCIM user record captures an employee’s organizational attributes and group memberships; it provides no model for recording capability declarations, behavioral fingerprints, or re-certification triggers. A traditional RBAC policy governs what actions an identity may request; it does not govern whether the agent making the request is operating within the behavioral envelope that was approved during its design. The gap between these existing standards and the governance requirements of agent-based systems is the space this specification addresses.

The urgency of that gap has been underscored by the security incidents of 2025 and early 2026. Investigations into agent-related incidents have repeatedly surfaced the same forensic obstacles: auditors cannot determine which version of an agent was running when an incident occurred; security teams cannot attribute a suspicious action to a specific deployment when multiple versions of the same agent were active simultaneously; compliance teams cannot demonstrate that an agent operating in a regulated workflow was using only the model and framework versions that were approved in the risk assessment. The OWASP Top 10 for Agentic Applications (2026) lists ASI03 (Identity and Privilege Abuse) and ASI10 (Rogue Agents) as two of the ten most dangerous risk categories for agentic systems precisely because the absence of authoritative agent records creates the conditions in which both attacks become possible [3]. A well-operated agent registry directly mitigates both risks by making agent identity authoritative, auditable, and revocable.

The design of the Agent Registry Specification reflects three architectural principles that emerged from analysis of the failure modes described above. The first is verifiability: every claim made by an agent about its identity must be cryptographically anchored to an attestation that an independent party can verify without trusting the agent’s self-report. The second is composability: the registry must integrate with existing IAM, identity federation, and certification infrastructure rather than requiring organizations to abandon investments in SPIFFE, SCIM, or directory services. The third is proportionality: the data model must be rich enough to support the full range of governance use cases — inventory, least-privilege enforcement, incident response, audit, and federated trust — without imposing an implementation burden so high that organizations defer registry deployment indefinitely. These principles informed every design decision in the sections that follow.

2. Agent Profile Schema

The Agent Profile is the fundamental unit of record in an agent registry. It is the structured representation of everything an organization knows about a specific deployed agent: its identity, capabilities, authorizations, ownership, provenance, and behavioral characteristics. A complete Agent Profile provides the data substrate for every downstream registry function — trust establishment, discovery, lineage tracking, and compliance attestation all depend on the accuracy and completeness of the profiles from which they draw.

The schema design follows the SCIM 2.0 extension model defined in RFC 7643 and the IETF draft SCIM agents extension (draft-abbey-scim-agent-extension-00), which introduces /Agents and /AgenticApplications as first-class SCIM resource types alongside the existing /Users and /Groups endpoints [4]. By grounding the Agent Profile Schema in the SCIM extension framework, the specification ensures interoperability with existing Identity Provider (IdP) infrastructure at organizations that have already deployed SCIM-compatible systems. The core SCIM schema handles universal identity attributes — display name, ownership, active status, organizational context — while the agent-specific extension handles the attributes that are unique to AI agents.

The following table defines the complete Agent Profile field set, organized by category:

Field Type Required Description
agentId URI Mandatory Globally unique agent identifier in SPIFFE URI format (spiffe://trust-domain/agent/name)
displayName String Mandatory Human-readable agent name
agentVersion String Mandatory Semantic version of this agent deployment
frameworkId URI Mandatory Identifier of the agent framework used (e.g., LangChain, CrewAI, AutoGen)
frameworkVersion String Mandatory Version of the agent framework
foundationModelId String Mandatory Identifier of the underlying foundation model (e.g., anthropic/claude-opus-4-6)
foundationModelVersion String Mandatory Pinned version or commit hash of the foundation model
capabilities Array[CapabilityDeclaration] Mandatory Structured enumeration of the agent’s declared functional capabilities
toolAccessList Array[ToolAuthorization] Mandatory Explicit list of tools and MCP servers the agent is authorized to invoke
permissionBoundaries PermissionBoundaryObject Mandatory Scope limits, data access constraints, and action prohibitions
owningOrganization OrganizationRef Mandatory Verifiable organizational identity of the agent’s operator
ownerEmail String Mandatory Accountable human owner email for governance and incident response
deploymentContext DeploymentContextObject Mandatory Environment, use case classification, operational boundary description
behavioralFingerprints Array[FingerprintRecord] Mandatory Hashes of expected behavioral profiles from pre-deployment testing
trustProfileRef URI Optional Reference to the agent’s Trust Profile in the registry
lineageRef URI Optional Reference to the agent’s Lineage Record in the registry
registrationTimestamp ISO 8601 Mandatory UTC timestamp of initial registry entry
lastModifiedTimestamp ISO 8601 Mandatory UTC timestamp of most recent profile update
status Enum Mandatory One of: active, suspended, deprecated, revoked
svid String Conditional SPIFFE Verifiable Identity Document (X.509 or JWT-SVID)
externalCertifications Array[CertificationRef] Optional References to STAR for AI or other third-party certifications
metadata Map[String, String] Optional Extensible key-value store for organization-specific attributes

The agentId field deserves particular explanation, as it serves as the anchor for the entire identity model. The specification requires SPIFFE URI format (spiffe://trust-domain/path) for agent identifiers because this format is both globally unique and directly interpretable by SPIFFE-aware infrastructure [2]. A trust domain corresponds to an organizational boundary — an enterprise’s internal SPIRE deployment, for example, would issue SVIDs under spiffe://acme-corp.internal/ — and the path component identifies the specific agent. This design allows agent identifiers to be directly verified by SPIRE workload APIs, creating a binding between the registry’s logical identity record and the cryptographic workload identity issued by the organization’s SPIFFE/SPIRE infrastructure.

The capabilities array uses a structured CapabilityDeclaration format rather than free text. Each capability declaration specifies a capabilityType from a controlled vocabulary (drawn from the AICM AA domain capability taxonomy), a description in natural language, and a scope that bounds the capability’s application. The controlled vocabulary approach ensures that capability declarations are machine-comparable across agents and organizations — a prerequisite for automated trust decisions — while the natural-language description preserves the expressiveness needed for human review.

The behavioralFingerprints array records the output of pre-deployment behavioral testing. Each FingerprintRecord contains a testSuiteId identifying the benchmark or evaluation harness used, a testSuiteVersion, a resultHash computed as a SHA-256 hash of the normalized test output, a testTimestamp, and a validatedBy field referencing the identity of the party that ran the evaluation. The hash-based approach does not require storing raw evaluation outputs in the registry — which may be large — but provides a tamper-evident record against which new behavioral evaluations can be compared. Divergence between a stored fingerprint and a fresh evaluation result is a trigger for re-certification review.

The following JSON Schema excerpt illustrates the structure of a complete Agent Profile conforming to this specification:

{
  "$schema": "https://csai.cloudsecurityalliance.org/schemas/agent-profile/v1.0",
  "agentId": "spiffe://acme-corp.internal/agents/contract-review/prod",
  "displayName": "Contract Review Agent — Production",
  "agentVersion": "2.4.1",
  "frameworkId": "https://langchain.com/framework",
  "frameworkVersion": "0.3.7",
  "foundationModelId": "anthropic/claude-opus-4-6",
  "foundationModelVersion": "2026-02-01",
  "capabilities": [
    {
      "capabilityType": "document_analysis",
      "description": "Reads and summarizes legal contracts up to 200 pages",
      "scope": "legal_documents"
    },
    {
      "capabilityType": "risk_flagging",
      "description": "Identifies non-standard clauses and flags for human review",
      "scope": "contract_risk"
    }
  ],
  "toolAccessList": [
    {
      "toolId": "spiffe://acme-corp.internal/mcp-servers/sharepoint-reader",
      "toolVersion": "1.2.0",
      "accessLevel": "read",
      "dataClassification": "confidential"
    }
  ],
  "permissionBoundaries": {
    "maxDataClassification": "confidential",
    "prohibitedActions": ["send_email", "create_calendar_event", "write_to_external_storage"],
    "allowedDataSources": ["sharepoint://legal-contracts"],
    "maxSessionDuration": "PT4H"
  },
  "owningOrganization": {
    "organizationId": "spiffe://acme-corp.internal/org",
    "displayName": "ACME Corporation",
    "verifiedDomain": "acme-corp.com"
  },
  "ownerEmail": "[email protected]",
  "deploymentContext": {
    "environment": "production",
    "useCase": "legal_contract_review",
    "operationalDescription": "Processes inbound vendor contracts for legal department review pipeline",
    "complianceScope": ["SOX", "GDPR"]
  },
  "behavioralFingerprints": [
    {
      "testSuiteId": "csai/contract-review-benchmark/v1.0",
      "testSuiteVersion": "1.0.2",
      "resultHash": "sha256:a3f9b2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1",
      "testTimestamp": "2026-03-15T09:00:00Z",
      "validatedBy": "spiffe://acme-corp.internal/agents/security-evaluator"
    }
  ],
  "registrationTimestamp": "2026-03-15T14:30:00Z",
  "lastModifiedTimestamp": "2026-03-15T14:30:00Z",
  "status": "active"
}

This schema is intentionally extensible. The metadata field provides an escape hatch for organization-specific attributes that do not belong in the core standard. Future versions of the specification will incorporate additional controlled vocabulary expansions as the industry develops consensus on capability taxonomies and compliance scope enumerations.

3. Trust Profiles

A Trust Profile is a structured attestation document that communicates what has been verified about an agent’s capabilities and behavior by an independent party. Where the Agent Profile records what an agent’s operator declares about it, the Trust Profile records what has been confirmed through formal evaluation. This distinction is architecturally significant: registry consumers making automated trust decisions — an orchestration platform deciding whether to delegate a task to an agent, a data access gateway deciding whether to grant an agent read access to a sensitive dataset — must be able to distinguish operator assertions from independently verified claims [5].

Trust Profiles exist in two complementary formats. The machine-readable format is a JSON document structured to conform with the W3C Verifiable Credentials Data Model v2.1, signed by the issuing certification authority using a Data Integrity proof [6]. The human-readable format is a structured prose document suitable for presentation in audit reports, vendor questionnaires, and governance reviews. The two formats carry identical information; the machine-readable format is optimized for automated consumption, while the human-readable format is optimized for practitioner review and regulatory disclosure. Both are stored in the registry and are returned together by the Trust Profile retrieval endpoint.

The Trust Profile carries the following structured fields:

Field Description
certificationStatus STAR for AI level achieved: none, level1_self_assessment, level2_iso42001, or level2_valid_ai_ted
certificationDate UTC date of most recent certification assessment
certificationExpiry UTC date at which certification lapses unless renewed
certifyingBody Identity of the organization or accredited auditor that issued the certification
evaluatedCapabilities Array of CapabilityAssessment records describing each capability’s verification result
knownLimitations Structured list of documented limitations identified during evaluation
certificationConditions Prerequisites that must remain true for the certification to remain valid
recertificationTriggers Events that invalidate the current certification and require re-evaluation
aiCaiqRef URI of the AI-CAIQ self-assessment submitted to the CSA STAR Registry
iso42001CertRef URI of the ISO/IEC 42001 certification, if applicable
behavioralTestResults Summary of benchmark performance across evaluated test suites
trustProfileVersion Semantic version of this Trust Profile record
vcProof W3C Verifiable Credential proof block (type, verification method, signature)

The certificationStatus field maps directly to CSA STAR for AI levels. STAR for AI Level 1, launched in October 2025, allows organizations to publish AI-CAIQ self-assessments to the CSA STAR Registry, establishing a transparent, standardized disclosure aligned with the AICM [7]. STAR for AI Level 2, launched November 2025, requires a Valid-AI-ted AI-CAIQ combined with an ISO/IEC 42001 certification — a combination first achieved by Microsoft and Zendesk in November 2025 [7]. The certificationStatus enumeration in the Trust Profile encodes these levels as machine-readable values, allowing downstream systems to enforce policies of the form “only agents with level2_valid_ai_ted certification may access regulated data.”

The recertificationTriggers field addresses one of the most operationally important questions in agent governance: when does an agent’s existing certification become invalid? The specification defines five standard trigger categories. A model update — any change to the foundationModelId or foundationModelVersion in the Agent Profile — invalidates the Trust Profile because the behavioral guarantees established during evaluation no longer apply to the new model version. A capability expansion — the addition of new entries to the capabilities or toolAccessList fields — invalidates the Trust Profile for the same reason. A behavioral divergence detection event — when a behavioral monitoring system reports that the agent’s runtime behavior has deviated significantly from its stored behavioralFingerprints — triggers mandatory re-evaluation. A security incident attributed to the agent triggers suspension pending investigation and re-evaluation. Finally, an elapsed certification period — the certificationExpiry date — requires proactive renewal to maintain certification continuity.

The evaluatedCapabilities array provides granular attestation at the capability level rather than only at the agent level as a whole. Each CapabilityAssessment record specifies the capability being assessed, the evaluation methodology used, the result (one of verified, partially_verified, unverified, contradicted), the specific limitations identified, and the boundary conditions under which the verification result holds. This structure allows a Trust Profile to convey nuanced attestations such as “document analysis capability is verified for English-language contracts up to 150 pages; performance degrades for non-English documents and has not been independently evaluated for contracts exceeding 200 pages.” That level of specificity matters for downstream consumers making fine-grained trust decisions.

4. Lineage Tracking

Lineage tracking is the mechanism by which an agent registry maintains a verifiable record of an agent’s provenance — the complete chain of custody from the foundation model that underlies its reasoning, through the framework that structures its behavior, to the deployed instance that takes actions, and into the specific runtime actions it executes. This chain of custody serves the same function in agent governance that a software bill of materials (SBOM) serves in software supply chain security: it provides the forensic substrate necessary to answer “what was running, and exactly how did it come to be that way?” when an incident investigation or compliance audit demands accountability.

The lineage model is structured as a directed acyclic graph (DAG) in which each node represents a versioned artifact or runtime event, and each edge represents a derivation or invocation relationship. Four tiers of the graph correspond to four distinct stages of the agent lifecycle.

The Foundation Model tier records the identity and version of the underlying large language model: its model identifier, the version or checkpoint used, the training data cutoff, the safety evaluation results that the model provider published in its system card, and the organizational trust decision — whether the foundation model is approved for use within the organization’s risk tolerance. Foundation model records are not owned by the deploying organization; they reference externally published system cards and provenance records from the model provider [8]. The registry links to these external records rather than duplicating them.

The Agent Framework tier records the framework and tooling layer that transforms the raw foundation model into a structured agent: the framework identifier and version, the specific orchestration logic or agent architecture pattern used, the tool invocation configuration, and any fine-tuning or system-prompt configuration that shapes the model’s behavior for the specific use case. This tier captures the “build” of the agent — the decisions made by the developer that determine the agent’s behavioral envelope before any runtime input.

The Deployed Agent tier corresponds to the Agent Profile itself: the specific instance of an agent framework configuration that was reviewed, approved, and registered, with the behavioral fingerprints that attest to its behavior at the time of evaluation. This is the tier at which the registry’s authoritative record resides, and it is the node to which all governance decisions — certification, authorization, incident attribution — are anchored.

The Runtime Action tier records individual action events at a level of granularity sufficient for forensic reconstruction: tool invocations, data accesses, agent-to-agent delegations, and output generation events. Runtime action records are not stored in full within the registry itself — the volume would be prohibitive — but the registry maintains a canonical schema for runtime action events and stores references to the external log stores where full records are held. Each runtime action record includes a parentAgentId referencing the agent profile that generated it, a sessionId, a actionType, an actionTimestamp, and a logRef URI pointing to the complete event in the organization’s SIEM or observability platform.

The following table illustrates the lineage chain for the contract review agent example from Section 2:

Tier Artifact Version Verified By
Foundation Model anthropic/claude-opus-4-6 2026-02-01 Anthropic System Card (external ref)
Agent Framework LangChain 0.3.7 Internal build verification + SBOM
Deployed Agent Contract Review Agent — Production 2.4.1 ACME Security Team (behavioral fingerprint)
Runtime Actions Tool invocations to SharePoint reader Per-session ACME SIEM (log reference)

The lineage DAG becomes most valuable during incident response. When a security team needs to investigate whether an agent behaved anomalously during a specific session, they can traverse the graph from the incident-triggering runtime action back to the deployed agent profile, then to the framework version, then to the foundation model, identifying at each tier whether a known vulnerability, misconfiguration, or policy violation contributed to the incident. This traversal is possible only if lineage records were created and linked at deployment time — not retroactively after an incident. The specification therefore treats lineage record creation as a mandatory step in the agent registration workflow, not an optional governance enhancement.

Cross-organizational lineage presents an additional challenge: when an agent delegates a subtask to an agent operated by a different organization, the lineage chain crosses a trust domain boundary. The specification handles this through lineage attestation references rather than direct record access. When Organization A’s orchestrator delegates to Organization B’s subagent, Organization A’s runtime action log records the delegation event with a reference to Organization B’s agent identifier and a verifiable claim — signed by Organization B’s registry — that the invoked agent was operating at a specific version and certification status at the time of delegation. This model preserves lineage continuity across organizational boundaries while respecting each organization’s right to maintain its own registry as the authoritative source for its agents.

5. Registration and Discovery Protocols

The registration protocol defines the process by which an agent is enrolled in the registry — creating the authoritative record that downstream consumers will rely on for trust decisions. The specification defines two registration paths: operator-initiated registration and automated self-registration, both of which produce identical Agent Profile records but differ in their authentication flow and the degree of human review they require.

Operator-initiated registration is the default for production agents. In this flow, a human operator — typically a platform engineer, AI developer, or security team member — submits an Agent Profile document through the registry API (see Section 6), authenticated with their personal or service account credentials. The registry validates the submitted profile against the Agent Profile Schema, checks that the agentId conforms to SPIFFE URI format and that the specified trust domain is one the organization is authorized to issue identities under, and verifies that the submitting operator has the governance permission to register agents for the specified deployment context. The registry then issues an SVID for the agent through the organization’s SPIRE deployment, binding the logical registry record to a cryptographic workload identity. The issued SVID is returned to the operator and stored as the svid field of the Agent Profile.

Automated self-registration is permitted for agents operating within a pre-approved agent framework that has been granted registration authority by the organization. In this flow, an agent framework issues a registration request on behalf of a newly instantiated agent. The request must be signed with the framework’s own SVID — which was itself registered and authorized for self-registration by a human operator — and must include a complete, pre-validated Agent Profile document. The registry verifies the framework’s SVID, confirms that the framework is authorized for self-registration, validates the submitted profile, and issues an SVID for the new agent. Self-registration is subject to tighter constraints than operator-initiated registration: the framework may only register agents whose capabilities and toolAccessList fields are strict subsets of the framework’s own authorized scope, preventing capability escalation through automated registration.

Discovery is the mechanism by which agents, orchestration platforms, and access control systems locate registry records for agents they wish to interact with. The specification defines three discovery patterns. The first is direct identifier lookup: a consumer that already knows an agent’s agentId can retrieve the full Agent Profile using the registry’s GET endpoint (see Section 6), with the response including the agent’s current status, trust profile reference, and SVID for verification. The second is capability-based search: a consumer that needs to delegate a task to an agent with specific capabilities submits a search query specifying one or more capability types, data classification levels, tool access requirements, and minimum certification levels, and receives a list of matching agent profiles ordered by trust level. The third is trust-domain-based federation: a consumer operating in one trust domain that needs to discover agents registered by a different organization queries a federated discovery endpoint that aggregates registry records from participating organizations’ registries, subject to the cross-organizational trust agreements established through the federation protocol.

Attestation-based trust establishment is the protocol by which one agent verifies another’s registry record before accepting a delegation or sharing data. When Agent A receives a request from Agent B, the protocol requires Agent B to present its SVID alongside the request. Agent A’s runtime must validate the SVID cryptographically — verifying the chain of trust back to the issuing SPIRE server’s root CA — and then query the registry using the SVID’s embedded agentId to retrieve Agent B’s current status and Trust Profile. If Agent B’s status is active and its Trust Profile meets Agent A’s configured trust requirements (such as minimum certification level), the interaction proceeds. If the status is suspended or revoked, Agent A must reject the request and log the attempted interaction. This protocol implements the OWASP ASI recommendation for inter-agent authentication and directly mitigates ASI07 (Insecure Inter-Agent Communications) [3].

6. API Specification

The Agent Registry API is a RESTful interface that provides programmatic access to registry operations for agents, orchestration platforms, operator tooling, and compliance systems. All endpoints require authentication via bearer tokens issued by the organization’s identity provider, with the specific scopes required varying by operation sensitivity. All requests and responses use application/json content type. All timestamps are ISO 8601 format in UTC. The API conforms to OpenAPI 3.1 specification, with a complete machine-readable schema published separately.

The following table defines the complete API surface:

Method Path Description Required Auth Scope
POST /v1/agents Register a new agent; body is a complete Agent Profile document registry:agents:write
GET /v1/agents/{agentId} Retrieve a full Agent Profile by SPIFFE URI identifier registry:agents:read
PUT /v1/agents/{agentId} Replace an existing Agent Profile (triggers re-certification review if material fields change) registry:agents:write
PATCH /v1/agents/{agentId} Update specific fields of an Agent Profile registry:agents:write
DELETE /v1/agents/{agentId} Deactivate an agent (sets status to deprecated; records are retained for audit purposes) registry:agents:admin
POST /v1/agents/{agentId}/revoke Immediately revoke an agent (sets status to revoked, invalidates SVID) registry:agents:admin
POST /v1/agents/{agentId}/suspend Temporarily suspend an agent pending investigation registry:agents:admin
GET /v1/agents/{agentId}/trust-profile Retrieve the Trust Profile associated with an agent registry:agents:read
PUT /v1/agents/{agentId}/trust-profile Submit or update a Trust Profile (restricted to certification authorities) registry:certifications:write
GET /v1/agents/{agentId}/lineage Retrieve the full lineage record for an agent registry:lineage:read
POST /v1/agents/{agentId}/lineage/events Append a runtime action event reference to the lineage record registry:lineage:write
GET /v1/agents Search and discover agents; supports query parameters for capability, status, certification, and organizational scope registry:agents:read
POST /v1/verify Verify an agent’s current status and Trust Profile given an SVID; used by relying parties during inter-agent trust establishment registry:verify
GET /v1/federation/trust-domains List federated trust domains whose agent records are accessible registry:federation:read
POST /v1/federation/trust-domains Register a new federated trust domain relationship registry:federation:admin
GET /v1/audit/events Retrieve registry audit log events for compliance reporting registry:audit:read

The /v1/verify endpoint deserves detailed description because it is the most security-critical operation in the API. It accepts a request body containing an SVID (X.509 DER or JWT format), a requestorId (the SPIFFE URI of the agent making the verification request), and an optional requiredTrustLevel specifying the minimum STAR for AI certification level acceptable to the requestor. The endpoint validates the SVID against the SPIRE root CA bundle for the relevant trust domain, looks up the associated Agent Profile, and returns a response containing the current status, Trust Profile summary, certification level, and a registry-signed attestation asserting the verification result. The attestation is itself signed with the registry’s SVID, allowing the requestor to present it as evidence of an authoritative trust check if challenged downstream. The endpoint does not return the full Agent Profile to prevent information disclosure to parties that have only registry:verify scope.

The search endpoint at GET /v1/agents supports the following query parameters: capability (one or more capability type values from the controlled vocabulary), certificationLevel (minimum Trust Profile certification level), status (one of active, suspended, deprecated, revoked), organizationId (filter to agents owned by a specific organization), environment (filter by deployment context environment), dataClassification (filter by maximum permitted data classification), page and pageSize for pagination, and sortBy for result ordering. The search response is paginated with a maximum of 100 results per page and includes a total count. All search operations are logged in the registry audit trail regardless of whether the requestor has registry:audit:read scope, ensuring that discovery activity is visible to security teams.

Rate limiting is enforced at the operator scope level rather than the individual endpoint level. The default rate limit is 1,000 requests per minute for read operations and 100 requests per minute for write operations, with separate limits for the /v1/verify endpoint (10,000 requests per minute) to accommodate the high-frequency verification calls that real-time agent orchestration requires. Organizations may request higher limits through the registry administration interface.

7. Privacy and Data Protection

Agent registry records contain information that is sensitive across multiple dimensions. The Agent Profile captures details about an organization’s AI capabilities and deployment strategy that constitute competitive intelligence — a well-populated registry reveals which business processes have been automated, which foundation models are trusted, and what data access the organization’s agents have been granted. The behavioral fingerprints and Trust Profile data reveal the results of security evaluations that could assist attackers in identifying gaps. The ownerEmail field and organizational identity attributes are personal data under most data protection regulations. The lineage records contain references to audit logs that may themselves contain sensitive operational data. Governing the privacy of registry data is therefore not a secondary concern but a first-order design requirement.

The specification establishes a data minimization principle that governs what is stored in the registry versus what is maintained in external systems with registry references. The registry stores the Agent Profile, Trust Profile, and lineage DAG structure as defined in this document. It does not store the raw outputs of behavioral evaluations, the content of agent sessions, the text of tool invocations, or the data processed by agents in the course of their operations. All such data remains in the organization’s own logging and observability infrastructure, with only hashed references and URIs stored in the registry. This separation limits the sensitivity of registry data while preserving its utility as a governance index.

Access to registry data is governed by scope-based authorization as described in Section 6. The specification recommends a three-tier access model. Internal operators — platform engineers, AI developers, and security team members within the registry-owning organization — receive read access to all profiles within their organizational scope and write access to profiles they own. Registry administrators receive the full complement of scopes including registry:agents:admin and registry:audit:read. Federated external parties — agents and systems from partner organizations accessing records through federation — receive access only to the publicly declared fields of Agent Profiles and Trust Profiles for agents that their trust domain has been explicitly authorized to discover. The behavioralFingerprints array and full permissionBoundaries details are excluded from federated responses by default.

The ownerEmail field presents a specific data protection consideration. Under the GDPR and equivalent frameworks, this field is personal data, and its storage in the registry is subject to processing lawfulness, purpose limitation, and retention requirements [9]. The specification recommends that registry deployments in regulated jurisdictions implement a pseudonymization option in which the ownerEmail is replaced by an opaque owner identifier that can be resolved through the organization’s HR or identity system by authorized personnel but does not expose the email address in standard API responses. The raw email address is retained in an access-controlled internal store linked to the owner identifier.

Retention and deletion policies must address the tension between privacy rights and audit requirements. Agent Profile records are retained for the longer of the agent’s active deployment period plus 24 months, or the applicable regulatory retention period for the jurisdiction and data classification involved. Deletion requests — including right-to-erasure requests under GDPR where applicable — are handled by pseudonymizing personal data fields rather than deleting the full profile, because the non-personal fields (agent identifier, capability declarations, lineage structure) may be required for ongoing audit proceedings. Registry deployments should document this retention approach in their data protection impact assessments.

8. Implementation Guidance

Organizations approaching agent registry deployment for the first time will encounter a spectrum of implementation complexity that depends heavily on the maturity of their existing IAM and SPIFFE infrastructure. For organizations that have already deployed SPIRE for workload identity, the registry’s identity model is largely an extension of existing practice: agent identifiers follow the same SPIFFE URI format as existing workload identities, and issuance of SVIDs for registered agents uses the same SPIRE APIs and attestation mechanisms already in production. For organizations without SPIRE, the registry deployment should be preceded by, or conducted concurrently with, a SPIRE deployment scoped at minimum to the environments where AI agents operate.

The recommended phased implementation follows four stages. In Phase 1 (Foundation), the organization deploys the registry infrastructure, configures the SPIFFE/SPIRE integration, and establishes the operator authentication and authorization model. No agents are registered in Phase 1; the objective is to validate the infrastructure and ensure that the registration and SVID issuance workflows function correctly. Phase 1 should also include a policy decision about which agent profile fields will be mandatory in the organization’s deployment, recognizing that the specification defines mandatory fields at the standards level but organizations may add additional mandatory fields for compliance purposes.

In Phase 2 (Inventory), the organization conducts a systematic inventory of existing deployed agents and registers them through operator-initiated registration. This phase will typically surface the discovery that many agents lack the structured metadata required to populate complete profiles — capability declarations, behavioral fingerprints, and permission boundaries are often implicit in code rather than documented. The registry onboarding process doubles as a documentation exercise, forcing clarity about what each agent is actually authorized to do. Organizations should expect Phase 2 to require significant coordination between development teams, security teams, and AI governance personnel.

In Phase 3 (Enforcement), the organization begins using registry data to enforce policy. Orchestration platforms are configured to perform registry lookups before delegating tasks to agents. Access control systems are updated to require valid, active SVID credentials from registered agents before granting data access. Monitoring systems are configured to alert on agent activity from unregistered identities. Phase 3 marks the transition from the registry as a documentation system to the registry as an active security control.

In Phase 4 (Certification), the organization pursues Trust Profiles for its agents, beginning with the agents that handle the most sensitive data or the most consequential decisions. STAR for AI Level 1 self-assessments are achievable without third-party involvement and provide an immediate governance signal. Organizations seeking STAR for AI Level 2 will need to coordinate with an accredited auditor for the Valid-AI-ted AI-CAIQ assessment and pursue ISO/IEC 42001 certification if they have not already done so.

Federation between organizational registries enables the cross-organizational trust networks that multi-enterprise agent deployments require. Two organizations that wish to allow their agents to interact with mutual trust establish a federation agreement by exchanging their SPIRE root CA bundles, registering each other’s trust domains in their respective registries, and agreeing on the minimum certification levels and scope constraints that apply to federated agent interactions. Once federation is established, agents in each organization can discover and verify agents from the other organization through the federated discovery endpoint without requiring bilateral API key exchange or manual trust configuration for each new agent pair.

Integration with existing enterprise IAM is handled primarily through the SCIM agents extension interface. Organizations whose IdP (Okta, Microsoft Entra, Ping Identity) supports the SCIM 2.0 protocol can configure the registry as a SCIM service provider, allowing the IdP to provision, update, and deprovision agent records through the standard SCIM protocol. This integration is particularly valuable for organizations that use IdP-governed lifecycle management: the same joiner-mover-leaver automation that governs human user accounts can be extended to govern agent lifecycle events, including the automated suspension of an agent when its owning team is dissolved or its owner leaves the organization. The IETF draft-abbey-scim-agent-extension specifically defines the /Agents resource type to enable this integration pattern [4].

9. Framework Alignment

The Agent Registry Specification does not exist in isolation from the broader ecosystem of AI security frameworks and identity standards. Each component of the specification draws from and aligns with established frameworks, and organizations that have already made investments in those frameworks will find specific touchpoints that allow registry deployment to build on rather than duplicate existing work. The following table maps each major registry function to its primary alignment point across five frameworks:

Registry Function AICM Domain SPIFFE/SPIRE Alignment SCIM Alignment STAR for AI Integration
Agent unique identifier (SPIFFE URI) IAM-05: Non-Human Identity Management SVID X.509/JWT; issued by SPIRE server after node + workload attestation id attribute on /Agents resource; uniqueness enforced by schema Referenced in AI-CAIQ control AI-IAM-05; required for Level 2 inventory
Capability declarations AA-03: Agent Capability Governance Not directly; SVID path can encode capability scope roles and applications attributes on Agent schema AI-CAIQ control AI-AA-03; Level 1 self-assessment field
Tool access list AA-07: Tool Authorization and Scope SPIFFE bundle federation maps to inter-service authorization protocols attribute (type: MCP-Server, A2A, OpenAPI) AI-CAIQ control AI-AA-07; required for Level 2 audit
Permission boundaries IAM-09: Least Privilege for AI Workloads SPIRE registration entry dns_sans and selector constraints Not directly; extensible via enterprise schema extension AI-CAIQ control AI-IAM-09; Level 2 auditor-reviewed
Behavioral fingerprints MS-04: Model Behavioral Validation Not directly; fingerprint hash can be embedded in SVID custom claims Not in base schema; custom attribute extension recommended AI-CAIQ control AI-MS-04; Valid-AI-ted process validates
Trust Profile / Certification status GRC-08: AI Governance Assurance Not directly; certification level can be encoded in JWT-SVID claims Not in base schema; custom attribute recommended Core STAR for AI output; Level 1 = self-assessment, Level 2 = third-party
Lineage tracking STA-03: AI Supply Chain Transparency SVID chain of trust provides cryptographic lineage for workload identities Not in base schema; lineage reference as custom attribute AI-CAIQ control AI-STA-03; Level 2 evidence package
Registration / Deregistration IAM-01: Identity Lifecycle Management SPIRE entry creation/deletion corresponds to workload identity lifecycle SCIM CRUD operations on /Agents resource type AI-CAIQ control AI-IAM-01; inventory completeness assessed at Level 1
Discovery and search AA-01: Agent Inventory and Classification SPIRE server workload entry listing provides enumeration capability SCIM GET /Agents with filter expressions AI-CAIQ control AI-AA-01; complete inventory required for Level 1
Federated trust SEF-02: Security Ecosystem Federation SPIFFE bundle federation across trust domains SCIM cross-domain identity management (RFC 7644 federation) Not currently in AI-CAIQ; recommended future control addition
Audit logging LOG-02: Security Event Logging SPIRE audit events for SVID issuance and revocation SCIM protocol audit log requirements AI-CAIQ control AI-LOG-02; Level 2 evidence requirement
Revocation / Suspension IAM-06: Access Revocation and Suspension SPIRE SVID TTL expiration + explicit revocation via delete SCIM active: false attribute on Agent resource AI-CAIQ control AI-IAM-06; revocation response time audited at Level 2

The MAESTRO framework alignment is also relevant. MAESTRO’s seven-layer architecture maps to registry functions as follows: the Foundation Model tier of lineage tracking corresponds to MAESTRO Layer 1; the Agent Framework tier corresponds to Layer 3; the Deployed Agent profile and behavioral fingerprints correspond to Layer 5 (Evaluation and Observability); the permission boundaries and tool access list enforcement correspond to Layer 6 (Security and Compliance); and the federation and discovery protocols correspond to Layer 7 (Agent Ecosystem) [10]. Organizations using MAESTRO for threat modeling their agent ecosystems will find that the registry provides the data substrate for Layer 5 and Layer 7 security controls in particular.

The OWASP ASI Top 10 (2026) alignment is direct. The agent registry directly mitigates ASI03 (Identity and Privilege Abuse) by making agent identities authoritative and revocable rather than asserted and unverified. It mitigates ASI07 (Insecure Inter-Agent Communications) by providing the attestation verification protocol described in Section 5 that agents use to verify each other’s identity and current status before accepting delegations. It mitigates ASI10 (Rogue Agents) by establishing the negative space: any agent that cannot present a valid SVID matching a current, active registry record is by definition unregistered and should be treated as potentially rogue. The registry does not directly mitigate ASI01 (Agent Goal Hijack) or ASI06 (Memory and Context Poisoning), as these are primarily prompt-layer attacks that operate within the behavioral envelope of a registered agent rather than exploiting the absence of identity governance [3].

References

[1] OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications 2026,” OWASP Foundation, 2026. Available: https://owasp.org/www-project-top-10-for-large-language-model-applications/

[2] SPIFFE Project, “SPIFFE Overview,” Cloud Native Computing Foundation, 2025. Available: https://spiffe.io/docs/latest/spiffe-about/overview/

[3] OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications: ASI03, ASI07, ASI10,” OWASP Foundation, 2026.

[4] M. Abbey and R. S. Cohen (Okta), “SCIM Agents and Agentic Applications Extension,” IETF Internet-Draft draft-abbey-scim-agent-extension-00, 2025. Available: https://www.ietf.org/archive/id/draft-abbey-scim-agent-extension-00.html

[5] WorkOS, “SCIM for AI: Inside the new IETF draft for agent and agentic application provisioning,” 2025. Available: https://workos.com/blog/scim-agents-agentic-applications

[6] W3C, “Verifiable Credentials Data Model v2.1,” W3C Working Draft, 2025. Available: https://w3c.github.io/vc-data-model/

[7] Cloud Security Alliance, “Cloud Security Alliance Announces Availability of STAR for AI Level 2 and Valid-AI-ted for AI,” CSA Press Release, November 20, 2025. Available: https://cloudsecurityalliance.org/press-releases/2025/11/20/cloud-security-alliance-announces-availability-of-star-for-ai-level-2-and-valid-ai-ted-for-ai

[8] Anthropic, “System Card: Claude Opus 4 and Claude Sonnet 4,” Anthropic, May 2025. Available: https://www.anthropic.com/claude-4-system-card

[9] European Parliament and Council, “Regulation (EU) 2016/679 (General Data Protection Regulation),” Official Journal of the European Union, 2016.

[10] Cloud Security Alliance, “MAESTRO: Multi-Agent Environment, Security, Threat, Risk, and Outcome,” CSA Research, February 2025.

[11] SPIFFE Project, “SPIRE Concepts,” Cloud Native Computing Foundation, 2025. Available: https://spiffe.io/docs/latest/spire-about/spire-concepts/

[12] P. Wahl, “System for Cross-domain Identity Management: Agentic Identity Schema,” IETF Internet-Draft draft-wahl-scim-agent-schema-01, 2025. Available: https://datatracker.ietf.org/doc/draft-wahl-scim-agent-schema/

[13] Cloud Security Alliance, “AI Controls Matrix (AICM) v1.0,” CSA Research, July 2025.

[14] NIST, “Artificial Intelligence Risk Management Framework (AI RMF 1.0),” NIST AI 100-1, January 2023.

[15] TrueFoundry, “What is AI Agent Registry — A Complete Guide,” 2025. Available: https://www.truefoundry.com/blog/ai-agent-registry

[16] B. Srinivasan et al., “A Survey of AI Agent Registry Solutions,” arXiv:2508.03095, 2025. Available: https://arxiv.org/html/2508.03095v1

[17] Red Hat, “What are SPIFFE and SPIRE?” Red Hat Topics, 2025. Available: https://www.redhat.com/en/topics/security/spiffe-and-spire

[18] Cloud Security Alliance, “Announcing the AI Controls Matrix and ISO 42001 Mapping and the Roadmap to STAR for AI 42001,” CSA Blog, August 20, 2025. Available: https://cloudsecurityalliance.org/blog/2025/08/20/announcing-the-ai-controls-matrix-and-iso-iec-42001-mapping-and-the-roadmap-to-star-for-ai-42001