Least Privilege for AI Agents, Securing kubectl, Terraform, and Cloud CLIs

On April 25, 2026, an AI coding agent deleted the entire production database of PocketOS, along with every volume backup, in nine seconds. Nobody attacked it. There was no prompt injection, no malicious code, no compromise of any kind. The agent hit a credential mismatch while working in staging, decided on its own that deleting a volume would fix the problem, scanned the codebase for a token, and found one that had been created months earlier for managing custom domains. That token carried blanket authority across the entire provider API, including volume deletion. The agent was not the vulnerability. The credential was.

The credential is the boundary

Read the PocketOS timeline again, because every control in this article follows from it. The agent was performing a routine task. It encountered an obstacle. It reasoned its way to a solution that happened to be catastrophic, went looking for the means to execute it, and found them lying in the repository. Its reasoning was internally coherent the entire time. Nothing in the architecture said no.

That is the uncomfortable part. Most teams are still defending against a hijacked agent, and that threat is real, but PocketOS shows you do not need one. A perfectly healthy agent pursuing a legitimate goal will occasionally take a destructive path, and when it does, the only thing standing between it and your data is what its credential permits. The vendor's own guardrails, marketed as destructive action protection and a restricted planning mode, did not stop it. A December 2025 bug in the same product let an agent delete tracked files and kill processes while the user was explicitly telling it to run nothing at all.

The lesson generalizes past any one tool. A system prompt is a request. A permission is a decision. Instructions live inside the model's reasoning loop, which means the model can reason its way around them when a goal seems to demand it. IAM policy lives outside that loop, in code the model cannot influence, and it fails closed. When you write "never delete production data" into a system prompt, you have expressed a preference. When you remove the delete permission from the agent's role, you have built a control.

This is also the shape of the industry's answer. The Coalition for Secure AI published its agentic identity and access management guidance in March 2026, and its opening imperatives are to give agents their own first class identity rather than forcing them into a human or service account mold, and to abolish standing privilege outright, with authorization decided by a governance layer sitting outside the agent's reasoning. NIST launched an AI Agent Standards Initiative in February 2026 asking whether OAuth, SPIFFE, and OpenID Connect are even sufficient for this. Meanwhile, Sonrai Security puts the share of overprivileged cloud identities at 92%, and only 44% of organizations have implemented any policy at all for managing their agents.

The three planes you have to get right

Agent access control decomposes cleanly into three questions, and confusing them is why most implementations leak.

Layered on top of all three sits an approval gate for anything irreversible, and the gate must live in code the agent cannot rewrite. If your approval logic is a sentence in the system prompt, you do not have a gate, you have a suggestion.

Pattern one, tool granularity is a permission boundary

Before you touch IAM, look at your tool definitions, because this is where most teams accidentally hand over the keys.

Consider two MCP tools that both let an agent restart a workload:

# DANGEROUS: the tool inherits every permission in the kubeconfig.
@mcp.tool()
def run_kubectl(command: str) -> str:
    """Run any kubectl command."""
    return subprocess.run(f"kubectl {command}", shell=True,
                          capture_output=True, text=True).stdout

# SAFE: the tool can express exactly one intent, and nothing else.
@mcp.tool()
def restart_deployment(name: str, namespace: str) -> str:
    """Restart a single deployment by name. Cannot delete or scale."""
    if namespace not in ALLOWED_NAMESPACES:
        return f"Refused: namespace {namespace} is not permitted."
    out = subprocess.run(
        ["kubectl", "rollout", "restart", "deployment", name, "-n", namespace],
        capture_output=True, text=True, timeout=30,
    )
    return out.stdout or out.stderr

The first tool is a shell. Whatever the kubeconfig can do, the model can now do, and the tool description does nothing to constrain it. The second tool has an API surface of exactly one verb against one resource type, with the namespace checked in code rather than in prose. Even a fully hijacked model calling restart_deployment cannot delete a namespace, because the capability was never exposed.

That rule follows directly. Never expose a tool that takes a free form command, a raw query, or an arbitrary API path. Every parameter your tool accepts should be a value, not an instruction. If you find yourself writing a tool called execute, run, or query, stop and enumerate the three or four things the agent actually needs to do.

Least privilege for kubectl

Start from the assumption that your agent gets its own ServiceAccount, never a human's kubeconfig and never cluster-admin. A read only agent is the default, and it covers most triage work.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: triage-agent
  namespace: sre
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: agent-readonly
rules:
  - apiGroups: ["", "apps", "batch"]
    resources: ["pods", "deployments", "replicasets", "jobs", "events", "nodes"]
    verbs: ["get", "list", "watch"]          # observation only
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get", "list"]
# Deliberately absent: secrets, pods/exec, pods/portforward,
# and every mutating verb. Absence is the control.

The comment at the bottom matters more than the rules above it. Kubernetes RBAC is purely additive, so security comes from what you never grant. A handful of permissions look innocuous in a manifest and are effectively administrative in practice.

Grant write access only through a second, separate identity, and keep it painfully narrow. An agent that remediates should hold one role that permits the specific mutation you intend and nothing adjacent to it.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role                      # namespaced, not cluster wide
metadata:
  name: agent-restart-only
  namespace: web
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    resourceNames: ["checkout-api", "web-frontend"]   # named resources only
    verbs: ["get", "patch"]     # patch enables rollout restart
  # No "delete". No "create". No wildcard on resourceNames.

Then verify it from the outside, because a manifest is a claim and can-i is evidence:

SA=system:serviceaccount:sre:triage-agent

# What can this identity actually do? Read the whole list.
kubectl auth can-i --list --as="$SA"

# Assert the dangerous things are denied. These must all print "no".
kubectl auth can-i delete pods            --as="$SA" -A
kubectl auth can-i get secrets            --as="$SA" -A
kubectl auth can-i create pods/exec       --as="$SA" -A

Put those assertions in CI. A pull request that widens an agent's role should fail the build the same way a broken test does, and negative tests are the only ones that catch privilege creep.

For a backstop, add admission control. A ValidatingAdmissionPolicy, Kyverno, or Gatekeeper rule that rejects deletes on resources labeled as protected will hold even if someone fat fingers an RBAC binding, and it gives you defense in depth at the API server rather than at the identity.

Least privilege for Terraform

Terraform has a built in privilege boundary that most teams never use, and it is the strongest control available to you here: the plan and apply split.

An agent that proposes infrastructure changes does not need permission to make them. Give it read only cloud credentials, let it run terraform plan, and let it write the plan to a file. A human reviews the plan and CI applies it under a completely different identity.

# AGENT context: read only credentials, no apply role, no state write.
terraform plan -out=tfplan -lock=false
terraform show -json tfplan > plan.json     # machine readable, reviewable

# POLICY GATE: fail the build before a human ever looks at it.
conftest test plan.json --policy policy/    # OPA rules
# Example rules: deny destroy of tagged prod resources,
# deny any change to IAM, KMS, or the state bucket.

# CI context: a separate identity, after human approval.
terraform apply tfplan       # applies the reviewed plan, nothing else

Two details make this work. Applying a saved plan file means the agent cannot alter what runs between review and execution, so what a human approved is exactly what executes. Converting the plan to JSON gives you a structured artifact you can run policy against, which turns "does this look right" into a test that either passes or fails.

Three Terraform specific traps are worth calling out.

State is a secret store. Terraform state contains resource attributes in plain text, and that routinely includes database passwords, private keys, and connection strings. Read access to your state backend is credential theft with extra steps. An agent should never hold write access to the state bucket, and in most designs it should not hold read access either.

Destroy is not the only destructive operation. A change that forces resource replacement will delete and recreate, which for a database or a volume is indistinguishable from a deletion. Mark anything you cannot lose with a prevent_destroy lifecycle block, and make your policy gate reject plans that replace protected resources rather than only rejecting explicit destroys.

The provider credential is the real permission set. Terraform enforces nothing. If the cloud role behind it can delete a bucket, then the plan and apply split is your only protection, so the read only credential you hand the agent has to actually be read only. Verify it against the cloud provider, not against your intent.

Least privilege for cloud CLIs

The PocketOS token was a standing credential with blanket authority, sitting in a file. Everything below exists to make that impossible.

Stop issuing long lived keys. An agent should authenticate through workload identity federation and receive a short lived token, minted per session and expiring in minutes. The mechanism differs by cloud but the shape is identical.

Most teams miss the middle column. On AWS, a session policy is an inline policy you pass at the moment you assume a role, and the resulting credential holds only the intersection of the role's permissions and the session policy. That is exactly the primitive an agent needs, because it lets you mint a credential scoped to the one task in front of you rather than to everything the agent might ever do.

# Downscope at assume time. The session can only touch what this task needs,
# even though the underlying role is broader.
cat > session.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::app-logs-prod", "arn:aws:s3:::app-logs-prod/*"] },
    { "Effect": "Deny",
      "Action": ["iam:*", "kms:ScheduleKeyDeletion", "s3:DeleteObject",
                 "rds:DeleteDBInstance", "ec2:TerminateInstances"],
      "Resource": "*" }
  ]
}
JSON

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/agent-investigator \
  --role-session-name "agent-incident-4417" \
  --duration-seconds 900 \
  --policy file://session.json          # 15 minute credential, task scoped

Note the explicit Deny block. An explicit deny in AWS cannot be overridden by any allow, anywhere, which makes it the right place for the operations you never want an agent performing under any circumstances. Deny the identity operations first, because iam:CreateAccessKey, iam:PutUserPolicy, and iam:AttachRolePolicy are how a constrained agent stops being constrained.

Behind that, set a permission boundary on the agent's role so it cannot exceed a ceiling even if someone attaches a broader policy later, and put a service control policy at the organization level as the wall that no role in the account can cross.

Contain the execution environment

Identity and authorization decide what an agent may do. The sandbox decides what it can reach when those fail.

Run the agent in an ephemeral container that is thrown away after the task. Deny all network egress by default and allowlist only the endpoints it genuinely needs. Then block the one thing people forget:

# An agent that can reach the metadata endpoint can steal the node's role,
# which quietly undoes every IAM control above it.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-egress
  namespace: sre
spec:
  podSelector:
    matchLabels: { app: triage-agent }
  policyTypes: ["Egress"]
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32     # cloud instance metadata service
              - 169.254.170.2/32       # ECS task metadata

Pair that with a hardened pod: runAsNonRoot, a read only root filesystem, all Linux capabilities dropped, and no host path mounts. An agent with a writable filesystem and a host mount is one instruction away from persistence.

Finally, take the PocketOS lesson seriously. Your backups must sit outside the credential chain that can reach production. The same token that dropped that database also removed every snapshot, because the snapshots lived in the same blast radius. A backup that an agent's credential can delete is not a backup but a copy.

Prove it, then watch it

A control you have not tested is a control you are guessing about, and a takeaway from the Identiverse conference this year was that most of the market still confuses visibility with enforcement. Knowing which agents exist is not the same as governing what they can reach.

Verification comes first, and the useful form of it is negative. Do not assert that the agent can restart a deployment, assert that it cannot delete one. Positive tests confirm your feature works, while negative tests confirm your boundary holds, and only the second kind catches privilege creep six months from now when someone widens a role to unblock a demo.

# Runs in CI. A pull request that widens agent permissions fails the build.
import subprocess

SA = "system:serviceaccount:sre:triage-agent"
FORBIDDEN = [
    ("delete", "pods"), ("delete", "deployments"), ("get", "secrets"),
    ("create", "pods/exec"), ("impersonate", "users"), ("escalate", "roles"),
]

def can_i(verb, resource):
    r = subprocess.run(
        ["kubectl", "auth", "can-i", verb, resource, "--as", SA, "-A"],
        capture_output=True, text=True)
    return r.stdout.strip() == "yes"

def test_agent_cannot_do_dangerous_things():
    granted = [f"{v} {r}" for v, r in FORBIDDEN if can_i(v, r)]
    assert not granted, f"Agent has forbidden permissions: {granted}"

Do the same on the cloud side with your provider's policy simulator or access analyzer, because a role that looks read only in a template and a role that is read only in effect are different claims. Resolve the second one against the provider.

Then instrument what actually happens. Log every tool call with three fields that most implementations omit: the arguments the agent passed, the provenance of the content that triggered the call, and the decision your router made. Provenance is what lets you distinguish an action a human asked for from an action that originated in a pull request comment, and those two things should never carry the same authority.

Alert on the signals that mean a boundary is being probed. An agent calling a tool it has never called before deserves attention. So does an outbound connection to a host outside your allowlist, a tool call that cannot be traced back to any human turn, an agent reading its own configuration, and any use of a credential outside its expected time window. Kubernetes audit logs give you most of this for free once agent identities are distinct, which is one more reason never to let an agent borrow a human's kubeconfig.

A maturity ladder you can actually walk

Most teams are somewhere on the first two rungs. Be honest about which one, then move up by one.

Level 2 is the honest minimum for anything touching production. Level 3 is achievable today with session policies and workload identity, and it is where the PocketOS incident becomes structurally impossible rather than merely unlikely.

Conclusion

The agent that destroyed PocketOS was not hacked, jailbroken, or poisoned. It was trusted, and trust is not a control. Everything that mattered in that incident happened at the identity layer: a token with no scope isolation, sitting in a file, reachable by a process that had no business holding it, with backups inside the same blast radius. No amount of prompt engineering would have changed the outcome, because the model was never the enforcement point.

Fix this the way you fixed it for humans, and then go one step further, because agents act at machine speed and will not pause to reconsider. Give every agent its own identity. Scope its tools to intents rather than to shells. Split plan from apply. Mint credentials that expire in minutes and deny the operations you can never take back. Put the backups where the agent's credential cannot follow.

Start this week by running kubectl auth can-i --list as each of your agent service accounts, and by grepping your repositories for the standing tokens that are already sitting there. You will almost certainly find at least one credential that could delete something you cannot get back. That is the one to fix first.