Zero Proof zkTLS for agentic MCP tools

When AI agents interact with external systems, they increasingly rely on tools, APIs, and web services to make decisions. These tool calls may be simple, but in many real-world settings they carry sensitive information, user context, or critical business facts. The question then becomes: how do we know the agent actually accessed the right source and used the correct data?

This is the problem Zero Proof zkTLS is designed to address.

At a high level, Zero Proof zkTLS is a form of Behavioral Attestation: it makes it possible to prove that an agent observed a real HTTPS interaction and extracted a relevant fact, without revealing the entire underlying response. That matters when the agent is acting on behalf of a user, invoking tools through an MCP server, or passing data into downstream systems that need trust but also require privacy.

---

Why build this?

The core issue is not that agents cannot fetch data. The issue is that normal tool calls and web requests do not provide strong provenance.

A typical API call gives us a result, but not proof that:

• the request went to the expected service,
• the connection was valid and authenticated,
• the response was not manipulated in transit,
• or the returned fact was extracted correctly from the real source.

For many agent applications, this is not enough.

An agent may claim that it checked a booking status, verified a user attribute, confirmed eligibility, or retrieved a record from a third-party service. Without a stronger proof layer, those claims are mostly trust-based. The system must assume the agent is honest, or trust the server that returned the result.

That model breaks down quickly when the workflow is sensitive, regulated, or security-critical.

Zero Proof zkTLS addresses this by putting a verifiable Behavioral Attestation layer between the agent and the external system. The goal is not to replace web traffic; it is to make the resulting data claim auditable and privacy-preserving.

---

Where this fits in the agent stack

This work is especially relevant for MCP-based tool execution.

MCP servers are becoming the standard way for agents to access tools, services, and external capabilities. In that architecture, an agent may call a tool that reads from a remote service, triggers a workflow, or returns structured data. The important question is whether the tool output is trustworthy enough to be used in a decision.

The issue is not only whether the tool responded. It is whether the result can be tied back to a real, authenticated source without leaking sensitive details.

This is where Behavioral Attestation adds value: Zero Proof zkTLS integrates proof generation into the tool-calling flow itself.

Instead of treating every MCP tool call as a plain function invocation, the flow can include:

• attestation of the underlying HTTPS interaction,
• proof that the relevant fact was observed in that interaction,
• selective disclosure of only the needed claim,
• and redaction of anything that should remain private.

This creates a stronger trust boundary for tool execution and makes the agent’s output easier to verify downstream.

---

What makes Zero Proof zkTLS different from a normal API call?

A standard API request is a convenience mechanism. Behavioral Attestation is closer to a proof mechanism.

It does not just return data. It gives the system a way to reason about the data as a verifiable claim.

In practical terms, that means the system can ask:

• Did this response come from a real HTTPS endpoint?
• Was the endpoint the one the user or agent intended to call?
• Was the data observed in a valid session?
• Was the relevant fact extracted correctly?
• Can we prove it without exposing unrelated private fields?

That is different from ordinary web access, where the result is generally trusted as long as the call returned successfully.

For high-trust workflows, that distinction matters.

---

What technology is involved?

Zero Proof zkTLS sits in the broader family of privacy-preserving web attestation systems, and more specifically in the category of Behavioral Attestation. The approach combines several technical layers:

• TLS for the real HTTPS interaction
• attestor or proxy-based observation of the encrypted session
• ECDSA signatures from attestors
• local decryption of the response on the client side
• zero-knowledge proof generation over the extracted facts
• selective disclosure and redaction logic
• verification logic that checks the proof and the attestation

The practical pattern is:

1. the client or proxy connects to the target service via an attested path,
2. the attestor observes the encrypted session and confirms the connection integrity,
3. the client locally decrypts the relevant response,
4. the client generates a proof that it knows the relevant fact,
5. the proof is bound to the attestation and returned alongside the result,
6. the verifier checks the attestation and the proof without learning unnecessary data.

This is not simply “the client claims it saw something.” It is a stronger model: an independent witness observes the session, and the client proves relevant knowledge of the data without exposing the entire underlying record.

---

Why zero-knowledge proof is important

Zero-knowledge proof is the key to making this useful in real systems.

Without it, the verifier would have to either:

• reveal the whole response,
• reveal too much about the response,
• or trust the agent’s summary without independent evidence.

In many production settings, none of those options is acceptable.

With zero-knowledge proof, the system can instead prove a specific fact. For example:

• the response contains a valid booking identifier,
• the user attribute matches a required value,
• the extracted field is present in the authenticated response,
• the condition holds without disclosing the rest of the data.

This is the essence of selective disclosure.

It is precisely what matters in agentic workflows: the agent may need to prove a claim without revealing all of the private data behind the claim.

---

Why this is useful for AI agents

The value of Behavioral Attestation becomes clear when an agent is responsible for acting on external data.

In many cases, the agent is not just reading data for display. It is using it to:

• decide whether to continue a task,
• trigger a downstream workflow,
• pass information to another service,
• validate user claims,
• or submit a result into a trust-sensitive system.

In those scenarios, trust must be explicit.

If the system accepts tool outputs without proof, then the decision pipeline is only as trustworthy as the agent and the tool backend. That is often too weak for production-grade automation.

By attaching a proof to the tool call, the system can reason about the claim with stronger evidence. The output is no longer just a convenient response; it is a cryptographically-backed statement about the observed source data.

---

Where the broader ecosystem stands

This is part of a broader set of approaches for proving things about web data while preserving privacy. Reclaim Protocol is one prominent example of a service that applies this model in a developer-friendly way. TLSNotary is another well-known example in the same space, with a similar emphasis on proving facts about HTTPS data without exposing the full transcript. In this context, Behavioral Attestation is the framing: the goal is not merely to attest a network session, but to attest an agent’s observed behavior in a way that is verifiable and privacy-preserving.

So the right framing is not that Zero Proof zkTLS is entirely brand new in the abstract. The insight is more specific: we are applying this class of attestation and proof technology to an agent and MCP tooling flow, where the proof is attached to tool execution and the result is usable in a secure automation stack.

The main differentiator is not a claim to uniqueness in theory. It is the practical integration: the proof layer sits directly in the agent-tool path and gives developers a way to preserve normal tool semantics while adding verifiable evidence and selective disclosure.

---

SDK support and developer ergonomics

A proof system is only useful if it is practical to integrate.

We therefore provide SDK support for using the attestation service in normal application code and agent flows. This makes it easier to:

• call proof-aware endpoints,
• configure redaction behavior,
• generate attestation-backed proofs for selected tool results,
• and integrate the flow into an MCP-oriented architecture without forcing developers to rework their existing tool model.

The SDK aims to keep the developer experience simple while preserving the underlying trust guarantees. In practice, that means developers can continue to work with familiar tool interfaces and response objects while the proof metadata is attached in a structured, verifiable way.

For developers who want to explore the underlying implementation and client libraries, the relevant repositories are:

• The zkTLS repo: https://github.com/Zero-Proof-AI/zkfetch-wrapper
• The Python SDK fork: https://github.com/Zero-Proof-AI/zeroproof-python-sdk
• The Rust SDK fork: https://github.com/Zero-Proof-AI/zeroproof-rust-sdk

These repositories provide the code paths and client libraries needed to experiment with the flow, integrate proof-aware requests, and extend the behavior into custom agent tooling.

---

Why privacy and verifiability must coexist

In many systems, privacy and trust are treated as opposing goals. One is sacrificed for the other.

Behavioral Attestation is valuable precisely because it shows that they do not have to be.

The system makes it possible to verify a fact without revealing the full underlying record. That is the central design principle.

This is especially important in AI systems, where tool results can contain personal or sensitive context. A proof framework that reveals everything would defeat much of the point. A proof framework that reveals nothing would be unverifiable. Zero Proof zkTLS sits in the middle: it gives enough evidence to trust the fact, while keeping unrelated data hidden.

---

Conclusion

Behavioral Attestation is about solving a real trust problem in agentic systems.

The problem is straightforward: as agents call tools and read external data, the downstream system needs evidence that the agent saw the right thing from the right service without exposing everything. Traditional tool calls do not provide that evidence.

By combining attestation, selective disclosure, and zero-knowledge proof, Zero Proof zkTLS creates a practical trust layer for MCP-driven agent workflows. It allows a tool result to carry proof that the underlying fact was observed in a real HTTPS session, while keeping sensitive parts hidden.

That is the real value: not just proving that a tool responded, but proving that the agent observed the correct fact from the correct source, in a way that preserves privacy and supports downstream verification.

In short, Behavioral Attestation gives agent systems a way to move from implicit trust to verifiable trust without sacrificing privacy.