When Your CLI Speaks English: Least Authority for Promptable Infrastructure

A platform team I talked to this quarter shipped a Slack bot that wrapped kubectl and accepted English. An engineer typed "clean up the unused branches in staging." The bot helpfully deleted twelve namespaces — including one whose name matched the substring "branch" but which happened to host a long-lived integration environment that the mobile team had been using for a week. No exception was thrown. Every individual call the bot made was a permission the bot legitimately held. The post-mortem could not point to a broken access rule, because no rule was broken. The bot did exactly what its IAM policy said it could do.

The Unix philosophy was a containment strategy hiding inside an aesthetic preference. Small tools with narrow surfaces meant that the blast radius of any single command was bounded by the verbs and flags it accepted. rm -rf was dangerous because everyone agreed it was; kubectl delete namespace required the operator to type out the namespace, and the typing was the gate. The principle of least authority was easy to enforce because authority was lexical: the shape of the command told you the shape of the action.

Then the wrappers started accepting English. Now "the shape of the command" is whatever the LLM decided it meant.

The wrapper is the new confused deputy

The classical confused-deputy pattern — a privileged program tricked by a less-privileged caller into misusing its authority — was supposed to be a relic. It was the kind of bug you saw in early capability systems and decades-old setuid binaries. The recent surge in promptable infrastructure has resurrected it as the dominant authorization failure mode of agentic systems. The Cloud Security Alliance's 2026 research note on agent confused-deputy attacks frames the dynamic precisely: when an AI agent holds broad credentials to act on an operator's behalf, every input channel the agent processes becomes a candidate for authority abuse. An adversary who can write to a Jira ticket, a retrieved document, a tool response, or a Slack message can inject instructions that execute with the operator's full permissions.

But notice: prompt injection is the spectacular case. The everyday case is much quieter. The "deputy" gets confused by its own user, in good faith, because the user asked for "delete the unused branches" and the deputy decided what "unused" meant.

Promptable infrastructure inherits the worst property of natural language: it is paraphrase-rich. The same intent can be phrased a thousand ways, and the same phrase can be interpreted as a thousand intents. A traditional CLI is a parser; a promptable CLI is an interpreter that resolves an underspecified spec into a concrete plan, and then executes the plan with the user's full authority. Every wrapper that translates intent into commands is now sitting on top of an authority-expansion machine.

The Unix model gave you containment by limiting the cardinality of the command set. The promptable model gives you a command set whose cardinality is the size of the language. The blast radius is no longer bounded by the verbs the tool accepts; it is bounded by the imagination of whatever model parses the request.

RBAC was written for verbs, not intents

The IAM stack the industry built for the previous decade — RBAC, sudo, capability tokens, OPA policies, IAM conditions — assumes the principal makes a discrete action request and the policy engine answers yes or no. The grammar is (subject, verb, resource, condition) → allow | deny. It works because verbs are stable nouns: s3:GetObject, pods/delete, secrets/list. You can write a policy against the verb because the verb has a fixed meaning.

Natural language has none of those properties. "Help me clean up the staging environment" is not a verb; it is an underspecified intent that compiles, at runtime, into a sequence of verbs the policy engine has never seen as a unit. RBAC can tell you whether the agent is allowed to call pods/delete. It cannot tell you whether deleting these particular pods was within the scope of what the user asked for. The policy engine sees the leaves; the authorization question lives in the tree.

The 2026 framing emerging from the agent-security research community is that this gap deserves its own name: semantic privilege escalation. The Acuvity write-up describes it as the case where the agent stays within its formal permissions while exceeding the authority the user actually delegated. The arXiv work on "Prompt Flow Integrity" (2503.15547) makes the same point at the architecture level: per-call authorization is necessary but not sufficient, because the policy that matters is the policy on the plan, not the policy on each individual step. SUDO, the attack framework from the 2503.20279 paper, demonstrates the symmetric offensive case: a "Detox2tox" pipeline that rephrases a refused harmful request into a benign-looking sequence of authorized actions, then reassembles the harm at execution time. In each of these, the agent never asked the policy engine for anything it didn't already have.

This is why "give the deploy bot LLM access" is one PR away from "give the deploy bot full admin." The bot didn't get more permissions. The natural-language surface in front of those permissions just got large enough that any subset of them is now reachable through some phrasing.

Intent-bound tokens: sign the English, pin the plan

The architectural primitive that fits this problem is one the IAM industry has flirted with for years and is now being pushed into actual deployment: an intent-bound token. The idea is straightforward and has antecedents in macaroons, biscuits, and the various capability-token designs from the early 2010s. The new wrinkle is that the bound thing is the user's English, not just a scope.

The mechanics:

1. The user submits an intent in natural language: "scale the checkout service to handle the holiday traffic."
2. The orchestrator compiles the intent into a concrete plan — a sequence of typed tool calls with resolved arguments. The plan is a deterministic artifact: it can be hashed, serialized, diffed.
3. The system mints a short-lived token whose payload binds three things: the original prompt, the plan hash, and a scope clause that restricts the token to exactly the calls in the plan, with the resolved arguments.
4. Each downstream tool re-validates the call against the token. A call that wasn't in the plan fails closed, even if the bot's broader credentials would have permitted it.

The point is not the cryptography — the point is that authority becomes plan-shaped instead of role-shaped. A bot with full kubectl access plus an intent-bound token authorizing only scale deployment/checkout --replicas=N cannot pivot to delete namespace mid-execution, no matter how the plan evolves under prompt injection. The bot's baseline permissions are irrelevant during the lifespan of the token; the token has narrowed them to the resolved plan.

This is also where the IETF and NIST work on agent authentication has been heading. The draft-klrc-aiagent-auth track and the early Microsoft Entra Agent ID work both treat agent identity as something distinct from human or service identity, with the explicit goal of enabling per-task scoping. WorkOS's framing is the same in product terms: agents need authorization that anchors to the task session, not the long-lived agent identity.

Loading…