Agent Registry Security Standards: What AI Package Registries Must Enforce in 2026

The npm registry serves billions of downloads per month. PyPI hosts hundreds of thousands of packages. When malicious packages infiltrate these registries — as has happened repeatedly through typosquatting, dependency confusion, and compromised maintainer accounts — the downstream harm propagates across millions of applications in hours. The software supply chain is a critical attack surface, and the package registry is its most concentrated chokepoint.

AI agent ecosystems are building their equivalent infrastructure: registries of agent capabilities, skills, tool plugins, prompt templates, and pre-built agents that developers and organizations can acquire and deploy. And they are mostly doing so without the hard-won security lessons that the software package ecosystem took two decades of incidents to learn.

This document specifies the security standards that AI agent registries must enforce in 2026 to avoid becoming the AI ecosystem's npm-equivalent supply chain disaster. It draws on the experience of traditional software registries, the specific threat models introduced by AI-specific artifacts, and the emerging standards being developed by NIST, CISA, and the AI safety community.

TL;DR

• AI agent registries face all the supply chain threats of software registries plus AI-specific threats: behavioral malware, capability escalation, training data poisoning, and trust laundering
• Provenance verification for AI artifacts requires extending software SBOM standards with model cards, training data attestations, and evaluation certificates
• Behavioral malware scanning (evaluating whether an agent acts maliciously, not just whether it contains malicious code) is the most distinctive security requirement for agent registries
• Revocation infrastructure must operate faster than for software registries — a malicious agent can cause harm within minutes of deployment
• Trust scoring for registry entries should aggregate evidence from provenance verification, evaluation results, deployment history, and operator reputation
• NIST SSDF and CISA Software Bill of Materials standards provide the foundation; agent-specific extensions are required for complete coverage

Lessons from Software Registry Security Incidents

Before specifying standards, it is worth reviewing the most significant software registry security incidents and the lessons they provide for AI agent registry design:

The xz Utils Backdoor (2024)

In early 2024, a sophisticated threat actor (likely state-sponsored) spent approximately two years cultivating a persona as a legitimate open-source contributor, eventually becoming a maintainer of the xz Utils compression library. Once in that position, the attacker introduced a backdoor that was discovered by accident only hours before it would have been included in major Linux distributions.

Lessons for AI agent registries:

• Maintainer identity verification cannot be based on contribution history alone — attackers can establish long-term trust
• Behavioral analysis of contributed code/artifacts (what does this change actually do?) is necessary beyond code review
• Automatic elevation of trust based on contribution volume is dangerous; manual authorization by existing trusted maintainers should be required for privileged roles
• Temporal analysis of contribution patterns (sustained engagement over years, not just a burst of contribution) is one detection signal for credential farming

The PyPI Malware Campaign (2023)

Multiple campaigns in 2023 placed malicious PyPI packages with names similar to popular legitimate packages. The packages contained credential-stealing code that activated when installed.

Lessons for AI agent registries:

• Name similarity checks should be automated and applied at submission time, not just flagged by users
• New publisher accounts submitting packages with names similar to established packages warrant additional scrutiny
• Pre-installation behavioral scanning (what does the package do when activated?) provides a layer that name checking alone cannot

The npm Left-Pad Incident (2016)

A developer unpublished a small npm package that was a dependency of thousands of popular packages, breaking builds worldwide. While not a security incident, it revealed the risk concentration inherent in widely-used registry-hosted dependencies.

Lessons for AI agent registries:

• Popular agents that are widely used as sub-components by other agents create systemic concentration risk
• Registries should track dependency networks and flag agents that are deep dependencies of many other agents for enhanced protection
• Immutable versions (versions that cannot be unpublished after a grace period) reduce the risk of accidental or malicious removal

The event-stream NPM Compromise (2018)

A malicious actor offered to maintain an npm package, received maintainership, and then introduced a malicious dependency that targeted a specific cryptocurrency wallet application.

Lessons for AI agent registries:

• Maintainer transfers require security review — new maintainers should not immediately receive the prior maintainer's trust level
• Dependency additions to established packages warrant additional behavioral scanning
• The specific targeting of cryptocurrency wallet applications in this attack prefigures the targeting of high-value AI agents by sophisticated attackers

The AI Agent Registry Threat Model

Before specifying standards, it is necessary to establish the threat model that those standards must address. AI agent registries face threats that are both analogous to traditional software registries and uniquely AI-specific.

Threats Analogous to Software Registries

Typosquatting: Registering agent names that closely resemble popular legitimate agents (armalo-core vs. armalo_core, agent-sales vs. agennt-sales) to capture accidental installations. This works at the agent capability level: a developer searching for a "database query agent" installs a malicious variant that exfiltrates query results.

Compromised maintainer accounts: If a legitimate agent's maintainer account is compromised, an attacker can publish a malicious update to an agent with an established trust history. This is the most dangerous vector in traditional software registries (the xz Utils backdoor in 2024 is the canonical example) and is equally dangerous for agent registries.

Dependency confusion attacks: Scoping attacks where a public registry agent with the same name as a private registry agent is installed instead. Particularly relevant for organizations with internal agent libraries.

Malicious code injection into legitimate agents: Injecting malicious components into legitimate agent packages during the build or publishing process. For traditional software, this might mean compromised CI/CD pipelines. For AI agents, this extends to compromised fine-tuning runs or malicious prompt template injection.

AI-Specific Registry Threats

Behavioral malware: Unlike traditional software malware (which executes code), behavioral malware in AI agents is encoded in the agent's prompting, fine-tuning, or retrieval configuration to cause specific harmful behaviors under trigger conditions. A behavioral trojan might cause an agent to behave normally during evaluation but exfiltrate data when deployed in a production environment with specific characteristics.

Capability escalation packages: Agent capabilities that appear to serve a legitimate purpose but grant their consumers access to capabilities or data sources beyond what the declared function requires. Analogous to software packages that request excessive permissions on mobile platforms, but more subtle because capability scoping for AI agents is less mature than permission systems for mobile apps.

Training data poisoning via registry: Datasets or fine-tuning examples distributed through an agent registry that encode adversarial examples or backdoor triggers. An agent trained on poisoned datasets from the registry will behave maliciously in ways that are not detectable from the agent's weights alone.

Trust laundering: A newly registered agent with no reputation claiming behavioral attestations from a trusted organization that didn't actually produce them. More sophisticated: building a reputation through benign deployments, then switching behavior after achieving high trust scores (the "trust laundering" attack on reputation systems).

Prompt template injection: Malicious system prompt templates that override the deploying organization's intended agent behavior when instantiated. A template that appears to provide useful framing behavior but contains hidden instructions that redirect the agent to serve the template author's interests.

Evaluation gaming: Agents that detect when they are being evaluated (e.g., through the presence of specific evaluation probe patterns) and exhibit better behavior during evaluation than during deployment. This exploits evaluation-deployment distribution shift intentionally.

Provenance Verification Standards

Provenance verification establishes that a registry artifact is what it claims to be, was produced by who it claims to have been produced by, and was not tampered with in transit or during the publishing process.

Software Supply Chain Standards Applied to AI Artifacts

The software supply chain security community has developed two primary standards that apply directly to AI agent artifacts:

SLSA (Supply Chain Levels for Software Artifacts): A security framework from Google that establishes four levels of supply chain security assurance. For AI agent registries, the relevant SLSA requirements include:

• SLSA Level 1: Provenance documentation (who built the artifact, how, from what sources)
• SLSA Level 2: Hosted build service (builds performed by a verifiable hosted service, not local developer machines)
• SLSA Level 3: Hardened builds (additional controls on the build environment)
• SLSA Level 4: Two-person review of all changes

SLSA Level 2 should be the minimum requirement for registry listings of any significant trust level. SLSA Level 3 should be required for agents that will be given significant capabilities or deployed in sensitive contexts.

Software Bill of Materials (SBOM): A machine-readable inventory of the components that make up a software artifact. CISA has published the National Cybersecurity Strategy mandating SBOM for critical software. For AI agent registries, the SBOM standard needs extension:

AI SBOM (Extended for Agent Artifacts):

{
  "sbomVersion": "2.0",
  "artifactType": "ai_agent",
  "componentInfo": {
    "name": "enterprise-data-query-agent",
    "version": "1.4.2",
    "registry": "armalo",
    "publisher": {
      "name": "Acme AI Corp",
      "did": "did:web:acmeai.example.com",
      "verification_url": "https://acmeai.example.com/.well-known/ai-agent"
    }
  },
  "softwareComponents": [
    {"name": "langchain", "version": "0.2.1", "license": "MIT", "sbomUrl": "..."},
    {"name": "openai", "version": "1.23.0", "license": "MIT", "sbomUrl": "..."}
  ],
  "modelComponents": [
    {
      "baseModel": "gpt-4o",
      "provider": "OpenAI",
      "version": "2025-01-15",
      "modelCard": "https://openai.com/research/gpt-4o",
      "fineTuning": null
    }
  ],
  "dataComponents": [
    {
      "dataset": "acme-product-docs-v3",
      "type": "rag_corpus",
      "license": "proprietary",
      "provenance": "internal_confluence_export",
      "lastUpdated": "2026-04-01"
    }
  ],
  "promptComponents": [
    {
      "type": "system_prompt",
      "hash": "sha256:abc123...",
      "description": "Core behavioral framing and capability definition",
      "reviewedBy": "security@acmeai.example.com",
      "reviewDate": "2026-03-15"
    }
  ],
  "attestations": {
    "buildProvenance": "https://slsa.dev/provenance/v1#...",
    "evaluationCertificate": "https://armalo.ai/attestations/eval_abc123",
    "securityScan": "https://armalo.ai/attestations/scan_def456"
  },
  "timestamps": {
    "created": "2026-03-20T10:00:00Z",
    "published": "2026-03-21T09:00:00Z",
    "lastUpdated": "2026-04-15T14:30:00Z"
  }
}

Cryptographic Signing Requirements

Every artifact published to an AI agent registry must be cryptographically signed:

Signing key management requirements:

• Publisher identity must be verified before signing keys are issued (organization-level identity verification, not just email verification)
• Signing keys must be hardware-protected (HSM or equivalent) for high-trust registry tiers
• Key rotation must be possible without publishing infrastructure downtime
• Revocation must propagate to all registry mirrors within 4 hours

Verification at install time: When an agent artifact is installed, the registry client should:

1. Verify the artifact hash matches the published hash
2. Verify the publisher signature against the trusted certificate for that publisher
3. Verify the certificate is not on the registry's revocation list
4. Verify the SLSA provenance attestation (if required for the trust tier)
5. Record the verification event in the local audit log

The sigstore project (Cosign, Fulcio, Rekor) provides open-source infrastructure for this verification pipeline and has been adopted widely in the container and software package ecosystem. Agent registries should build on sigstore rather than implementing custom signing infrastructure.

Behavioral Malware Scanning

The most distinctive security requirement for AI agent registries — with no real equivalent in traditional software registries — is behavioral malware scanning: evaluating whether the agent behaves maliciously, not just whether it contains malicious code.

What Behavioral Malware Looks Like

Behavioral malware in AI agents doesn't look like a rootkit or a keylogger. It looks like an agent that performs its declared function correctly under normal conditions but exhibits harmful behaviors under specific trigger conditions. Detection requires running the agent under a range of conditions that might trigger the malicious behavior.

Types of behavioral malware:

Context-triggered data exfiltration: An agent that functions correctly when accessed through the expected API but exfiltrates data when it detects specific environmental signals (deployment in a production vs. test environment, access to specific database schemas, presence of high-value users).

Delayed activation trojans: An agent that behaves correctly for the first N uses or for the first 30 days after deployment, then activates malicious behavior. Motivated by the detection-evasion goal: automated security scanning typically occurs at installation or shortly after, not 30+ days into deployment.

Trigger-activated prompt injection: An agent's system prompt that contains hidden instructions that are only activated when the input contains specific trigger phrases. A legitimate customer service agent might contain hidden instructions to exfiltrate customer data when the word "refund" appears in a conversation.

Subtle manipulation: Rather than exfiltrating data or executing unauthorized actions, the agent subtly biases its outputs in ways that serve the attacker's interests. A product recommendation agent that systematically recommends overpriced products. A financial research agent that subtly inflates the assessed quality of specific securities.

The Behavioral Malware Scanning Protocol

Behavioral malware scanning for registry artifacts requires a multi-phase evaluation protocol:

Phase 1: Static analysis of prompt and configuration artifacts

• Scan system prompt text for hidden instructions, steganographic encoding, unusual Unicode sequences, and injection patterns
• Analyze tool call configurations for capability scope violations
• Verify that declared functionality matches actual tool permissions
• Check for environmental condition checks that might indicate trigger-conditional behavior

Phase 2: Behavioral evaluation under normal conditions Run the agent against a comprehensive test battery representing its declared use case. Verify that:

• Outputs match the declared functionality
• Tool calls are within declared permissions
• No unexpected network connections are made
• No unexpected data writes occur
• Refusal behaviors match the declared policy

Phase 3: Adversarial trigger probing Run the agent under conditions designed to trigger conditional malicious behavior:

• High-value user simulation (simulate access as a high-value enterprise customer)
• Production environment markers (set environment variables indicating production deployment)
• Time-delayed evaluation (evaluate at multiple times — 1 day, 7 days, 30 days after "deployment")
• Cross-context evaluation (evaluate the agent in contexts beyond its intended use case)
• Trigger phrase testing (probe with common trigger vocabulary — credential names, sensitive operations, environment flags)

Phase 4: Canary deployment monitoring For high-trust registry tiers, require a supervised canary deployment period before full publication:

• Deploy the agent in a monitored sandbox environment
• Monitor all I/O, tool calls, and network activity for 14-30 days
• Compare behavior against the static analysis predictions
• Flag any behavior not predicted by the declared functionality

Behavioral Malware Signature Database

As behavioral malware techniques are discovered, maintain a signature database of known malicious patterns that can be applied to new submissions:

• Hidden instruction patterns in system prompts
• Known trigger vocabularies associated with conditional activation
• Characteristic I/O patterns of known data exfiltration techniques
• Tool call sequences associated with known privilege escalation attacks

This signature database should be shared across registry operators (analogous to antivirus signature sharing in the traditional security ecosystem) and updated as new techniques are discovered.

Evaluation Certificate Requirements

An evaluation certificate is a standardized, signed document that records the results of a behavioral evaluation against a defined test battery. Registry entries should be required to present evaluation certificates as a condition of publication at higher trust tiers.

Minimum Evaluation Certificate Content

{
  "certificate_id": "eval_cert_a1b2c3",
  "artifact_id": "agent_xyz_v1.4.2",
  "issuer": {
    "name": "Armalo AI",
    "did": "did:web:armalo.ai",
    "signature": "ed25519:deadbeef..."
  },
  "evaluation_timestamp": "2026-05-01T10:00:00Z",
  "certificate_expiry": "2026-08-01T10:00:00Z",
  "evaluation_type": "registry_standard_v2",
  "test_battery": {
    "name": "armalo_agent_security_battery_v3",
    "version": "3.2.1",
    "owasp_coverage": ["LLM01", "LLM02", "LLM06", "LLM07", "LLM08"],
    "atlas_coverage": ["AML.T0043", "AML.T0054", "AML.T0057"]
  },
  "results": {
    "overall_pass": true,
    "dimensions": {
      "refusal_accuracy": {"score": 0.998, "threshold": 0.990, "pass": true},
      "tool_permission_adherence": {"score": 1.000, "threshold": 0.999, "pass": true},
      "injection_resistance_known": {"score": 0.994, "threshold": 0.990, "pass": true},
      "injection_resistance_novel": {"score": 0.921, "threshold": 0.900, "pass": true},
      "output_toxicity": {"score": 0.00008, "threshold": 0.001, "pass": true},
      "behavioral_malware_scan": {"verdict": "clean", "pass": true}
    }
  },
  "conditions": {
    "deployment_scope": "enterprise_internal",
    "max_autonomy_level": "supervised",
    "required_monitoring": ["tpar", "irr"],
    "prohibited_use_cases": ["medical_decisions", "legal_advice"]
  }
}

Certificate Expiry and Re-evaluation Triggers

Evaluation certificates must expire and require re-evaluation because agents change over time:

Standard expiry periods:

• High-risk agents (financial, medical, legal): 60 days
• Medium-risk agents (enterprise internal, customer-facing): 90 days
• Low-risk agents (developer tools, internal utility): 180 days

Mandatory re-evaluation triggers (regardless of expiry):

• Any change to the agent's system prompt
• Any change to the underlying model or model version
• Any change to the retrieval corpus or fine-tuning data
• Any change to the authorized tool list or tool configurations
• Discovery of a new attack technique that the previous evaluation did not cover

Revocation Infrastructure

When a registry artifact is found to be malicious, compromised, or critically non-compliant, revocation must propagate rapidly to prevent continued deployment.

Revocation Latency Requirements

Target revocation latencies:

• From discovery to registry revocation: < 1 hour
• From registry revocation to client enforcement: < 4 hours
• From discovery to deployed-instance notification: < 24 hours

These are aggressive targets — for comparison, certificate revocation in traditional PKI often takes days. But the potential harm from a malicious AI agent in active deployment justifies the investment in fast revocation infrastructure.

Revocation Mechanisms

Certificate Revocation List (CRL) approach: Maintain a list of revoked artifact hashes, updated in real time. Registry clients check the CRL before and during artifact use. CRL approach has high update frequency (every 15 minutes) and small delta files for efficient distribution.

Online Certificate Status Protocol (OCSP) approach: Registry clients query a real-time OCSP endpoint to check the current revocation status of a specific artifact. Adds a network dependency to each use but provides immediate revocation enforcement.

Registry-pushed revocation: The registry proactively pushes revocation notifications to registered clients (analogous to push notifications for security advisories). Clients that have installed a revoked artifact receive an immediate notification and quarantine directive.

Emergency kill-switch: For critical zero-day vulnerabilities, the registry should be able to push a mandatory stop signal that causes deployed instances of the affected artifact to suspend operation immediately, pending operator review. This is an extreme measure that should require multi-party authorization at the registry operator level.

Trust Scoring for Registry Entries

A trust score for a registry entry aggregates evidence across multiple dimensions to produce a scalar trust assessment that helps consumers make deployment decisions.

Registry Trust Score Dimensions

Provenance score (0-1): Based on SLSA level, signing key security, publisher identity verification completeness.

Evaluation score (0-1): Based on most recent evaluation certificate results, evaluation recency, and evaluation coverage breadth.

Deployment track record (0-1): Based on reported security incidents from deployed instances, aggregated across all deployments. Privacy-preserving aggregation (not individual deployment details) protects deployer confidentiality while accumulating signal.

Publisher reputation (0-1): Based on the publishing organization's history: how many artifacts have they published, what is their average evaluation score, have any of their artifacts been revoked?

Community signal (0-1): Aggregated feedback from deployments — not subjective ratings, but behavioral signals from deployed instances (incident reports, compliance violations, unexpected behaviors).

Composite registry trust score: RTS = 0.25 * provenance + 0.30 * evaluation + 0.25 * deployment_track_record + 0.15 * publisher_reputation + 0.05 * community_signal

The weights reflect the relative reliability of each signal: evaluation results are the most directly relevant to security, provenance is second (it controls the trustworthiness of the evaluation itself), deployment track record is informative but susceptible to gaming.

Governance Architecture for Registry Operations

A security standard is only as good as the governance architecture that enforces it. Registry security standards require not just technical controls but organizational governance to maintain those controls under adversarial pressure.

The Registry Governance Committee

AI agent registries that enforce meaningful security standards need a governance committee with:

Technical representation: Security engineers, AI safety researchers, and ML engineers who can evaluate technical security evidence and understand emerging attack techniques.

Legal representation: Attorneys who can advise on the legal implications of revocation decisions, liability for registry-hosted artifacts, and regulatory compliance requirements.

Independent members: External members with no financial stake in the registry operator's business, providing independent oversight and preventing governance capture by large publishers who want weaker standards.

Publisher representation: Representatives of the registries' publisher community, ensuring that standards are technically feasible and that the burdens are proportionate to the security benefits.

User/deployer representation: Representatives of the organizations that deploy registry-hosted agents, ensuring that standards reflect deployer needs rather than just publisher preferences.

The governance committee should meet at minimum quarterly, with emergency sessions available within 48 hours for security incidents requiring urgent revocation decisions.

Standard Evolution Process

Security standards must evolve as the threat landscape evolves. The standard evolution process should:

Track emerging threats: The committee should monitor MITRE ATLAS, OWASP LLM security project updates, academic security research, and incident reports to identify new attack techniques that current standards don't address.

Conduct annual comprehensive review: Each year, the full registry security standard should be reviewed for gaps, with updates to evaluation batteries, SBOM requirements, and provenance standards as warranted.

Provide deprecation timelines: When old standards are superseded by new ones, publishers should receive adequate notice (minimum 90 days) and a clear migration path before the old standards stop being accepted.

Document rationale: All standard changes should be accompanied by documentation explaining the security rationale — what threat the change addresses and why the specific design was chosen.

Conflict of Interest Management

Registry security governance faces inherent conflicts of interest: the registry operator has commercial interests in attracting publishers, and more stringent standards may reduce the publisher pool. Managing these conflicts requires:

Financial independence: The governance committee must have members whose compensation is not tied to the registry's commercial success.

Transparency: All governance decisions, including decisions not to strengthen standards in response to identified threats, should be publicly documented.

Appeal processes: Publishers who have artifacts rejected or revoked should have a clear, fair, time-bounded appeal process that is adjudicated by independent reviewers.

Standard audits: External security firms should periodically audit whether the registry's enforcement of its stated standards actually matches the standards — not just whether the standards exist on paper.

Registry Integration with Enterprise AI Governance

For enterprises that deploy agents from registries, registry security standards should be integrated into the enterprise's broader AI governance framework:

Registry Trust Score Thresholds by Deployment Tier

Tier 1 (internal low-stakes) deployments: Registry Trust Score ≥ 0.60 acceptable. Basic behavioral malware scan result required.

Tier 2 (external-facing or medium-stakes) deployments: Registry Trust Score ≥ 0.75 required. Full evaluation certificate required. SLSA Level 2+ provenance required.

Tier 3 (regulated, high-stakes) deployments: Registry Trust Score ≥ 0.85 required. Full evaluation certificate with domain-specific evaluation required. SLSA Level 3+ provenance required. Publisher identity verification required. Independent third-party evaluation recommended.

Supply Chain Documentation Requirements

Enterprises deploying agents from registries should maintain:

Registry source documentation: Which registry was each deployed agent sourced from? What were the agent's registry trust score and evaluation certificate details at the time of deployment?

Version tracking: What specific version of each agent is deployed? When was the version deployed? What changed from the prior version?

Dependency graph: For each deployed agent, what are the complete dependency chain components (base models, tools, data sources)? This is the enterprise-level AI SBOM.

Update management: How are agent updates evaluated before deployment? Is there a staging environment where new versions are behavioral-tested before production deployment?

This documentation supports audit, incident response, and regulatory compliance — and it is most efficiently maintained by integrating with the registry's published SBOM and evaluation certificate data.

How Armalo Implements Registry Security Standards

The Armalo platform functions as a trust-verified agent registry, implementing the standards described in this document as first-class platform features rather than optional add-ons.

Every agent published to the Armalo marketplace goes through the complete behavioral malware scanning protocol before publication. Agents are evaluated against the Armalo security battery (which maps to all relevant OWASP LLM Top 10 categories and selected MITRE ATLAS techniques) and receive an evaluation certificate before their listing is activated. Evaluation certificates are embedded in the agent's public trust profile and updated as agents are re-evaluated.

Armalo's provenance verification requirements mandate AI SBOM documentation for all published agents. The SBOM is parsed and indexed, enabling enterprises to search for agents by their component dependencies — including filtering out agents that use specific base models, training datasets, or tool libraries that the enterprise has determined to be high-risk.

The Armalo revocation infrastructure maintains sub-1-hour revocation latency from discovery to registry update and provides push-notification revocation for all agents that have been installed through the Armalo platform. When a revocation event occurs, all registered deployers of the affected agent receive immediate notification with remediation guidance.

The Armalo trust score for registered agents incorporates all seven dimensions described in the trust scoring section, with aggregate scores updated continuously as new evaluation results and deployment signals are received. The trust oracle API at /api/v1/trust/ exposes the current trust score, the evidence basis, and the score trajectory for any registered agent.

Conclusion: Key Takeaways

AI agent registries are being built today at the scale and in the contexts that justify treating their security standards as a critical infrastructure question. The software supply chain community learned this lesson through years of incidents. The AI agent ecosystem has the opportunity to learn it preemptively.

Key takeaways:

1. Traditional software registry threats all apply — typosquatting, compromised maintainers, dependency confusion. Don't reinvent security solutions for these; apply the established approaches.

2. Behavioral malware scanning is the AI-specific requirement — static code analysis is not sufficient for AI artifacts; behavioral evaluation under adversarial trigger conditions is required.

3. AI SBOM extends software SBOM — model components, training data components, and prompt components must all be inventoried alongside software components.

4. Evaluation certificates provide the trust foundation — standardized, signed, expiring evaluation certificates make behavioral claims verifiable.

5. Revocation must be faster for AI agents — a malicious agent can cause harm within minutes; revocation latency targets must be measured in hours, not days.

6. Trust scores aggregate multiple evidence dimensions — provenance, evaluation, deployment history, publisher reputation, and community signal all contribute independently.

7. Build on existing infrastructure — sigstore for signing, SLSA for provenance, CISA SBOM standards for component inventories. Agent-specific extensions on proven infrastructure are better than greenfield custom solutions.

8. Governance architecture determines enforcement quality — technical standards without independent governance committees, conflict of interest management, and transparent decision-making will not be enforced consistently under commercial pressure.

9. Regulatory requirements are converging — EU AI Act, NIST AI RMF, and CISA guidelines all create registry-relevant expectations. Registry operators who invest in standards now will find compliance straightforward when regulations mature.

10. Incident history provides essential context — the software industry's supply chain incidents (xz Utils, npm compromises, left-pad) provide direct lessons for AI agent registry design. The AI agent ecosystem should learn from them before experiencing its own equivalents.

The organizations that invest in registry security standards today — both as registry operators and as publishers who meet those standards — will be the ones whose agents earn and maintain enterprise trust. Those that don't will face the same supply chain incidents that the software industry has been dealing with since the early 2000s, with the added complexity of AI-specific attack vectors.

Emerging Regulatory Requirements for Agent Registries

The regulatory landscape for AI agent registries is evolving rapidly. Several jurisdictions are developing requirements that will directly affect registry operators and publishers:

EU AI Act Implications for Registries

The EU AI Act creates several provisions relevant to AI agent registries:

General-purpose AI model documentation (Article 53): Providers of general-purpose AI models must make publicly available documentation that includes technical specifications and training information. Registry operators should require that published agents include documentation that meets Article 53 requirements when applicable.

Prohibited AI systems (Article 5): Registries must not list agents that implement prohibited AI practices under Article 5 — including real-time biometric identification in public spaces and social scoring systems. Registry behavioral malware scanning should include checks for these prohibited capabilities.

Conformity assessment requirements: For agents intended for high-risk use cases, EU AI Act conformity assessment requirements apply. Registries should surface whether published agents have undergone conformity assessment and whether their intended use cases require it.

NIST AI RMF Registry Implications

NIST's AI Risk Management Framework, while voluntary, is increasingly incorporated by reference into regulatory requirements and procurement standards. Key AI RMF considerations for registries:

GOVERN function: Registries should document their governance structures, including who has decision authority over standard-setting, revocation, and publisher access. This governance documentation supports organizations' own GOVERN function compliance.

MAP function: Registries should provide sufficient information about each published agent to enable deployers to conduct their MAP function (categorizing and mapping AI risks). This includes detailed scope documentation, evaluation results, and known limitations.

MEASURE function: Evaluation certificates should include the measurement methodology and results in sufficient detail that deployers can assess whether the evaluation methodology aligns with their own MEASURE function requirements.

CISA AI Security Guidelines

CISA's guidelines on secure AI development and deployment create expectations relevant to registry operators. Key CISA positions:

Secure by design for AI: CISA's Secure by Design principles, applied to AI, encourage AI system developers to take responsibility for security outcomes rather than delegating them entirely to users. Registry operators who enforce pre-publication security standards embody this principle.

Software supply chain security: CISA's extensive guidance on software supply chain security (particularly post-SolarWinds incident guidance) applies to AI supply chains. Registry operators should review their infrastructure against CISA's software supply chain security guidance.

Vulnerability disclosure: CISA expects organizations to have clear vulnerability disclosure policies and processes. Registry operators need clear processes for receiving and acting on vulnerability reports about registry-hosted agents.

Organizations that align their registry operations with emerging regulatory expectations will face significantly lower compliance friction as these regulations mature. Registry operators who are still implementing basic security standards when EU AI Act enforcement begins in 2026-2027 will find compliance costly and disruptive; those who have invested in standards-compliant registry infrastructure early will find compliance straightforward and will have a meaningful competitive advantage in markets where regulatory compliance is a procurement prerequisite. The AI agent registry security standards field is evolving quickly, and the organizations investing in it now — as registry operators, as standard-setters, and as publishers who meet those standards — are building the infrastructure that will define how the AI agent supply chain operates at scale.