Cloud platforms / AI agent security deep dive · 2026-10-12

Cloud AI agents: least privilege must follow the plan

Cloud AI agents can inspect resources, propose changes, and invoke APIs. The dangerous design is not simply “an LLM with admin access”; it is a system where an untrusted plan can quietly inherit broad authority through tools, credentials, and retries. Give each action the narrowest authority possible, make mutations explicit, and keep the model outside the credential boundary.

Why ordinary least privilege is not enough

A user-facing agent often chains several operations: read a deployment, diagnose a quota issue, then change a setting. If the same long-lived role permits every step, a prompt injection hidden in logs or a mistaken plan can turn read access into a write. Tool schemas constrain syntax, not intent. An API that accepts a valid UpdateService request cannot know whether that update is justified.

Separate the control points:

Identity: workload identity or a broker issues short-lived credentials; never place cloud keys in prompts or tool output.
Capabilities: expose distinct read and write tools, scoped by resource, account, and environment.
Policy: enforce allowed operations at the server side, not merely in the model instructions.
Human gate: require confirmation for irreversible, costly, externally visible, or privilege-changing actions.
Evidence: record actor, requested operation, policy decision, approval, and result with a correlation ID.

Plan is not permission

Treat the model's proposed action as an untrusted request. A trusted executor should re-check authorization immediately before execution, using current policy and current resource state. This closes a time-of-check/time-of-use gap: the plan might have been generated before the target resource or approval changed. Bind approvals to a concrete action digest—resource, operation, and material parameters—not to a vague “approve this plan.”

request → validate schema → authorize target + verb
        → require approval if policy says so
        → mint short-lived scoped credential
        → execute once → record result

Reproducible lab: a dry-run gate

This local Python snippet illustrates a policy boundary; it does not call a cloud provider. The model can propose an operation, but the executor permits only reads unless a human explicitly approves a narrowly defined change.

ALLOWED_READS = {"GetService", "ListDeployments"}
APPROVABLE_WRITES = {"SetReplicaCount"}

def authorize(action, approved_digest=None):
    verb = action["verb"]
    if verb in ALLOWED_READS:
        return "execute-read"
    digest = f'{verb}:{action["resource"]}:{action["replicas"]}'
    if verb in APPROVABLE_WRITES and approved_digest == digest:
        return "execute-write"
    return "deny-or-request-approval"

change = {"verb": "SetReplicaCount", "resource": "staging/api", "replicas": 3}
print(authorize(change))                 # deny-or-request-approval
print(authorize(change, "SetReplicaCount:staging/api:3"))  # execute-write

Try changing the resource, verb, or replica count after constructing the approval digest. A production executor should reject the mismatch, validate bounds (for example, replica count maximum), and perform authorization against the actual cloud resource—not trust this toy string comparison.

Operational checks that catch real failures

Can the agent read production secrets or enumerate unrelated projects?
Can user-controlled logs, tickets, or web pages influence a write tool?
Does a retry reuse an already-consumed approval or repeat a non-idempotent operation?
Can you reconstruct the exact request and policy version from audit records?
Can you revoke the agent's credentials and halt queued actions quickly?

Takeaway

An agent's authority should be granted by a deterministic executor, one bounded operation at a time. Keep the model useful for reasoning, but make policy—not persuasive text—the thing that can authorize a cloud mutation.