Access control answers one question: can this identity reach this resource. Execution control answers a different one: does this specific command fit what this session said it was for. A jump host in front of the cluster only answers the first. The tools that came after it get closer—Teleport gates the exec verb, others match the command string against a list written in advance—but a fixed pattern still can't express the session's declared purpose.
A jump host authenticates the connection to the cluster. It has no opinion about the kubectl exec command that runs once you're on the other side—whether that command is typed by a person or issued by an agent or automated job calling the same API. That gap is easy to miss because routing everyone through one hardened bastion feels like the responsible version of direct kubectl access from a laptop. But authenticating who gets on the box and governing what they do once they're on it are two different problems, and a jump host only ever solves the first one.
The privilege you inherit, not the privilege you're granted
In the setup Hirschberg describes, a jump host lands an operator in a shell with a kubeconfig already loaded—as ARMO CTO Ben Hirschberg wrote in a 2023 piece on jump-host risk, it arrives "most likely with cluster administration privileges." That's convenient—nobody wants to re-authenticate to the cluster every time they hop through the bastion. It's also the risk: when that's how the box is set up, whoever controls the SSH session controls the cluster—a phished credential or a hijacked session hands over whatever that kubeconfig was bound to, and it's usually bound wide. RBAC is still evaluated on every request—where that shell carries cluster-admin, it just has nothing left to restrict.
It's not only attackers who benefit from that gap. The same absence of command-level judgment is why a wrong-context kubectl delete or kubectl apply—someone forgetting they'd switched their kubeconfig to production—runs exactly as typed; nothing at the shell layer asks which cluster you meant, and the jump host did its job the moment you logged in. A compromised credential and a fat-fingered context switch are different failure modes, but they share the same root cause: nothing between the shell and the API server asks whether this particular command belongs here.
Hirschberg's piece makes the harder point too: defeating the jump host's SSH auth and defeating a properly authenticated, directly exposed Kubernetes API endpoint both come down to breaking the same grade of cryptography. The bastion doesn't raise the bar much. It adds a hop, and one more configuration to get right.
Gating the verb isn't the same as judging the command
Teleport, for instance, gates the exec verb—whether you're allowed to open a shell into a given pod or namespace at all—and stops there. Other tools go further and match the command string itself against a static allow- or deny-list before it runs. Either way, a pattern written in advance decides the outcome, not a judgment about this specific command in this specific session. kubectl exec payments-pod -- psql -c 'select * from customers' is the same string whether the session was opened to debug a failing query or to copy the table out—a static list sees one command either way; it can't express the difference the session's declared purpose actually makes.
That's the same access-control/execution-control split that shows up across infrastructure security, just relocated to a newer surface. Access control answers "should this identity be able to reach this resource." Execution control answers "should this specific command run, given what this session is supposed to be doing." Verb-gating and static command matching are both still access control, applied at a finer grain—neither one is built to ask the second question.
What AlpacaX's Alpacon proposes
What's left is re-checking the commands actually issued by a user or agent that already holds access. But on paths where AI is the one running the command—the command API, MCP—having a person judge each one becomes the bottleneck. Diagnosing that risk upfront, and pointing the direction from there, is the part AI has to own.
A kubectl exec command that arrives through Alpacon's exec lane—the command API, MCP, an agent's execute—is judged whole, inner command included, against the purpose the session declared before it runs. Rules first, then a behavioral baseline, then an LLM's read of intent—the same scoring any other command on that lane gets. A command the risk lane scores in the grey zone can be held for out-of-band human approval before it runs.
That's a different answer to "the jump host trusted me completely once I was in."
The lesson isn't about which vendor's box people SSH through. That gap widens as more of the kubectl exec commands hitting a cluster are issued by an agent instead of typed by a person. If nothing evaluates the command itself, the access control was never the control that mattered.
FAQ
Does gating the kubectl exec verb solve this? Only partly. Verb-gating, like Teleport's control over the exec verb, decides whether a shell can be opened into a pod at all. It's still access control applied at a finer grain—it doesn't judge the command run once that shell is open.
Does a static command allowlist solve this?
No. A fixed pattern written in advance returns the same verdict for the same command string regardless of the session's purpose. kubectl exec payments-pod -- psql -c 'select * from customers' reads identically whether the session was opened to debug a failing query or to copy the table out.
