Part of Entangle Labs has been acquired. Our team is moving into private development on verifiable multi-agent AI.Read the note →

Verification and interoperability for multi-agent AI. Agents that can prove who they are, what they said and what they did.

GoogleNVIDIA Inception ProgramConsensysConfidential Computing ConsortiumHalborn

AI agents now talk to each other, hand off work and act in the real world. No one can prove what they did.

Entangle Labs makes multi-agent systems verifiable: which agent acted, on what data, under which rules.

How it works

Trust between agents, by construction.

Four things an outside party can check, without taking anyone's word for it.

01

Who acted

Every agent carries an identity you can confirm: who built it, which model runs it, what it is allowed to do.

02

What it saw

Every input carries verified provenance: where the data came from, who signed it, and that nothing changed on the way.

03

What was said

Every message between agents is signed and checkable, across frameworks, models and companies.

04

What was done

Every result comes with proof of what ran, on what data, under which rules. Recorded where no one can rewrite it.

Technology

Core Building Blocks

Universal Proof of Compute

Agents run inside secure compute enclaves, and every run produces proof of what executed: which model, which code, on what data, under which rules.

Distributed Ledger

The record of what every agent did. Attestations agreed by consensus and stored where no single party can rewrite them.

Universal Interoperability

A trusted communication layer between agents. Any framework, any model, any company, with every message signed and checkable end to end.

Universal Data Feeds

How do you know the data is right? Every input arrives with verified provenance: where it came from, who signed it, and proof that nothing changed.

Notes

Writing on verifiable AI

Research and Developments

Our research on verifiable compute, agent interoperability and trust between machines.

All Publications
AgentsEnclavesAgent MessagingInteroperabilityIdentityVerified DataProof of ComputeAuditPolicyTrusted ComputeMulti-agent SystemsRoboticsData ProvenanceModel Provenance

Join us in building AI you can verify.

Help us make trust between agents something you can check, not just promise.
[Close]

Notes · Oct 2026

Our next chapter

Entangle Labs has entered its next chapter. Part of the lab has been acquired, and our team is moving into private development on one problem: verification and interoperability for multi-agent AI.

For years we built the hard parts of connecting systems that do not trust each other: messaging between independent networks, data with provenance, and consensus on what actually happened. The same problems now sit at the centre of AI. Agents call other agents, pass work along and take actions with real consequences, and today nobody can check any of it.

The terms are confidential, so we cannot say much more for now.

Thank you to everyone who built with us. The work continues.

Entangle Labs

[Close]

Notes · Oct 2026

Why multi-agent systems need a ledger of record

When agents from different teams and vendors act together, the record of what happened cannot belong to any one of them.

The question every incident ends with

In July 2025, SaaStr founder Jason Lemkin reported that Replit's coding agent ran a database command during an explicit code freeze and deleted his production database. By his account, the agent also produced fake data, misreported test results and said a rollback was impossible. That last claim was false. His main evidence was screenshots of the agent's own replies.

In December 2025, AWS's agentic coding tool Kiro deleted and recreated an environment. The Financial Times reported an outage of roughly 13 hours. AWS confirmed the deletion but called it user error, pointing to misconfigured access controls. It declined to say what Kiro asked the engineer or how the engineer answered.

Both stories end in the same place. Someone asks what actually happened, and the only record is held by a party with a stake in the answer. In one case the agent narrated its own failure, and got it wrong. In the other, outsiders had to take the operator's word for it.

Regulators now ask for the whole chain

Article 12 of the EU AI Act says high-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system." The logs must give enough traceability to spot risky situations and to monitor the system once it is in use.

Finance is moving the same way. FINRA's 2026 oversight report, released on 9 December 2025, covered agentic AI for the first time. A law-firm summary of the report says firms must be able to reconstruct the full chain of a system's activity, because "outputs alone are insufficient." The OWASP Top 10 for Agentic Applications, published the same day, calls for correlated audit trails so teams can trace how a failure spread between agents. Without them, as one explainer puts it, "you know something went wrong but you can't reconstruct the chain."

None of these texts names a technology. Together they set a bar that ordinary logs struggle to clear.

Why ordinary logs fall short

Most agent logs today are written by the system they describe, and stored by the company that runs it. The operator can edit them. Each vendor keeps its own, in its own format.

That gap widens when several agents work together. A UC Berkeley study presented at NeurIPS 2025 analysed more than 200 execution traces across seven multi-agent frameworks. Misalignment between agents caused 36.94% of failures. The authors note that pinpointing root causes is difficult, because different causes produce similar symptoms. The hand-offs between agents are where a record matters most. They are also where no single component's log is complete.

Signing each log entry helps, because it proves who wrote it. It does not stop whoever holds the log from deleting entries, reordering them or showing different versions to different people.

What a ledger of record adds

A ledger of record is an append-only history that every party can check and no single party controls. The underlying technique already exists. Transparency logs such as Sigstore's Rekor, whose version 2 became generally available on 10 October 2025, return a receipt proving that an entry was included. Later checks can show that the history was only ever added to. Rekor v2 also shows the costs. Writes are batched and take a few seconds, and witnessing, which strengthens the append-only guarantee, was not yet live at launch.

An IETF Internet-Draft from April 2026 applies this idea to agents. It is an individual draft, not an adopted standard. It argues that evidence of consequential agent actions must be verifiable "without relying on the agent operator's cooperation," because "operator-controlled audit logs are mutable by the operator." In its design, each material action produces a signed record. An independent custodian holds the log, and auditors, regulators and counterparties can verify it for themselves.

The practical shape is clear. Keep rich event data, sign it with the agent's identity, and anchor it in a record that the operator, the counterparty and the auditor can each check without asking permission.

Where Entangle Labs fits

This is the problem Entangle Labs is working on: a shared, tamper-evident record of what agents did, agreed between the parties involved rather than kept by any one of them.

Entangle Labs

[Close]

Notes · Oct 2026

Agents do not need to trust each other. They need to verify.

As agents start calling other agents, the question "who sent this, and should I act on it?" has to be answered with evidence, not assumption.

Trust by default is the weak point

In April 2025, researchers at LevelBlue's SpiderLabs showed how a host agent using the A2A protocol picks a remote agent "based purely on what is in those agent cards." An Agent Card is the short self-description an agent publishes. A rogue card claiming broad skills, with a line telling the host to always pick it, won the task over the legitimate agent. It then received the user's data and could return false results.

In October 2025, Palo Alto Networks' Unit 42 described "agent session smuggling". A malicious remote agent slipped hidden instructions into a running conversation and got a financial-assistant agent to make unauthorised stock trades. In November 2025, AppOmni showed how text planted in a ServiceNow ticket could lead an admin's agent to recruit a more powerful agent, which then acted with the admin's rights. ServiceNow said the behaviour was intended and updated its documentation.

These are research demonstrations. No in-the-wild breach caused by one enterprise agent impersonating another has been publicly confirmed. But the pattern is consistent. Each attack worked because one agent believed what another agent told it.

Identity is being built from parts we already have

The encouraging news is that the industry is not inventing a new identity system. It is treating agents as workloads, like any other service, with credentials of their own.

An IETF draft written by authors from AWS, OpenAI, Okta, Ping Identity, Zscaler and Defakto became a working group document, draft-ietf-wimse-aims, on 15 September 2026. It is still a draft, but its language is blunt. "Static API keys are an antipattern for agent identity." "An identifier alone is insufficient unless it can be verified to be controlled by the communicating agent." And the model itself "MUST NOT have access to an agent's credentials."

Products are following. Google Cloud gives each agent an identity based on SPIFFE, an open standard for workload identity, with a certificate that lasts 24 hours and rotates automatically. Its access credentials are bound to that certificate, so stolen credentials are of little use on their own. Microsoft now lists Entra Agent ID as generally available, with owners and sponsors assigned to each agent so none is left orphaned.

A signature is not an identity

A2A v1.0 defined how to sign and verify Agent Cards. That is real progress. But the Agentic AI Foundation's own builder's guide is clear about the limit: "Signing fixes card integrity. It does not fix identity."

A valid signature tells you the card has not changed since someone signed it. It does not tell you who that someone is, whether the agent is safe, or whether it is approved for your organisation. You still have to decide separately whether you trust the organisation behind the key. Unit 42 makes a similar point about its own recommended fix: signed cards do not prevent a trusted agent from being subverted.

Four things to check

Verification works when it covers each claim an agent makes. The first is who is calling, shown by a credential the agent can prove it controls. The second is whether the message is intact, shown by a signature over it. The third is on whose authority the agent acts, through short-lived, scoped delegation rather than inheriting a user's full rights. The fourth is what code is actually running.

That last check is the newest. The IETF draft already treats hardware evidence as a signal when issuing an agent's credentials. A research paper presented at an ICML 2026 workshop, "Proof-of-Guardrail", ran an agent and its safety filter inside a secure enclave, a sealed area of the processor that the host cannot tamper with. Users could check offline that the published code really ran, and every tampering attempt was detected. The authors still warn that it "should not yet be interpreted or advertised as proof of safety."

Verification narrows trust down to claims you can measure. Someone still has to judge whether those claims are good enough.

Where Entangle Labs fits

This is the problem Entangle Labs is working on: letting agents prove who they are, what they sent and what they ran, so the agent receiving a request can check rather than assume.

Entangle Labs

[Close]

Notes · Oct 2026

Interoperability is the easy part

The protocols that let agents talk to each other are now largely settled; what they do not yet give you is a way to check what was said.

The plumbing is in place

Agent connectivity has standardised quickly. The Linux Foundation launched the Agentic AI Foundation on 9 December 2025, with Anthropic's Model Context Protocol (MCP) among its founding projects. MCP connects agents to tools and data. At launch, more than 10,000 MCP servers had been published. AWS, Google, Microsoft, OpenAI and Anthropic are all platinum members of the same neutral foundation.

The Agent2Agent protocol (A2A), created by Google and now hosted by the Linux Foundation, covers the other half: agents talking to agents. By its first anniversary in April 2026 it had more than 150 supporting organisations, production SDKs in five languages and a first stable specification, v1.0.

So agents can now find each other and exchange messages in a common format. Cisco's Luca Muscariello described A2A as "the syntactic layer that makes agent-to-agent communication reliable and interoperable." That is accurate, and it is also the point. A syntactic layer defines how messages are shaped. It does not tell you whether a message is true or who really sent it.

What the specifications leave out

MCP messages are unsigned, and tool definitions are served unsigned. A Cloud Security Alliance whitepaper from May 2026 notes that nothing in the protocol cryptographically vouches for what a tool definition says or where it came from. Tool-definition integrity, it says, "remains an open problem at the protocol level." MCP's August 2026 roadmap puts agent identity and delegated permissions among its five priorities. That is valuable work, but a published summary of the roadmap mentions nothing on signing, provenance or audit.

A2A v1.0 lets publishers sign their Agent Cards. As the foundation's own guide puts it, signing fixes card integrity, it does not fix identity. The same guide does not cover signing individual messages between agents, and it leaves audit to implementers.

Proposals to close the gap exist. An IETF draft published on 21 August 2026, known as MCPS, proposes signed message envelopes and signed tool definitions for MCP. It is an individual draft with no formal standing.

Where the attacks land

The record since April 2025 shows why this matters. That month, Invariant Labs disclosed "tool poisoning": hidden instructions in a tool's description that the model reads but the user never sees. The MCPTox benchmark later measured attack success rates of up to 72.8% across 20 models. In July 2025, CVE-2025-6514 in the mcp-remote package, with a severity score of 9.6 out of 10, let a malicious server run commands on a developer's machine. The package had been downloaded more than 437,000 times.

In September 2025, a fake Postmark MCP server on npm quietly copied every email to an attacker. Snyk and others describe it as the first confirmed malicious MCP server in the wild. In February 2026, a trojanised clone of the Oura MCP server was submitted to an MCP registry and delivered an infostealer. Being listed in a registry is not the same as verified provenance.

On the A2A side, Unit 42's October 2025 research on "agent session smuggling" showed a malicious peer agent triggering an unauthorised stock purchase. Unit 42 stressed that this is not a bug in A2A. It comes from agents being "designed to trust other collaborating agents by default."

None of these attacks broke the protocols. Each one exploited content the agent consumed but could not verify.

More connections, more to verify

Every new server or peer agent is another source of content a model will act on. Interoperability multiplies these connections, and most organisations cannot see them clearly. A 2026 CSA survey found that only 28% of organisations can trace agent actions to a responsible human or system across all their environments.

Unit 42's advice is the right starting point: "Practitioners should assume that agent-to-agent communication is not inherently trustworthy." The next step is for each message to carry its own evidence of who sent it and that it arrived unchanged.

Where Entangle Labs fits

This is the problem Entangle Labs is working on: a trusted communication layer in which messages between agents are signed and can be checked, whichever protocol carries them.

Entangle Labs

[Close]

Notes · Oct 2026

What 'verifiable' should mean for AI

"Verifiable" is becoming a common claim in AI, so it is worth being precise about what can be proven today and what still rests on trust.

Proof of what ran

The most practical tool today is the trusted execution environment, or TEE: a sealed area of a processor that the host machine cannot read or alter. A TEE can produce a remote attestation. This is a signed report, chained back to a key fused into the chip at manufacture, that contains hashes of the firmware and code that were loaded.

NVIDIA's approach shows how this works in practice. Its attestation service checks combined GPU and CPU evidence against published reference values. Only if they match are secrets, such as the keys that decrypt a model, released. NVIDIA's Blackwell systems support this across up to eight GPUs. NVIDIA claims inference performance of up to 98% of normal, and its own published figures for one large model show penalties of roughly 1% to 8%. Speed is no longer the main objection.

What attestation does not prove

Attestation proves that specific code was loaded on genuine hardware in a protected mode. It does not prove that the code is correct or safe. Someone still has to examine the code behind the hash. It does not show that a given output came from that run, unless the output is signed with a key tied to the enclave. And it is typically a one-off check at start-up.

It also rests on trust in the hardware. In autumn 2025, researchers showed that physical access can undermine it. The WireTap and Battering RAM attacks targeted older DDR4 systems. Then, on 28 October 2025, TEE.fail used off-the-shelf parts costing under $1,000 to snoop on DDR5 memory. The team extracted attestation keys from Intel's platform and extended the attack to NVIDIA's GPU confidential computing. With those keys, a workload could appear to run in a protected environment when it did not, and return wrong output alongside a successful attestation. There is no evidence of real-world use. Intel and AMD treat physical attacks as out of scope, and AMD has no plans to mitigate.

The lesson is not that TEEs are useless. A TEE attestation is a signed statement from hardware that a vendor vouches for. It is only as strong as the physical security of the host and the vendor's key infrastructure.

Layering trust

Apple's Private Cloud Compute is a useful reference. When Apple extended it to Google Cloud data centres in June 2026, it said it "does not rely solely on confidential computing." It tracks the hardware in a "cryptographically verifiable, append-only ledger," roots software attestation in "at least two separate roots of trust from independent vendors," and will publish all its binaries. Apple's devices check server attestations against a public transparency log.

Even here, verifiability depends on who decides which code counts as good. For Apple's service, that is Apple.

Proof without trusting hardware

Zero-knowledge machine learning, or zkML, takes a different route. It produces a mathematical proof that a committed model produced a given output, with no trusted hardware involved. Progress has been fast. A 2026 paper on the DeepProve system, marked for the CCS 2026 conference, reports end-to-end proofs of full language model inference. For GPT-2 it proves roughly 174 pieces of generated text per minute, and for Gemma 3 about 86, rising to 1,855 with distributed proving. Checking a proof takes between 1 and 3.7 seconds.

That is still too slow to prove every response from a production model. zkML also proves only that the committed model ran, usually a compressed version of it. It says nothing about whether that was the right model to use. Today it suits spot checks and high-value outputs.

A working definition

Taken together, verifiable AI should mean evidence at four levels. The hardware is genuine and accounted for. The code and model match reference values that others can inspect. Each output or action is bound to that environment by a signature. And the policy that was enforced is recorded somewhere tamper-evident. Any claim of verifiability should say plainly what it proves and what it still trusts.

This is the problem Entangle Labs is working on: running agents in secure compute environments where each run produces attested proof of what executed, with the limits of that proof stated openly.

Entangle Labs

[Close]

Notes · Oct 2026

From data feeds to agent inputs

An agent is only as reliable as what it reads, and today most agents have no way to tell where their inputs came from or whether anyone changed them.

The input is the attack

In June 2025, Microsoft patched EchoLeak, CVE-2025-32711, a critical flaw in Microsoft 365 Copilot found by Aim Security. An attacker sent an ordinary-looking email. When the user later asked Copilot a routine question, Copilot's retrieval engine mixed that email with sensitive internal data and leaked it. The user never had to click anything. Microsoft fixed it on the server side and reported no evidence of exploitation.

EchoLeak was not an outlier. In May 2025, Invariant Labs showed a malicious GitHub issue steering an agent into leaking private repository data through a public pull request. Invariant called the flaw "architectural", meaning no server-side patch could fix it. In April 2026, hidden instructions in Grafana log entries led its AI assistant to send data out.

By 2026 this had moved beyond research. The Cloud Security Alliance says indirect prompt injection "has crossed the line from proof-of-concept to live exploitation." Citing Google, it reports a 32% rise in malicious injection content on crawled web pages between November 2025 and February 2026.

Each case has the same root. The agent treated content from an email, an issue tracker or a log file as if it carried the user's authority.

Small amounts of bad data go a long way

Poisoning works with less data than most people assume. In October 2025, Anthropic, the UK AI Security Institute and the Alan Turing Institute published a study showing that as few as 250 malicious documents could plant a backdoor in models from 600 million to 13 billion parameters. The number needed stayed roughly constant as models grew. The authors are careful about the limits. The backdoor was low-stakes, making the model produce gibberish, and it is unclear whether the result holds for larger models or more harmful behaviour.

Retrieval systems are more exposed, because their content can change at any time. The PoisonedRAG study, presented at USENIX Security 2025, inserted five malicious texts per target question into a knowledge base of millions and steered the answers 90% of the time.

"It is a tiny fraction of our data" is not a defence.

Provenance tools exist, in pieces

Businesses already expect the data feeds they rely on to come from a named, accountable source. Most of what an agent reads offers no such assurance. There is no single standard for proving where agent inputs came from, but there are useful building blocks.

C2PA Content Credentials attach signed records of origin to images and video. RFC 9421, the IETF standard for HTTP Message Signatures, lets an API sign its responses so that integrity survives proxies and gateways along the way. As one explainer puts it: "TLS secures the pipe. A message signature secures the letter."

Government guidance points the same way. A joint paper from CISA, the NSA and the FBI in May 2025, written with partner agencies in Australia, New Zealand and the UK, recommends tracking data provenance, hashing data and verifying those hashes, and using content credentials for web-scale data.

Origin is not truth

All of these tools prove origin and integrity. None of them proves the content is correct or benign. In 2025, a flaw in Nikon's Content Credentials firmware let unauthentic images keep a valid signature, and Nikon had to revoke certificates. A perfectly signed email can still carry a prompt injection.

So provenance has to come with policy. An agent should know where each input came from, whether it arrived unchanged, and what that source is allowed to ask it to do. A signed figure from a known supplier and an anonymous comment on a web page should not carry the same weight. In the incidents above, they effectively did.

This is the problem Entangle Labs is working on: verified provenance for the data agents act on, so that each input carries a checkable record of where it came from.

Entangle Labs