Question: signed receipts for selected Kubernetes MCP action / diagnostic handoffs?

Hi — I found mcp-kubernetes while looking at MCP servers where agents can interact with Kubernetes clusters, run kubectl operations, produce diagnostics, and hand action results to another user, workflow, reviewer, or audit/debugging process.

I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected claims, actions, artifacts, or handoffs that cross trust boundaries:

https://github.com/cullenmeyers/BoundaryAttest

The idea is not to replace mcp-kubernetes’s local MCP setup, kubeconfig model, kubectl behavior, access-level filtering, Kubernetes audit logs, OpenTelemetry traces, Helm/Cilium/Hubble records, or normal MCP/client logs. The receipt only proves a narrow claim:

> a specific signer signed a specific claim, and the signed claim has not been altered.

mcp-kubernetes seemed relevant because it exposes Kubernetes operations through MCP: querying resources, executing kubectl commands, managing clusters through natural-language interactions, diagnosing Kubernetes state, filtering tools by readonly/readwrite/admin access level, and optionally enabling Helm, Cilium, and Hubble commands.

A BoundaryAttest receipt could potentially bind selected events like:

- MCP server/tool reference;
- Kubernetes cluster/context/namespace reference;
- access level, such as readonly, readwrite, or admin;
- kubectl/helm/cilium/hubble command digest;
- request/action digest;
- resource group/version/kind/name reference;
- permission check or `kubectl auth can-i` result hash;
- diff/apply/create/delete/patch/replace result hash;
- rollout/scale/status result hash;
- pod logs/events/top/exec/cp result hash;
- context-switch reference;
- OpenTelemetry trace/span reference;
- status, such as checked, refused, executed, applied, created, deleted, patched, scaled, diagnosed, failed, exported, or handed off;
- timestamp/event ID;
- signer/public key ID.

The strongest use case would be when a Kubernetes diagnostic result, permission check, kubectl command result, rollout/scale action, pod exec/log result, Helm/Cilium/Hubble output, incident packet, or audit/debugging handoff leaves the local MCP runtime, and the recipient should not have to fully trust a screenshot, copied JSON, transient command output, or local agent transcript.

BoundaryAttest would not prove the Kubernetes action was safe, the operator was authorized, the kubeconfig identity was appropriate, the diagnosis was correct, the cluster was uncompromised, the final state stayed unchanged, or the access-level filter was a legal/security authorization boundary. It would only prove that a specific claim about a selected mcp-kubernetes action/artifact/handoff was signed and has not been altered after export.

Does this kind of portable signed receipt fit anything you imagine around mcp-kubernetes, especially around diagnostic reports, permission checks, refused/filtered operations, kubectl results, rollout/scale changes, pod exec/logs, Helm/Cilium/Hubble outputs, or incident/audit handoffs? Or are Kubernetes audit logs, OpenTelemetry traces, MCP responses, and normal local records enough for the current scope?

No pressure if it is not relevant — I’m mainly trying to learn whether signed receipts are useful around local MCP tools that can perform consequential Kubernetes operations.

The issue names no repository files, tests, or concrete entry points to change. Start by reviewing the MCP Kubernetes tools and the existing audit logs, OpenTelemetry traces, MCP responses, and local records it mentions; done would require a clear maintainer decision about whether portable signed receipts fit the project's scope.

Written by the indexing model from the issue text.