Open Standards for AI Agent Trust: Evaluating Proposals from IEEE, IETF, and W3C

Standards wars are expensive. The history of technology is littered with the wreckage of competing standards that consumed billions in implementation costs before one prevailed or the market fragmented permanently: VHS vs. Betamax, HD-DVD vs. Blu-ray, SOAP vs. REST, the decades-long battles over wireless protocols. Each fragmentation episode imposes costs on everyone in the ecosystem — developers building to multiple standards, enterprises evaluating incompatible products, and ultimately end users experiencing incompatible products.

The AI agent trust standards landscape is in the early stages of what may become a fragmentation event. At least four major standards bodies are actively developing specifications that govern different aspects of how AI agents are identified, evaluated, authorized, and trusted. IEEE is working on trustworthiness frameworks for AI systems. The IETF has multiple working groups developing protocols for agent authentication and authorization. W3C is extending its Verifiable Credentials infrastructure to cover AI agent provenance. NIST is codifying evaluation methodologies in guidance that will likely become de facto standards for US government procurement.

These efforts are largely uncoordinated. They make different assumptions. They use different vocabularies. They solve adjacent but not identical problems. An enterprise navigating them without a map will spend substantial resources building to incomplete specifications, only to rebuild when the landscape clarifies.

This post provides that map. We analyze the four major standardization efforts in depth, identify where they align and where they conflict, assess their maturity and likely timelines, and provide enterprise guidance for engagement.

TL;DR

• IEEE P3394 is the broadest framework — a trustworthiness assessment standard for AI systems, not just agents. Expected to publish as a full standard in late 2027. Currently in draft.
• IETF has multiple relevant working groups: RATS (Remote ATtestation ProcedureS) for hardware-anchored attestation, OAuth working group extensions for agent authorization, and emergent work on agent identity in the HTTP and JOSE specs.
• W3C Verifiable Credentials Data Model 2.0 (published 2023) is the most mature and implementable specification for portable behavioral credentials. AI-specific extensions are being developed in the CCG (Credentials Community Group).
• NIST SP 800-218A and the AI RMF Playbook are rapidly becoming de facto standards for US government AI agent deployments.
• The core alignment across all bodies: behavioral evidence over claims, cryptographic verifiability, provenance tracking.
• The core conflict: IEEE's document-centric approach vs. IETF's protocol-centric approach vs. W3C's credential-centric approach — each prioritizes a different interaction model.
• Enterprise recommendation: implement to W3C VC Data Model 2.0 now; track IEEE P3394 for governance frameworks; use IETF RATS for hardware-anchored attestation in critical infrastructure.

The Standards Landscape: Four Bodies, Four Problem Framings

IEEE P3394: Trustworthiness Assessment for AI Systems

The IEEE P3394 working group began formally in 2023 with a mandate to develop "a standard for trustworthiness of AI systems, including specifications for technical and organizational requirements for ensuring, measuring, and demonstrating trustworthiness."

IEEE P3394 is broad by design. It covers not just autonomous agents but all AI systems, including supervised ML models, recommendation systems, and generative AI. The breadth is both a strength (comprehensive coverage) and a weakness (the standard must satisfy constituencies with very different technical requirements, leading to abstraction and generality that can feel unhelpful for practitioners).

The current P3394 framework organizes trustworthiness along six dimensions:

Technical trustworthiness. Accuracy, robustness, reliability, scalability, and efficiency. This dimension maps most directly to what most practitioners mean when they talk about AI agent trust. The framework requires that technical trustworthiness be measurable — not just asserted — and specifies minimum evidence requirements.

Safety and security. Hazard analysis, threat modeling, adversarial robustness, data protection. P3394 draws on existing cybersecurity frameworks (NIST CSF, ISO 27001) and extends them for AI-specific threats including data poisoning, model inversion, and adversarial examples.

Explainability and transparency. The ability to understand how the system produces its outputs. For AI agents, this includes both model-level explainability (why did the model generate this response?) and system-level explainability (what steps did the agent take?).

Fairness and non-discrimination. Statistical parity, individual fairness, and causal fairness requirements. This dimension is most relevant to agents making consequential decisions about people (hiring, lending, healthcare).

Privacy. Data minimization, purpose limitation, right to erasure compliance. P3394 requires that AI systems be able to demonstrate compliance with privacy obligations.

Governance and accountability. Organizational requirements: documentation, testing, deployment processes, incident response, ongoing monitoring. This is the dimension most relevant to enterprise deployment governance.

The P3394 evidence requirements are the standard's most practically useful element. Rather than specifying specific testing methodologies (which would become outdated quickly), P3394 defines categories of evidence that must be gathered: evaluation metrics, documentation of training data characteristics, adversarial testing results, operational monitoring data, and incident history.

Timeline and maturity. P3394 is currently in Draft 2 (as of early 2026). IEEE estimates publication as a full standard in Q4 2027. The draft is available for review and comment. Enterprise practitioners can engage through the IEEE SA (Standards Association) membership.

Key limitation. P3394 is an assessment framework, not a protocol. It tells you what to measure and document but does not specify how to communicate trustworthiness assertions between systems. Interoperability — the ability for one system to query another's trustworthiness — is out of scope for P3394. This is where W3C and IETF specifications are needed.

IETF: Protocol-Level Agent Authentication and Attestation

The IETF does not produce a single AI agent trust standard. Instead, several IETF working groups are developing protocols relevant to agent trust, each addressing a different layer of the interaction stack.

RATS (Remote ATtestation ProcedureS) Working Group. RATS is developing RFC-track specifications for remote attestation — the ability for one system to verify claims about the hardware, firmware, and software state of another system. RATS has already published RFC 9334 (Remote ATtestation Procedures Architecture) and is developing claim formats and verification protocols.

For AI agents, RATS attestation provides the foundation for hardware-anchored trust. An agent running inside a trusted execution environment (Intel TDX, AMD SEV) can produce RATS attestations that prove: (1) the hardware is genuine and unmodified, (2) the firmware is the expected version, (3) the model weights loaded in the TEE are the expected weights (hash-verified). This creates a chain of trust from hardware to model to behavior that is stronger than software-only attestation.

The RATS specification most relevant to AI agents is the Entity Attestation Token (EAT, RFC 8392 extended). EAT provides a JWT-compatible format for attestation claims that can be verified by relying parties. An AI agent deploying RATS-based attestation would include an EAT in its trust credential presentation, allowing counterparties to verify the hardware and software provenance of the agent.

OAuth and Authorization Working Groups. The OAuth working group is developing extensions relevant to AI agent authorization. Rich Authorization Requests (RAR, RFC 9396) allows OAuth clients to request fine-grained authorization structures, moving beyond simple scope strings to detailed permission specifications. This is directly relevant to capability disclosure in agent-to-agent trust negotiation.

Token Introspection (RFC 7662 extended) enables real-time checking of whether an access token is still valid — critical for agents operating with time-bounded authorizations. The working group is also developing guidance for authorization frameworks that involve multiple parties (the human principal, the deploying organization, the agent) — the OAuth concept of "authorizing parties" needs extension for the multi-principal model of agent deployments.

HTTP Working Group extensions. The IETF HTTP working group has produced HTTP Message Signatures (RFC 9421), which provides a mechanism for cryptographically signing HTTP requests and responses. For AI agents communicating via HTTP APIs, message signatures provide authenticity and integrity guarantees at the transport layer. This is foundational infrastructure for agent-to-agent communication security.

JOSE (JSON Object Signing and Encryption) extensions. The JOSE specifications (RFC 7515 through 7520) define the format for JWTs, JWKs, and related structures. Extensions being developed include mechanisms for expressing AI agent capabilities and constraints in token form, and selective disclosure proofs (SD-JWT, being standardized) that allow agents to reveal only specific credential attributes without revealing the full credential.

Timeline and maturity. IETF RATS specifications are the most mature, with multiple RFCs already published. OAuth extensions are in active development with RFC publication timelines of 1–2 years. HTTP-layer specifications are published and implementable today.

Key limitation. IETF specifications are protocol and format specifications — they define how to communicate trust claims, but not what claims are meaningful or how to evaluate them. An IETF-compliant agent could produce cryptographically valid attestations that are semantically meaningless. IETF work must be combined with evaluation frameworks (like IEEE P3394 or NIST guidance) to be useful.

W3C: Credential-Centric Trust for AI Agents

The W3C has produced two foundational specifications with direct relevance to AI agent trust: Verifiable Credentials Data Model 2.0 (VCDM 2.0, published March 2023) and Decentralized Identifiers (DID Core, published July 2022). Both are W3C Recommendations — the organization's highest maturity status — and are ready for production implementation.

Verifiable Credentials Data Model 2.0. VCDM 2.0 defines a standardized format for cryptographically signed claims about a subject. A Verifiable Credential (VC) is a JSON-LD document containing:

• An issuer (who made the claim)
• A subject (about whom the claim is made)
• Credential claims (the specific assertions)
• A proof (cryptographic signature binding issuer to claims)
• Credential status (revocation information)

For AI agents, VCs provide the natural format for behavioral attestations. An Armalo-issued VC attesting to an agent's trust score looks like:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://armalo.ai/ns/agent-trust/v2"
  ],
  "type": ["VerifiableCredential", "AgentTrustAttestation"],
  "issuer": "did:web:armalo.ai",
  "issuanceDate": "2026-05-01T00:00:00Z",
  "expirationDate": "2026-08-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:armalo:agent:0x7f4a9b2c1e3d5f6a",
    "compositeTrustScore": 887,
    "scoreComponents": {
      "accuracy": 0.91,
      "reliability": 0.88,
      "safety": 0.94,
      "security": 0.85,
      "bond": 0.92,
      "latency": 0.89
    },
    "evaluationPeriod": "2026-02-01T00:00:00Z/2026-04-30T23:59:59Z",
    "interactionCount": 12847,
    "adversarialTestingCoverage": 0.94,
    "certificationLevel": "armalo-certified-reliable"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:web:armalo.ai#key-2",
    "proofPurpose": "assertionMethod",
    "proofValue": "z4oey5q2M..."
  }
}

This credential is portable (can be presented to any relying party that understands VCDM), verifiable (the issuer signature can be checked against the published public key), revocable (the credential status endpoint allows the issuer to revoke it), and time-bounded (expirationDate ensures freshness).

Decentralized Identifiers. DID Core provides the identity foundation on which VCs rest. A DID resolves to a DID Document that contains the public keys needed to verify VCs. The DID for an AI agent serves as its stable, portable identifier — present it to any DID-aware system and they can resolve the cryptographic material needed to verify the agent's credentials.

W3C Credentials Community Group AI Work. The CCG is developing AI-specific VC extensions including: schemas for model provenance claims, standards for expressing behavioral constraints as credentials, and mechanisms for linking behavioral monitoring records to issued credentials. This work is not yet at Recommendation status but is actively being developed.

Timeline and maturity. VCDM 2.0 and DID Core are published Recommendations — implement them now. CCG AI extensions are in development with 12–18 months to Recommendation status.

Key limitation. W3C specifications define data formats and verification mechanisms but say nothing about what behavioral claims should be made or how they should be evaluated. The semantic content of AI agent credentials — what does "accuracy score 0.91" mean and how was it measured? — is not standardized by W3C. This gap must be filled by domain-specific profiles referencing IEEE P3394 or NIST guidance.

NIST: The De Facto Standard for US Government AI Trust

NIST's AI Risk Management Framework (AI RMF 1.0, published January 2023) and its associated Playbook are becoming de facto standards for US government AI deployments, and through procurement requirements, for any organization seeking US government contracts.

The AI RMF organizes AI risk management around four core functions: GOVERN, MAP, MEASURE, and MANAGE. For AI agents specifically:

GOVERN requires that organizations establish policies, roles, and processes for AI risk management. For agents, this means: who is responsible for agent behavior, what escalation paths exist, what policies govern agent authority scope.

MAP requires identifying AI risks in the deployment context. For agents: what are the failure modes, what harm could result, what populations are affected.

MEASURE requires quantifying identified risks. For agents: what metrics measure behavioral quality, what thresholds indicate acceptable risk, how frequently are risks measured.

MANAGE requires responding to identified risks. For agents: what triggers remediation, what forms does remediation take, how are incidents documented.

NIST SP 800-218A (Secure Software Development Framework for AI) extends cybersecurity guidance to AI development pipelines, covering training data security, model security, and deployment security. This is increasingly referenced in FedRAMP authorization packages for AI systems.

Timeline and maturity. AI RMF 1.0 is published and widely referenced. NIST is developing AI RMF 2.0 with more specific guidance for generative AI and autonomous agents. SP 800-218A is published. FedRAMP's AI guidance is in active development.

Where the Standards Align

Examining the four bodies' work reveals substantial alignment on core principles, which provides a stable foundation for enterprise implementation:

Behavioral evidence over claims. All four bodies require that trust assertions be supported by documented evidence — evaluation results, testing records, operational monitoring data. None of the frameworks accepts "we assert this agent is reliable" as a substitute for evidence. This is the fundamental insight that drives Armalo's architecture: trust is built from accumulated behavioral evidence, not from claims.

Cryptographic verifiability. IETF (message signatures, RATS attestation), W3C (VC proofs, DID verification), and IEEE P3394 (evidence authentication requirements) all require that trust-relevant data be cryptographically signed by credible issuers. NIST requires that audit records be tamper-evident. The result: a well-designed AI agent trust system built on any of these frameworks will produce cryptographically verifiable records.

Identity as a foundation. All four bodies recognize that behavioral claims must be anchored to stable, verifiable identities. Without knowing that the agent presenting credentials today is the same agent that earned those credentials, the credentials are useless. W3C DIDs are the most mature identity specification; IETF RATS provides hardware-anchored identity for the most critical deployments.

Ongoing monitoring vs. point-in-time certification. All four bodies have moved away from certification-at-deployment-time as the primary trust mechanism. IEEE P3394 requires ongoing measurement. NIST requires continuous MEASURE and MANAGE activities. IETF authorization protocols use short-lived tokens that require frequent renewal. W3C VCs with short expiration periods model the same principle. This alignment validates the architectural choice to ground trust scores in continuous operational monitoring rather than periodic audits.

Organizational accountability alongside technical verification. None of the frameworks treats technical controls as sufficient. All require that human organizations take responsibility for AI system behavior, document their risk management processes, and be accountable for failures. This is the governance layer that technical trust mechanisms must support.

Where the Standards Conflict

The conflicts between standards bodies are less visible but equally important for enterprise decision-making:

Problem framing: documents vs. protocols vs. credentials. IEEE P3394 is fundamentally a documentation and assessment framework — it tells you what to write down and what to measure. IETF is fundamentally a protocol framework — it tells you how to communicate trust claims between systems. W3C is fundamentally a credential framework — it tells you how to package and verify attestations. These three framings are complementary but not identical, and combining them requires explicit interface design.

Evaluation methodology. IEEE P3394 specifies evaluation categories but not methodologies. NIST's AI RMF Playbook provides more specific guidance but is non-prescriptive. Neither specifies how behavioral evaluation should be conducted for generative AI agents — the evaluation methodology question is unresolved at the standards level. Armalo's multi-LLM jury evaluation with outlier trimming and inter-rater reliability measurement represents the current state of practice, but it is not yet standardized.

Scope creep vs. stability. IETF specifications are narrow and specific — a feature that produces stability and implementability but means a single IETF RFC covers only a narrow slice of the overall problem. IEEE P3394 is broad — a feature that provides comprehensive coverage but at the cost of abstraction. These different philosophies create tension when trying to build systems that satisfy both: the broad IEEE requirements may not map cleanly to the specific IETF protocols.

Governance model. NIST guidance is designed around organizational governance — humans in organizations making decisions. W3C and IETF specifications are designed around technical systems interoperating. For highly autonomous agent systems where human-in-the-loop governance is limited, the governance-centric NIST framing and the protocol-centric IETF framing address different aspects of the same problem rather than providing a unified framework.

Privacy-preserving credentials. W3C has made strong commitments to privacy-preserving credential technologies — BBS+ signatures, selective disclosure, unlinkable presentations. IETF's SD-JWT work addresses selective disclosure. IEEE P3394 mentions privacy but does not specify credential technologies. This creates a real interoperability challenge: organizations that need to present credentials to multiple verifiers without enabling correlating surveillance must choose between standards bodies that have different maturity levels of privacy-preserving mechanisms.

Implementation Guidance for Enterprise Architects

Given this landscape, how should an enterprise architect build an AI agent trust implementation that is standards-aligned without being paralyzed by standards uncertainty?

Tier 1: Implement Now (Stable Standards)

W3C VCDM 2.0 + DID Core. These are published Recommendations with stable specifications and multiple conformant implementations. Build your agent identity and credential infrastructure on these now. Choose DID methods that match your operational requirements: did:web for organizations with stable web infrastructure, did:key for ephemeral agent instances, did:ethr for deployments requiring blockchain anchoring.

IETF RFC 9421 (HTTP Message Signatures). All agent-to-agent communication should use HTTP message signatures for request and response integrity. This is implementable with existing libraries and adds minimal overhead.

IETF RATS (RFC 9334). For agents deployed in regulated industries or government contexts, hardware-anchored attestation via RATS should be on the roadmap. Implementation requires TEE infrastructure (Intel TDX, AMD SEV) but the protocol specifications are stable.

NIST AI RMF. Document your AI risk management processes against the AI RMF's GOVERN/MAP/MEASURE/MANAGE framework. This creates the organizational documentation required by NIST, which is increasingly required for US government contracts and will likely be required for EU AI Act conformity assessments.

Tier 2: Design For (Emerging Standards)

IEEE P3394. Align your behavioral evaluation methodology with the P3394 draft's evidence categories. When the standard publishes, you will need to demonstrate evidence in these categories — start collecting it now. The draft is stable enough to design against even if details may change.

W3C CCG AI Extensions. Monitor the CCG's AI-specific VC extension work. When it advances toward Recommendation, it will provide standardized schema for behavioral claims that currently requires proprietary definition.

IETF OAuth Agent Extensions. Design your authorization infrastructure to use RAR (Rich Authorization Requests) for capability-specific authorizations. This is implementable today under the existing RFC but will become the standard model for agent authorization as the working group finalizes guidance.

Tier 3: Track (Pre-Standard)

Multi-agent trust protocols. There is no published standard for agent-to-agent trust negotiation protocols — the space described in this post. Multiple industry working groups (including Armalo's participation in several) are developing proposals. Design your agent-to-agent interfaces with extensibility to adopt a standard protocol when one emerges.

Behavioral evaluation standardization. The question of how to conduct and score behavioral evaluations for generative AI agents remains unstandardized. Track IEEE P3394's progress on evaluation methodology guidance and NIST's work on AI evaluation frameworks.

Engaging with Standards Bodies

Enterprise practitioners have significant influence in the standards development process when they engage actively:

IEEE SA membership provides access to working group ballots and the ability to contribute technical comments to P3394. Enterprise practitioners who are deploying AI agents at scale have empirical data about what evaluation categories are actually predictive of deployment quality — this data is valuable to the working group.

IETF participation is free and open. Attending IETF meetings (three per year) and contributing to working group mailing lists is accessible to any engineer with relevant expertise. The OAuth, RATS, and HTTP working groups all benefit from input about real-world agent deployment requirements.

W3C membership enables participation in the CCG and other community groups developing AI-specific extensions. Community group participation is open to non-members.

NIST engagement through the public comment process for guidance documents, and through participation in the NIST AI Safety Institute Consortium (AISIC), which coordinates between government and industry on AI trust standards.

The Role of Vendor Ecosystems in Standards Adoption

Standards bodies develop specifications; vendor ecosystems drive adoption. The AI agent trust standards landscape is early enough that vendor ecosystem choices will substantially shape which standards achieve dominance.

Armalo's approach aligns with the most mature available standards while extending them where gaps exist. The trust oracle implements W3C VCDM 2.0 credential issuance natively, ensuring that Armalo-issued trust credentials are immediately compatible with any VCDM-compliant relying party. Behavioral pacts are encoded as signed JSON-LD documents that extend W3C credential patterns. Agent identity is anchored to DID Documents with Armalo-specific extensions that remain resolvable by standard DID resolvers.

Where standards gaps exist — notably in behavioral evaluation methodology and agent-to-agent protocol — Armalo implements the current state of practice (multi-LLM jury evaluation, structured negotiation protocol) while actively participating in standards development to ensure that when standards emerge, they can be aligned with minimum disruption.

Conclusion: The Standards Picture in 2026

The AI agent trust standards landscape in 2026 is incomplete but navigable. The core message for enterprise architects:

Build on W3C VCDM 2.0 and DID Core now — they are stable, widely implemented, and will remain foundational regardless of how other standards evolve. Align your governance documentation with NIST AI RMF — it is the de facto standard for US procurement and aligns with the EU AI Act's conformity requirements. Track IEEE P3394 and IETF work as they mature, and design your architecture for extensibility.

Engage with the standards process. The organizations that participate in standards development shape outcomes that affect the whole industry. The behavioral evidence and operational data that enterprise AI deployers accumulate is exactly what standards bodies need to develop evidence-grounded specifications.

The fragmentation risk is real but not inevitable. The shared foundation — behavioral evidence, cryptographic verifiability, stable identity, continuous monitoring — provides enough common ground for the different bodies' work to be complementary rather than contradictory. The challenge is bridging the vocabulary and framing differences, which is exactly the work that platform providers and enterprise implementers must do in the standards gap period.

Key Takeaways:

• IEEE P3394 provides the broadest assessment framework; IETF provides the protocol layer; W3C provides the credential format; NIST provides the governance model.
• All four bodies align on: behavioral evidence over claims, cryptographic verifiability, stable identity, continuous monitoring.
• Conflicts center on: problem framing (documents vs. protocols vs. credentials), evaluation methodology, governance model.
• Enterprise recommendation: implement W3C VCDM 2.0 + DID Core and NIST AI RMF now; design for IEEE P3394 and IETF OAuth extensions.
• Active engagement with standards bodies gives enterprises the opportunity to shape specifications based on real-world deployment data.
• Armalo implements current standards and participates in standards development to ensure alignment as specifications mature.