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

Hi — I found AKS-MCP while looking at MCP servers where agents can interact with Azure Kubernetes Service, run AKS/Kubernetes 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 AKS-MCP’s local-only trust model, Azure/Kubernetes credentials, Azure CLI behavior, kubectl/helm/cilium/hubble execution, `--access-level` guardrails, denylist, Azure logs, Kubernetes audit logs, or normal local MCP/client records. The receipt only proves a narrow claim:

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

AKS-MCP seemed relevant because its README is very explicit about the trust boundary: it is designed for a single trusted local user, runs with the process identity, does not perform per-caller authorization, and `--access-level` is a guardrail rather than a security boundary. That clarity makes it easier to ask a narrow question: when an AKS-MCP action or diagnostic result leaves the local runtime, would a portable signed receipt be useful?

A BoundaryAttest receipt could potentially bind selected events like:

- AKS-MCP tool reference;
- Azure subscription / resource group / AKS cluster reference;
- Kubernetes context / namespace / resource reference;
- access level, such as readonly, readwrite, or admin;
- Azure CLI or kubectl command digest;
- denylist / guardrail decision reference;
- request/action digest;
- AKS diagnostic result hash;
- Azure monitoring/KQL result hash;
- kubectl/helm/cilium/hubble result hash;
- generated report or handoff artifact hash;
- status, such as checked, refused, executed, diagnosed, updated, failed, exported, or handed off;
- timestamp/event ID;
- signer/public key ID.

The strongest use case would be when an AKS-MCP diagnostic result, command outcome, denied/refused operation, cluster-change summary, monitoring query, debugging packet, or incident handoff is passed to another developer, platform team, reviewer, downstream agent, support process, or future audit trail, and they should not have to fully trust a screenshot, copied JSON, local MCP transcript, or transient local workstation state.

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

Does this kind of portable signed receipt fit anything you imagine around AKS-MCP, especially around diagnostic reports, refused/guardrailed operations, Azure CLI or kubectl results, cluster-change summaries, or incident/audit handoffs? Or are Azure logs, Kubernetes audit logs, local MCP records, and the current local-only trust model 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 AKS operations.

Start with the AKS-MCP README's stated local-only trust model and the referenced BoundaryAttest project to understand the proposed boundary. No source file, test, or entry point is named; the work is only complete once maintainers define whether signed receipts fit the current scope and identify a concrete, bounded implementation target.

Written by the indexing model from the issue text.