Confidential integrations and attested MCP servers · next release

Cameleer can prove what it runs.

Q: Is attestation released?

It is on Cameleer's main branch and ships in the next release after 0.5.1. Its tests use a simulated configfs-tsm and a simulated dstack agent; it has not yet been run on real TEE hardware.

Run Cameleer in a confidential VM and a client, or an agent's MCP client, can ask it for hardware evidence of the exact routes, configuration and MCP tools it is running, bound to the client's nonce and to the TLS connection the client is using. That is confidential computing applied to the integration itself, not only to the machine under it. The action layer already makes every agent action checked, run once, approved and audited; attestation lets the caller check which routes those are.

Status: on the main branch, in the next release after 0.5.1. The tests use a simulated configfs-tsm and a simulated dstack agent; it has not yet run on real TEE hardware. What it does not prove.

What a report proves

The TEE signs 64 bytes (REPORTDATA) that Cameleer computes from four things. A client that recomputes them knows the evidence was made for its own connection, now, by a process running that manifest.

Your nonce

16 to 64 random bytes the client sends, so a report can't be replayed.

The TLS key

The SHA-256 of the server's own TLS public key. A proxy that terminates TLS in between changes the key, and the check fails.

The manifest

Cameleer's version and features, every route file with its SHA-256, every route, the configuration with secret values replaced by <secret>, and the published MCP tools with their fingerprints.

The change log

A hash-chained record of every change after start-up: a route added or removed, a tool turned off with the kill switch.

REPORTDATA = SHA-512( "cameleer-attest-v1" || 0x00
                    || manifest digest (the log's head, SHA-384)
                    || SHA-256 of the server's TLS public key
                    || nonce length || nonce )

Turn it on, fetch it, check it

In the confidential VM

# application.properties
camel.attestation.enabled=true
# optional: also as an MCP tool
camel.attestation.mcp-tool=true

At start-up Cameleer finds an evidence source (dstack first, then Linux configfs-tsm). If attestation is on and none works, start-up fails: a process asked to be attested never runs looking attested when it isn't.

Three ways to fetch a report

HTTP: GET /q/attestation?nonce=...
MCP handshake: _meta["ing.cameleer/attestation"] in server/discover (2026-07-28) and initialize (earlier versions); a client that sends a nonce gets the full report in the same round trip
MCP tool: cameleer_attestation(nonce), for clients that only speak tools

A client checks two things

The binding. Recompute REPORTDATA from the manifest digest, the TLS key seen on its own connection and the nonce it sent; check the log chain ends at that digest. In Rust: cameleer_attest::check_binding.
The hardware signature. Verify the TDX quote or SEV-SNP report against Intel's or AMD's roots and the platform measurements with the platform's verifier: Intel Trust Authority, Microsoft Azure Attestation, Google's verifier, or dstack's.

Then decide: is this the image digest you reviewed, are these the routes and tools you expect?

curl "https://orders.example.com/q/attestation?nonce=$(openssl rand -base64 32 | tr '+/' '-_' | tr -d '=')"

Who it is for

Agent builders: an attested MCP server

An agent that calls tools has to trust the server behind them. With Cameleer in a confidential VM, the MCP client can ask in the handshake which routes and tools the server runs, bound to the session's TLS connection, and refuse a server whose manifest isn't the one it expects. The MCP specification has no standard for this yet; Cameleer's design stays inside the spec with a vendor-prefixed _meta entry.

Regulated data: confidential integration

Healthcare, finance and the public sector already run sensitive workloads in confidential VMs. The integration engine moving that data is part of the workload: with Cameleer it can show an auditor or a partner which routes and configuration processed the data. We found no other integration engine or iPaaS that advertises attestation of its own routes (searched November 2026).

Where it runs

evidence source	where	platforms	status
Linux configfs-tsm	`/sys/kernel/config/tsm/report` (Linux 6.7 and later)	Intel TDX and AMD SEV-SNP confidential VMs	supported (next release)
dstack guest agent	`/var/run/dstack.sock`	dstack CVMs on Intel TDX: Phala Cloud, dstack on Google Cloud	supported (next release)
AWS Nitro Enclaves	NSM device	AWS	not yet
Azure vTPM attestation	vTPM, Microsoft Azure Attestation	Azure confidential VMs	not yet
Google Confidential Space	attestation tokens	Google Cloud	not yet

What it does not prove (yet)

Cameleer doesn't verify hardware evidence. It produces the evidence and the binding; checking Intel's or AMD's signature chain is the client's verifier's job. A gateway that refuses tools from MCP servers that don't attest is planned.
No sealed secrets yet. Releasing secrets only to an attested process is planned.
Not yet run on real TEE hardware. The tests use a simulated configfs-tsm and a simulated dstack agent; the report formats follow the kernel ABI and dstack's API.
"This exact release" needs a pinned image. Reproducible builds aren't published yet, so pin the image by digest (pmsudhi/cameleer@sha256:...) and let the platform measurement identify the build you reviewed.
Physical attacks. TEEs trust the cloud's physical security as well as the CPU vendor; memory-bus interposers (TEE.fail, 2025) have extracted keys from TDX and SEV-SNP machines.
Runtime changes are recorded, not prevented. The log shows a route added after start-up; refusing it is the verifier's decision.
A model showing evidence is not checking it. Only a program that checks the binding and the signature gets the guarantee.

The full reference, with every property: Attestation in confidential VMs. Security of the TLS stack itself: TLS and security.

Common questions

Can an MCP client check what a Cameleer server is running?

Yes, when Cameleer runs in a confidential VM (next release). The client sends a nonce in server/discover or initialize and gets a hardware-signed report bound to that nonce, to the SHA-256 of the server's TLS key and to a manifest of the routes, configuration and MCP tools. The client checks the binding (cameleer_attest::check_binding in Rust) and verifies the hardware signature with the platform's verifier.

What is confidential integration?

Running integration routes inside a confidential VM, where the hardware encrypts memory and can attest what software runs. With Cameleer the evidence covers the integration itself: the route files, the routes, the configuration (with secret values left out) and the MCP tools it publishes, not only the virtual machine.

Does Cameleer verify Intel or AMD attestation evidence?

Not yet. Cameleer produces the evidence and the binding; a verifier such as Intel Trust Authority, Microsoft Azure Attestation, Google's verifier or dstack's checks the hardware signature chain. Verifying remote MCP servers inside Cameleer is planned.

Which confidential computing platforms does it support?

Intel TDX and AMD SEV-SNP confidential VMs whose Linux kernel (6.7 or later) exposes configfs-tsm, and dstack CVMs such as Phala Cloud or dstack on Google Cloud TDX. AWS Nitro Enclaves, Azure vTPM attestation and Google Confidential Space are not supported yet.

Is it enough for an AI model to call the attestation tool?

No. A model that shows evidence is not checking it. Only a program that checks the binding and the hardware signature gets the guarantee; the cameleer_attestation tool exists so that clients which only speak tools can fetch the report for such a program.

Is attestation released?

It is on Cameleer's main branch and ships in the next release after 0.5.1. Its tests use a simulated configfs-tsm and a simulated dstack agent; it has not yet been run on real TEE hardware.