KYA-OS: A new open specification provides the immediate blueprint for securing machine-to-machine workflows before autonomous systems cross enterprise perimeters.
For two decades, identity on the internet revolved around one core assumption: a human was sitting behind the browser. Authentication systems were built to answer a simple question: “Is this the right person?” Today, that assumption is breaking down as autonomous AI agents take over browsing, API usage, and digital transactions.
When an AI agent interacts with a web service, it typically carries its owner’s session cookies or OAuth tokens. To the receiving system, that agent looks indistinguishable from a human user or a standard automated script. The server has no native way to determine which agent software is calling, what task it was asked to perform, or whether it is operating within its authorized limits.
This gap between human authentication and machine execution is the agent accountability gap. A valid login no longer means a person is at the keyboard. Solving it requires moving past implicit trust and establishing an open, cryptographic layer for agent identity.
The Failure of Naive Trust in Autonomous Systems
In the early days of automated software, simple API tokens or service accounts were sufficient. API calls were deterministic, tightly scoped, and executed predictable workflows. Modern AI agents are non-deterministic, adaptive, and capable of executing multi-step reasoning across dozens of independent services.
The instinctive answer, OAuth, was engineered around a human at a consent screen granting a registered application scoped access to an account. Its tokens are opaque: only the issuing server can say what a token means, so nobody outside that domain can independently verify a delegation. Token exchange stretches the model toward delegation, but the result still cannot be checked by a third party.
Granting an autonomous agent full access to a user’s session cookie is the digital equivalent of handing a valet your entire keyring. The receiving site must blindly trust that the agent will only perform the intended action. If an agent hallucinates, suffers a prompt injection attack, or exceeds its instructions, the receiving system cannot intervene before the action completes.
Security cannot rely on guessing intent from traffic signatures alone. Recent industry reports highlight that automated traffic accounts for nearly half of all web traffic and continues to grow rapidly. To allow agents to perform meaningful work safely, web systems need a structured protocol to verify who an agent is, who delegated authority to it, and what constraints bind its actions.
An Open Specification, Developed in the Open
To prevent fragmenting the ecosystem into proprietary silos, open specifications have emerged to unify these trust mechanics. Authored by Dylan Hobbs in May 2025 as MCP-I, the specification was formally donated by Vouched to the Decentralized Identity Foundation (DIF) in March 2026. It was subsequently renamed KYA-OS on April 22, 2026, reflecting an expanded scope beyond any single transport protocol.[Text Wrapping Break]
The Decentralized Identity Foundation published its architectural reasoning for accepting the contribution into open governance. Today, the specification is actively maintained by a dedicated task force within the DIF Trusted AI Agents Working Group (TAAWG).
Agent identity could have arrived through proprietary channels, with each major platform issuing credentials for its own agents and binding them to proprietary accounts. That fragmented model functions only until a service must build custom integrations for every platform, or a developer’s track record is locked inside one vendor’s system. W3C Web Authentication (WebAuthn) provides a clear precedent: passkeys achieved broad adoption because the underlying standard belonged to an open standards body rather than a single vendor’s SDK.
The Six Primitives
Establishing verifiable identity for autonomous software requires six distinct cryptographic primitives defined by the KYA-OS specification: identity, credentials, delegation, consent, proof, and audit. Together, these primitives separate agent identity from human authority while creating a verifiable chain of responsibility. They enable a receiving service to cryptographically verify who called, under what authority, and what was executed.
An agent begins with an identity anchored by a W3C Decentralized Identifier (DID). A DID provides a persistent, globally unique identifier that resolves directly to public key material without relying on a centralized identity provider. This provides the agent with a distinct, cryptographically verifiable identity independent of the human operator who deployed it.
Before authority can be delegated, explicit human consent is required. The operator approves the precise scope, duration, and operational boundaries before a credential can be minted. This consent primitive prevents autonomous systems from self-authorizing expanded privileges or broadening their own operational reach.
Once authorized, the agent receives a cryptographic delegation grant built on the W3C Verifiable Credentials Data Model. This credential contains machine-readable constraints, allowing boundaries—such as a purchase capped at two hundred dollars, valid for one week at a single merchant—to be expressed directly in the grant. Attestation credentials can further specify an agent’s software provenance and verified operational boundaries.
At runtime, the agent presents a signed proof that cryptographically binds the request content and delegation grant to its private key. In the reference implementation built for the Model Context Protocol (MCP), the agent signs its request using detached JSON Web Signatures (RFC 7515), and the receiving server signs its response in return.
Finally, the protocol establishes an append-only audit trail. Every protected action generates a replayable, tamper-evident record aligned with transparency architectures like IETF SCITT and RFC 3161. This ledger allows both operators and resource servers to verify historical compliance after execution concludes.
Who Answers for the Agent
The most consequential architectural design choice in the specification is non-cryptographic. KYA-OS decouples the principal (the individual or process that directly invoked the agent) from the responsible party (the legal entity at the root of the delegation chain who remains accountable for outcomes). For a personal assistant, the principal and responsible party may be identical, but in an enterprise context, this separation is critical.
Reputation and trust signals attach to the responsible party rather than to ephemeral agent keypairs. A malicious actor cannot discard a compromised history by generating fresh agent keys, and an established enterprise’s newly deployed agent is not treated as an unverified stranger. This model adapts principles from financial compliance—applying Know Your Customer rigor to autonomous software anchored by verified legal entities.
Conformance Levels and Architectural Adoption
The KYA-OS open specification is transport-agnostic, defining how trust primitives map across communication protocols. While the primary reference implementation targets MCP, transport bindings for HTTP and WebSockets are also in active development. To facilitate progressive enterprise adoption, KYA-OS outlines three distinct conformance tiers:
- Level 1: Leverages existing identifiers such as OpenID Connect (OIDC) and JSON Web Tokens (JWTs), enabling platforms to verify agents without immediate public key infrastructure changes.
- Level 2: Introduces full DID verification, Verifiable Credential delegation grants, and dynamic revocation checks.
- Level 3: Implements enterprise lifecycle management, immutable transparency auditing, and full bilateral cryptographic verification between client, agent, and server.
Revocation mechanisms are essential for managing long-lived agent interactions across distributed networks. KYA-OS leverages W3C Bitstring Status Lists to enable performant, privacy-preserving credential revocation checks. Under a fail-closed posture, any unverified or revoked credential results in immediate request termination, or triggers an out-of-band consent challenge for fresh human sign-off.
Fitting Into the Modern Web and Commerce Stack
KYA-OS does not replace established identity and network security standards. Instead, it layers on top of existing infrastructure to supply missing delegation and authorization context. Established frameworks like OAuth 2.1 and Demonstrating Proof-of-Possession (DPoP, RFC 9449) handle token issuance and sender-constrained transport.[Text Wrapping Break]
Concurrently, RFC 9421 HTTP Message Signatures and the IETF Web Bot Auth draft confirm which infrastructure operator transmitted a request. Emerging multi-agent protocols, such as Agent2Agent (A2A), face identical identity gaps when calls traverse organizational boundaries. KYA-OS complements these transport protocols by resolving the delegation question: On whose behalf is this agent acting, and what exact authority was delegated to it?[Text Wrapping Break]
This structured authority is critical for the emerging agentic commerce ecosystem. Emerging commerce frameworks like Google AP2 and payment standards like Mastercard Verifiable Intent require verifiable agent identity and scoped mandates to execute automated transactions. KYA-OS supplies the underlying trust substrate that makes automated commercial transactions legally and operationally defensible.
The Larger Implications of Agentic Identity
Addressing agent identity triggers several structural shifts across cybersecurity, compliance, and enterprise software architecture. First, identity becomes the primary control plane for automated traffic, as network-layer firewalls and IP rate limits cannot distinguish legitimate commercial agents from malicious scrapers. Second, open cryptographic standards enable cross-organizational trust without prior bilateral integration, allowing heterogeneous agents to coordinate across enterprise boundaries.
Third, cryptographic consent keeps human operators meaningfully in the loop, directly supporting regulatory frameworks like the EU AI Act and the NIST AI Risk Management Framework. Fourth, platforms are shifting toward a fail-closed posture, restricting unverified agents to read-only endpoints while reserving state-changing operations for verified delegation chains, mitigating key vulnerabilities cataloged in the OWASP Top 10 for LLM and Agentic Applications.
Finally, international standards bodies are demonstrating rapid convergence across the IETF, W3C, OpenID Foundation, and DIF. The decisive milestone for any security standard is rigorous interoperability: independent implementations validating cryptographic signatures against the specification’s public suite of 142 test vectors.
What Remains Unsettled
The specification is explicit regarding its architectural boundaries. A spending cap or parameter restriction written into a Verifiable Credential is a verifiable claim rather than an autonomous enforcement engine. Terminating a transaction that exceeds declared bounds remains the responsibility of the verifying server and its backend business logic.
Governance of trust registries represents another active area of industry development. If the registries that anchor organizational identifiers or compute reputation become concentrated under proprietary control, the openness of the underlying wire protocol is compromised. Furthermore, persistent identifiers introduce correlation risks across services, presenting an architectural tension between non-repudiation and operator privacy.
Underlying these technical considerations sits a legal question that protocol design alone cannot resolve. Once an agent’s authority is cryptographically provable, where does legal liability rest among the model developer, the infrastructure operator, and the delegating organization? Open standards provide mathematical clarity on what occurred, but judicial and regulatory bodies will ultimately define the legal boundaries of machine liability.
What Engineering and Security Leaders Should Do Now
Preparing enterprise systems for an agent-driven web does not require tearing down existing security infrastructure. Platform and security engineering teams can implement practical, incremental safeguards today:
- Inventory agent-facing endpoints: Audit public and internal APIs to identify where autonomous, non-human traffic currently interfaces with business logic.
- Deploy the reference middleware: Integrate the open-source KYA-OS reference implementation into your Model Context Protocol (MCP) servers to enforce cryptographic request-response validation with minimal overhead.
- Enforce signed request proofs: Transition high-risk endpoints to require cryptographic request signatures and sender-constrained credentials.
- Validate against the public test suite: Test internal agent implementations against the specification’s 142 public test vectors to ensure immediate interoperability across multi-agent ecosystems.
- Establish Level 1 conformance: Begin binding existing OIDC and JWT tokens to agent runtimes today, establishing foundational agent identification before upgrading to full public-key infrastructure.
- Plan for revocation and audit logging: Integrate bitstring status lists and immutable, tamper-evident log stores for critical agent-driven transactions.
- Treat verified identity as an access tier: Reconfigure APIs to restrict unverified agent traffic to read-only endpoints, requiring signed delegation proofs for all state-changing or transactional operations.
- Participate in open governance: Engage with the DIF Trusted AI Agents Working Group to help shape evolving transport bindings and machine identity standards.
By shifting from implicit bearer trust to explicit cryptographic verification, organizations can safely open their platforms to autonomous software. Establishing verifiable identity today ensures that as machines run more of the web, human operators retain mathematical control over who acts, under what authority, and within what bounds.
