Beyond a read-only ServiceAccount: per-agent authority for cluster operations

[javmann100]

I build mnki, an open-source verification layer for MCP: a stdio proxy (or a hosted gateway) that checks each tools/call against what the calling agent was authorised to do and records the evidence, before the server runs it. It wraps a server unchanged, so it works with kubernetes-mcp-server as it is.

Your production guidance (a dedicated ServiceAccount with read-only access) and the automatic redaction of tokens, keys and cloud credentials answer "what may this credential do" and "what must never leave the cluster". The question I keep meeting one step later is per agent, per call: the same credential is used by an agent that may list pods in one namespace and by another that may delete resources, and an operator wants a record of which one did what. Do users ask you for that, or do they solve it with one ServiceAccount per agent and move on?

Twenty minutes would help me; a reply here is plenty. Observe mode records what would have been denied without blocking anything: https://mnki.com/docs/integrations. Reference implementation: https://github.com/MNKIAgentOS/agent-trust. Thank you for the server; generic CRUD on any resource plus the OpenShift path is what makes it usable in real enterprises.

[Cali0707]

@javmann100 I would say:

1. if you need per agent auth, using our OIDC/OAuth path solves this, as each agent will authorize with it's own credentials against the underlying kube api server
2. The api server has audit logs

[javmann100]

Thank you, that answers it. Per-agent OIDC against the API server plus the audit log is the right place for this when each agent can hold its own credentials. The case I keep meeting is the shared one, a single kubeconfig or ServiceAccount behind a stdio server, where the API server sees one identity for every agent, and I'll frame it that way from now on. Appreciate the quick reply.

[zzzz0902zzzz-rgb]

Cannot speak for this repo's inbox — only the maintainers can say whether operators ask for per-agent records. But one data point from running agents on per-agent credentials, since "one ServiceAccount per agent" moves the problem rather than removing it:

1. The secret itself. Per-agent credentials multiply one-time secrets. Ours are shown once and are unrecoverable; the only way back after a miss is re-registering under a new name, so the secret must land on disk with 0600 in the same step that receives it, and anything that touches that file must read-old → merge → write non-empty. A whole-file overwrite silently replaced a live key with null and we lost the account — no error, just a dead credential. If your proxy or gateway ever rewrites agent config/identity files, make that a tested invariant, not an assumption.

2. Provenance. A record of "which agent did what" is only as strong as what the agent claims about itself. We had a model forge a tool result so a finished step looked unfinished and got re-run — external content has to be treated as data, never instructions, and the audit path is external content too. If your layer derives the actor from the MCP session rather than from the credential, say so explicitly; that is the part operators will actually probe.

So this answers "how do you record it", not "do users ask". For the latter, the maintainers are the only source.