ATP Open Standard: Roadmap for Industry Adoption

Author: Lyrie Threat Intelligence Team

Date: 2026-05-13

Reading time: 9 min

TL;DR

The Agent Threat Protocol (ATP) specification, the reference implementations in four languages, the conformance test suite (1,726 tests passing as of this article), and the deployment tooling are all public at github.com/OTT-Cybersecurity-LLC/lyrie-ai.

We are now in the public-review window ahead of an industry-consortium launch targeted for Q3 2026. External contributions to the specification, the implementations, and the test suite are arriving from researchers at Anthropic, Microsoft, and Google as well as independent maintainers. This article documents the current adoption state, what is coming when, and how organizations and individuals can engage.

We are deliberately operating ATP as a public-good standard with a multi-stakeholder governance trajectory. Lyrie is the originating implementor; we are explicitly not intending to be the long-term gatekeeper. The consortium structure is what we are working toward.

Where the Spec Stands Today

Current draft: 0.7, available in the repository under spec/atp/. The spec is 84 pages covering:

• Transport (HTTPS, WebSocket, HTTP/3 — UDP variant for high-throughput streaming).
• Encoding (canonical JSON-LD with deterministic serialization).
• Identity (W3C DID-based agent identity, Ed25519 signing keys).
• Signing and verification (well-specified canonicalization, replay protection, nonce semantics).
• Capability scope (enumerable capability set, declared at deployment, enforced at runtime).
• Error handling and version negotiation.
• Conformance requirements (which receivers MUST/SHOULD/MAY support).

A non-normative companion document covers deployment patterns, threat-model rationale, and worked examples.

Reference Implementations

Four reference implementations are public and tested cross-conformantly against each other:

• TypeScript (@lyrie/atp-ts) — most-used in production, full feature coverage, MIT.
• Rust (atp-rs) — performance-focused, used for high-throughput streaming, MIT.
• Python (atp-py) — most-accessible for academic and research use, MIT.
• Go (atp-go) — used by partner-built infrastructure components, MIT.

Cross-implementation conformance: every release of every implementation must pass the cross-conformance test suite (the 174 tests from article 13's count) against the other three before tagging. The suite is run continuously in CI.

Test Suite

Aggregate test count: 1,726 tests passing. Broken down:

• 1,103 unit tests across the four implementations.
• 412 integration tests covering end-to-end behaviors.
• 174 conformance tests (the cross-implementation portable subset).
• 37 fuzz harnesses running continuously.

The suite is what we will use to validate third-party implementations during the consortium's certification program. Any implementation that passes the conformance subset is considered ATP-conformant in the spec's intended sense.

External Contributions

We have received substantive contributions to the project from researchers at:

• Anthropic — reviewer feedback on the MCP-adjacent boundary semantics (article 4 of this series), plus three accepted PRs to the conformance suite tightening replay-protection edge cases.
• Microsoft — design feedback on the audit-substrate independence requirements, plus one accepted PR adding an Azure-Key-Vault-backed key management adapter to the TypeScript implementation.
• Google — review of the cryptographic transport choices (article 14), plus discussions on how ATP relates to their internal Wave / Borg-attestation primitives. No code yet, but engaged participation in the public review.
• Independent maintainers — twelve accepted PRs across various components, two of which fixed real bugs (one race condition in the Rust implementation, one canonicalization edge case affecting some Unicode inputs).

We want to be precise about what these contributions represent. They represent individual researchers and engineers engaging with the spec on a public open-source basis. They do not represent corporate adoption commitments. We will be careful, throughout the consortium launch process, to distinguish between people contributing and companies committing. The former is well-established. The latter is what we are working toward.

Adoption Roadmap

Quarter by quarter through Q4 2026.

Q2 2026 (now). Public spec review. Draft 0.7 → 0.8 → 0.9 over the quarter, integrating external feedback. Continued external contributions. Conformance suite stabilization. We have committed to not breaking the conformance suite between 0.7 and 1.0 except where bug-fixing requires it; this gives early implementors a stable target.

Q3 2026 (consortium launch). Public announcement of the consortium structure. Founding-member companies (whose names we are not yet at liberty to share, but which include established security vendors, AI platform companies, and at least two enterprise consumer-of-the-spec organizations). Spec freeze candidate. Conformance certification program opens.

The consortium will be incorporated as a 501(c)(6) industry organization with multi-stakeholder governance. Lyrie will contribute the specification, the reference implementations, and the test suite to the consortium under permanent licenses; Lyrie's role in governance will be that of a founding member, not a controlling member. The specific governance structure — board composition, voting rules, IP commitments — is currently being negotiated with founding members.

Q4 2026. Spec freeze at 1.0. The 1.0 spec is what conformance certification tests against. Implementations that pass conformance can use the ATP-Conformant mark (trademark held by the consortium, not by Lyrie). First wave of certified implementations expected to be announced at a major security conference in Q4.

2027. Profile work. The 1.0 base spec is intentionally general. Specific industry profiles — financial services, government, healthcare, Web3 — will be developed within the consortium working groups during 2027. Profiles are additive: they refine the base spec for sector-specific needs without breaking interoperability with the base.

How to Engage

For different audiences:

Individual contributors (engineers, researchers, security professionals). Read the spec. File issues against the repository. Submit PRs. The contribution review process is documented in CONTRIBUTING.md; pull requests get initial review within 3-5 business days. We are particularly interested in:

• Test coverage of edge cases we have not thought of.
• Performance benchmarks against the reference implementations.
• Translations of the spec into languages other than English (Spanish, Mandarin, and Hebrew translations are in progress; others welcome).

Vendor companies. If you are building an agentic security product or an enterprise AI platform and you intend to support ATP, get on the early-implementer list. Email [email protected] with a description of your product and your intended ATP role (sender, receiver, or both). Early implementers get:

• Direct engagement with our spec maintainers on integration questions.
• Early visibility into spec revisions before they land publicly.
• Reserved seats in the consortium's Q3 launch announcements.

Enterprise customer organizations. Ask your existing vendors about ATP support timelines. Customer demand moves vendor roadmaps faster than any standards-body resolution. We will provide briefing materials suitable for vendor-relationship discussions to any customer who requests them.

Standards-body people, cryptographers, researchers. Read the spec critically. The public-review window is exactly the moment to surface design objections. The spec is better for every well-founded objection raised before freeze. We have already changed several material design choices in response to external critique.

Government and regulatory observers. We are happy to brief on the spec, the deployment evidence, and the governance trajectory. Several governments are engaged informally; we expect formal observer status during the consortium launch for any government interested in cross-vendor security standards for agentic systems.

Risks We Are Aware Of

The candid section. Standards work fails in known ways and we want to be honest about which ways we worry about.

Risk 1: Standard captured by a dominant vendor. Standards bodies that incorporate too few founding members, or that give the originating vendor too much governance weight, end up captured by that vendor. We are explicit about wanting Lyrie to be one founding member among several, not the controlling member. The governance structure being negotiated reflects this.

Risk 2: Standard fragments into incompatible profiles. Profile work in 2027 has a known failure mode where sector profiles drift apart and lose base-spec interoperability. The consortium's working-group structure includes an explicit interoperability-preservation mandate; we hope this is sufficient.

Risk 3: Implementations declared 'conformant' without passing the suite. Trademark enforcement of the ATP-Conformant mark will be the consortium's responsibility; we are advocating for strict enforcement.

Risk 4: The standard is too rigid for the rapidly-evolving agentic landscape. The agentic AI space is moving fast. A standard frozen too soon may not accommodate next year's threat surface. We are mitigating with the profile mechanism (additive sector-specific extensions without base-spec changes) and with a planned annual minor-version revision cadence.

What's Next

• This week: Draft 0.8 with the latest review-cycle changes.
• Within 60 days: Consortium-launch advance briefings to early-implementer companies.
• Q3 2026: Public consortium launch.
• Q4 2026: 1.0 spec freeze, conformance program opens.

Reach the team: [email protected] for spec questions; github.com/OTT-Cybersecurity-LLC/lyrie-ai for implementations and issues.

---

_Published by Lyrie.ai · lyrie.ai/research · Guy Sheetrit, CEO_