How can ChatGPT and an MCP tool executor mutually verify tool calls and results end-to-end?

ChatGPT Apps SDK
, , , ,
1

I’m looking for an official way to guarantee end-to-end integrity in both directions when a public relay sits between ChatGPT and the final MCP tool executor.

The generic architecture is:

ChatGPT -> public HTTPS MCP server/relay -> final executor

and for the response:

final executor -> public HTTPS MCP server/relay -> ChatGPT

TLS, OAuth and mTLS can protect individual transport links, but they do not solve the case where the public relay itself is considered potentially compromised.

Once TLS terminates at the relay, the relay can theoretically modify:

  • the tool name or arguments before they reach the final executor;
  • the tool result before it reaches ChatGPT.

So there are two separate requirements:

  1. The executor must be able to verify that the exact tools/call it received is the one ChatGPT/OpenAI generated.
  2. ChatGPT/OpenAI must be able to verify that the exact tool result it received is the one the final executor generated.

The relay should only transport messages and should not have to be trusted for their integrity.

Conceptually, one solution could be bidirectional signatures:

OpenAI signature(session / tool_call_id / tool_name / hash(arguments) / timestamp / executor_id)

and on the return path:

Executor signature(session / tool_call_id / hash(result) / timestamp)

The executor would verify the first signature using an OpenAI public key, while OpenAI would verify the result using a public key registered for that executor.

I have not found a mechanism in the current MCP/ChatGPT documentation that provides this complete bidirectional guarantee. OpenAI Developer Community

Is there an existing supported way to achieve this?

If not, would OpenAI consider a primitive such as one of the following:

  • Bidirectionally signed MCP messages: OpenAI signs each tools/call, and the final executor signs each corresponding tool result. Both endpoints independently verify the payload received through the relay.

  • Bidirectional signed attestations: instead of signing the MCP messages themselves, OpenAI attaches a signed attestation containing the hash and metadata of the tool call, while the executor attaches an equivalent signed attestation for the result.

  • A canonical verification API: the executor could submit the tool_call_id plus the received tool name/arguments or their hash to an OpenAI endpoint and ask whether they exactly match the call generated by OpenAI. In the reverse direction, the executor could independently register the hash of the result with OpenAI, allowing ChatGPT to reject any result delivered by the relay that does not match what the executor registered.

  • An end-to-end authenticated envelope: the relay could transport an opaque cryptographically authenticated message between OpenAI and the final executor. The call would be authenticated for the executor, and the result authenticated for OpenAI, so modification by the relay in either direction would be detectable.

Replay protection could presumably be provided by binding these proofs to tool_call_id, session/context, intended endpoint, timestamp/expiry and/or a nonce.

The core issue is therefore not user authentication or protection against arbitrary clients. It is mutual end-to-end integrity between ChatGPT/OpenAI and the final tool executor when every intermediary MCP relay is outside the trusted computing base.

3

For anyone interested, I ended up using a client-generated key shared by the two endpoints, with authenticated encryption and replay protection.

That lets the relay remain completely untrusted: even if it is compromised, it cannot read, alter, forge, or replay valid messages.

So this effectively solves the practical issue I was trying to address in the original post.