OZEK

Manifesto

The trust layer for autonomous agents

MCP and A2A define how agents connect. They don't define whether those connections can be trusted. That infrastructure doesn't exist yet. We're building it.

The asymmetry

In 2025, two things became true at the same time. First: autonomous agents went from research projects to production systems. Real enterprises began deploying them in real workflows — procurement, logistics, customer operations, financial reconciliation. Second: the protocols those agents communicate over — MCP, A2A — were finalized and adopted at speed.

The result is a rapidly closing gap. The wire is being figured out. What it carries, and whether it can be trusted, is not.

This is the asymmetry. The plumbing is shipping faster than the safety layer. And the gap between the two is where the most consequential infrastructure problem of the next decade lives.

What MCP and A2A actually define

Anthropic's Model Context Protocol, launched November 2024, solved a real problem: how do you give a model standardized access to external tools and data? Before MCP, every agent-to-tool integration was bespoke — a mess of ad-hoc APIs, custom schemas, and fragile glue code. MCP made that layer generic. An agent can discover, call, and consume tools without custom integration work. This was an enormous unlock.

Google's Agent-to-Agent protocol, launched April 2025, solved the next problem: how do agents communicate with each other? A2A defines a standard message format and interaction model for agent orchestration — how a coordinating agent delegates tasks to specialist agents, how results flow back, how errors propagate. Backed by fifty-plus companies on launch day, it set the emerging standard for multi-agent systems.

Together, these two protocols define the wire. A model can connect to tools over MCP. Agents can orchestrate each other over A2A. The connectivity layer for autonomous systems exists now. What doesn't exist is the trust layer on top of it.

What they still don't answer

When an agent sends a message over A2A, how does the receiving agent know who sent it? Not in the sense of an IP address or API key — in the sense of organizational identity, delegated authority, scoped capability. Is this agent authorized by the organization it claims to represent? Has it been granted permission to make this request? Can its claims be verified without calling home to a central authority?

When an agent connects to a tool over MCP, how does the tool know what that agent is allowed to do? A human logging into a system has a role, a set of permissions, an audit trail. An agent sending a request over MCP has none of that unless the receiving system implements it from scratch — which most don't.

When one agent tells another agent something — a fact, a constraint, a claimed result — how does the receiving agent know whether to believe it? This is the agent-to-agent trust problem, and it becomes acute in multi-agent systems where the source of information is several hops removed from the original data.

MCP and A2A define the wire. They don't define who's allowed to use it, what they're allowed to say, or whether their claims can be verified. That's the gap.

None of this is a criticism of the protocols. They solved the right problems for where the ecosystem was in 2024 and 2025. But protocols define communication formats, not trust relationships. The same pattern played out with HTTP: it defined how requests and responses move. TLS came later. OAuth came later still. The trust layer is always a second-order problem — until suddenly it isn't.

Why this becomes infrastructure

Every major infrastructure category in the history of the internet was shaped by a trust incident. SSL became standard after financial institutions started getting man-in-the-middled. OAuth emerged after the proliferation of screen-scraped passwords and credential sharing. PKI became critical after it became clear that any service accepting certificates needed a way to verify them.

Autonomous agents will follow the same arc. The first wave of production deployments will work fine — carefully scoped, internal use cases, controlled environments. Then an agent will be spoofed. A delegation chain will be abused. A multi-agent workflow will propagate a hallucinated fact into a production database. A supplier agent will commit to a contract it wasn't authorized to sign.

The incident will create the demand. And the teams that built the infrastructure ahead of it will own the category.

This is what we mean by "trust layer." Not security theater — not rate limiting and API keys. Infrastructure: a verifiable identity system for agents, a discoverable registry of what agents exist and what they're authorized to do, and a policy enforcement layer that applies consistently across every protocol interaction.

Three layers that make autonomous agents safe to deploy in production — not just in sandboxes.

Why supply chain

We could start anywhere. We're starting in supply chain because it's where the trust problem is most concrete, most urgent, and most measurable.

Supply chain orchestration is one of the earliest domains where multi-agent systems are being deployed at scale. Procurement agents negotiate with supplier agents. Logistics agents coordinate with customs agents. ERP agents trigger finance agents. These workflows already exist in production, at major enterprises, with real financial and operational consequences.

And the trust gap is already visible. These workflows cross organizational boundaries — no single company's auth system spans the full supply chain. They operate under multiple regulatory regimes. They involve commitments — orders, contracts, transfers — that can't be easily undone. When an unauthorized agent action happens, the cost is measurable.

Starting in supply chain gives us a forcing function. The requirements are concrete. The feedback loop is fast. And the pattern generalizes: every domain where agents cross organizational boundaries, make consequential commitments, or operate under regulatory scrutiny will need this layer. Supply chain is first. The others follow.

The window

Infrastructure gets defined in the early years. TCP/IP. TLS. OAuth. DNS. The teams that built those layers owned the category for decades. The agent trust layer will be the same.

The window is right now. MCP and A2A are defined. Production deployments are beginning. The incident that creates mainstream demand hasn't happened yet. That's the moment to build — before the problem is obvious to everyone, when the design space is still open and the early partners are still reachable.

We're not building a security product. We're not building a compliance tool. We're building the infrastructure that makes autonomous agents trustworthy by default — the layer that every agent network will eventually need.

If you're building or deploying agents in a domain where trust is already a problem, we want to work with you.

— Zharkyn Kassenov, founder