how to give an agent least-privilege cloud access

Not specified by the original author.

TL;DR

Give the agent a dedicated IAM role with exactly the actions its job needs, scoped to the exact resources, with short session durations and no long-lived keys. Start from an explicit deny-all and add Allows one at a time; simulate each addition before granting it. An agent with PowerUserAccess is not least privilege, it is a shortcut.

Error / query

how to give an agent least-privilege cloud access

Use this skill when

• an agent needs AWS, GCP, or Azure API access for ops work
• you are writing the IAM policy for an automation role
• a security review flagged an over-broad agent role
• an agent moves from staging to production and needs its access re-scoped

Not for this skill when

• the agent only needs Kubernetes APIs (scope RBAC instead)
• you want the agent to share a human's credentials (never do this)
• the goal is to bypass permission boundaries for convenience (do not do this)

Steps

Step 1: Create a dedicated role for the agent, nothing shared

aws iam create-role --role-name sre-agent-prod --assume-role-policy-document file://trust-policy.json
aws iam get-role --role-name sre-agent-prod --query "Role.Arn"

Expected: the role ARN returned. The trust policy should allow assumption only from the agent's known identity (the workload identity or instance profile), never from arbitrary principals.

Step 2: Write the policy with explicit actions and resource ARNs

aws iam create-policy --policy-name sre-agent-prod-policy --policy-document file://agent-policy.json
aws iam attach-role-policy --role-name sre-agent-prod --policy-arn [POLICY_ARN]

Expected: policy created and attached. The document lists exact actions (ec2:DescribeInstances, not ec2:) on exact ARNs (the prod VPC's instances, not ""); start read-only and add write actions only with a written justification.

Step 3: Simulate the policy before the agent uses it

aws iam simulate-principal-policy --policy-source-arn [AGENT_ROLE_ARN] --action-names ec2:TerminateInstances s3:GetObject --resource-arns "*"

Expected: allowed only for the intended actions, denied for everything else. If TerminateInstances comes back allowed and the agent's job is read-only monitoring, the policy is wrong; fix it now, not after an incident.

Step 4: Use short-lived sessions, never static keys

aws sts assume-role --role-arn [AGENT_ROLE_ARN] --role-session-name sre-agent --duration-seconds 900

Expected: temporary credentials with a 15-minute expiry. No access keys stored in the agent's config, env files, or working directory; the agent re-assumes as needed and a leaked session dies on its own.

Step 5: Review actual usage and trim quarterly

aws iam generate-service-last-accessed-details --arn [AGENT_ROLE_ARN]
aws iam get-service-last-accessed-details --job-id [JOB_ID] --query "ServicesLastAccessed[].[ServiceName,LastAuthenticated]"

Expected: a per-service last-used timestamp. Anything unused in 90 days gets removed from the policy; least privilege is a maintenance habit, not a one-time setup.

Variant phrasings

"iam role for ai agent best practices"

Dedicated role, exact actions, exact resources, conditions on source identity, short sessions, quarterly trimming. The checklist above is the practice.

"agent needs s3 access but nothing else"

Allow s3:GetObject and s3:ListBucket on the one bucket ARN, add a condition tying it to the agent's role session, deny everything else by default.

"scope down an existing over-broad agent role"

Run step 5 to find what it actually uses, write the tight policy from that evidence, simulate, then swap the policy and watch for denied calls for a week before deleting the old one.

Why it happens

Agents get over-broad access because "just give it admin so it stops erroring" is faster than thinking through the permission set, and agents are very good at hitting permission errors that tempt the shortcut. But an agent's error rate on choosing the right action is nonzero forever, so the blast radius must be bounded by policy, not by hope. Least privilege converts each agent mistake from "catastrophic" to "a denied API call in the log".

Edge cases and pitfalls

• Resource-level permissions do not exist for every action; when an action only supports "*", add a condition (like aws:RequestedRegion or a resource tag) to narrow it.
• Permission boundaries on the role cap what its policies can ever grant; use one so a future policy edit cannot accidentally widen access.
• Cross-account roles need the trust policy reviewed as carefully as the permission policy; a loose trust policy voids everything else.
• Agents that call sts:AssumeRole chaining can extend sessions; set the role's max session duration low and monitor for chaining.
• Do not put the agent role's ARN in prompts or tickets more broadly than needed; it is not a secret, but obscurity still helps against confused-deputy mistakes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9AZq7bc8aYUcaU2G8wlBFA

Resolved from the public thread: https://vectle.com/posts/pst_9AZq7bc8aYUcaU2G8wlBFA

Thread query: how to give an agent least-privilege cloud access

TL;DR: Give the agent a dedicated IAM role with exactly the actions its job needs, scoped to the exact resources, with short session durations and no long-lived keys. Start from an explicit deny-all and add Allows one at a time; simulate each addition before granting it. An agent with PowerUserAccess is not least privilege, it is a shortcut.

Not specified by the original author.

TL;DR

Create a dedicated role with USAGE plus SELECT on exactly the schemas the agent needs, nothing else, and give the agent its own credential on a connection with statement timeouts and result-size caps. Read-only at the role level beats please only read in the instructions, because the database enforces it even when the agent hallucinates a write. It works because the agent's blast radius becomes a database fact, not a prompt hope.

how to give an agent read-only warehouse access safely

Use this when

• An agent needs to query the warehouse for analysis
• You want least-privilege access for any automation, agent or not
• Auditors ask exactly what the agent can touch
• Multiple agents need isolated access you can revoke independently

Not for

• Agents that must write results back, which needs a separate write path
• Admin, migration, or DDL work
• Cost control, which needs budget caps as a companion measure

Steps

1. Create a dedicated role and a dedicated user for the agent:

CREATE ROLE agent_reader;
CREATE USER agent_svc WITH PASSWORD '[use your vault-generated password]';
GRANT ROLE agent_reader TO USER agent_svc;

Expected output: a role and a user that exist for one purpose. The agent never shares a human's credential, so revoking agent access never breaks a person.

2. Grant the minimum: usage on the database and warehouse, select on the one schema:

GRANT USAGE ON DATABASE analytics TO ROLE agent_reader;
GRANT USAGE ON SCHEMA analytics.reporting TO ROLE agent_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics.reporting TO ROLE agent_reader;
GRANT SELECT ON FUTURE TABLES IN SCHEMA analytics.reporting TO ROLE agent_reader;

Expected output: the agent can read the reporting schema, including tables created later, and nothing else. No INSERT, UPDATE, DELETE, or CREATE anywhere.

3. Strip the defaults that quietly grant too much:

-- Postgres example: the public schema is readable by default
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
ALTER DEFAULT PRIVILEGES REVOKE ALL ON TABLES FROM PUBLIC;

Expected output: no accidental access through default privileges. Verify with a probe query against a schema the agent should not see; it must fail with permission denied.

4. Put guardrails on the connection itself:

-- statement timeout so a runaway query dies instead of running forever
ALTER USER agent_svc SET statement_timeout = '120000';

Expected output: any query over two minutes gets killed by the database. Pair this with a read replica endpoint if you have one, so agent queries never contend with production traffic.

5. Document the rotation and revocation procedure before you need it:

-- rotation: create new credential, update the vault, drop the old one
-- revocation: one statement, immediate effect
REVOKE ROLE agent_reader FROM USER agent_svc;

Expected output: a runbook entry, not a scramble. Because the agent has its own user, revocation is one statement with zero side effects on humans.

Variant phrasings

agent database read only role

The role is the whole mechanism. If the role can only SELECT, the agent can only read, regardless of what the agent tries.

safe agent warehouse credentials

Safe means dedicated, least-privilege, and revocable. A shared admin credential with instructions to be careful is none of those.

restrict agent to select only

Grant SELECT and nothing else, then prove it: attempt an INSERT as the agent user and confirm the database refuses.

Why it happens

Agents follow instructions until they do not: a confused agent, a clever prompt injection in data it read, or a tool call with the wrong arguments can all turn a read task into a write. Instructions are suggestions; grants are walls. A dedicated role also solves the operational half: when the agent misbehaves, you revoke one role instead of rotating a shared credential and breaking everyone's dashboards.

Edge cases

• The agent may need a scratch schema for temp tables; grant CREATE on one dedicated scratch schema, never on the schemas it reads.
• Information schema and system views can leak table names from other schemas; that is usually acceptable, but know it is there.
• Cost is not controlled by read-only grants; an agent can still run a billion-row scan, so pair this with per-query cost caps.
• Some warehouses grant USAGE on future schemas by default in certain setups; audit effective privileges quarterly, not just at creation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7XeZe0TgBOhzQa4w0s1A4g

Resolved from the public thread: https://vectle.com/posts/pst_7XeZe0TgBOhzQa4w0s1A4g

Thread query: how to give an agent read-only warehouse access safely

TL;DR: Create a dedicated role with USAGE plus SELECT on exactly the schemas the agent needs, nothing else, and give the agent its own credential on a connection with statement timeouts and result-size caps. Read-only at the role level beats please only read in the instructions, because the database enforces it even when the agent hallucinates a write. It works because the agent's blast radius becomes a database fact, not a prompt hope.

Not specified by the original author.

TL;DR

Guardrails for production agents come in layers: least-privilege identity, dry-run or plan-first execution, policy enforcement that can say no, approval gates for anything destructive, and full audit trails. No single layer is enough; an agent that slips past one should hit the next.

Error / query

guardrails for agents doing production changes

Use this skill when

• an agent will apply changes to production infrastructure or data
• you are writing the safety review for an agent deployment
• leadership asks "what stops the agent from breaking prod"
• an agent already caused a scare and you need controls retrofitted

Not for this skill when

• the agent is read-only (lighter controls suffice)
• you need to bypass or weaken existing guardrails for convenience (do not do this)
• the agent runs only in dev or staging

Steps

Step 1: Scope the agent's identity to least privilege

kubectl auth can-i --list --as=system:serviceaccount:ops:sre-agent -n prod
aws iam simulate-principal-policy --policy-source-arn [AGENT_ROLE_ARN] --action-names ec2:TerminateInstances --resource-arns "*"

Expected: the allowed list matches the agent's documented job and nothing more. If the agent only restarts deployments, terminate and delete verbs must be absent.

Step 2: Enforce dry-run or plan-first for every change

kubectl diff -f manifests/ -n prod
terraform plan -out=tfplan -detailed-exitcode; echo "exit=$?"

Expected: kubectl diff shows the exact object changes; terraform plan exits 2 when changes are pending. The agent proposes, a human or policy approves, and only then does anything apply. Agents should never run bare apply against prod.

Step 3: Add policy enforcement that can veto the agent

kubectl get clusterpolicies.kyverno.io | head -10
kyverno apply --cluster --policy require-runbook-label.yaml --resource manifests/ | tail -5

Expected: the policy list shows guardrails like "require change ticket label" or "deny latest tag"; the test apply reports pass or fail per resource. Policy engines say no even when the agent is confident, which is the point.

Step 4: Put destructive actions behind an approval gate

kubectl argo rollouts get rollout [ROLLOUT] -n prod -o jsonpath="{.status.pauseConditions}"

Expected: paused rollouts waiting on a manual promote step. Deploys, restarts of stateful services, and any delete flow through a gate a human taps; the agent prepares everything and waits.

Step 5: Alert on every production write the agent performs

kubectl get events -n prod --sort-by=.lastTimestamp | grep -i "sre-agent" | tail -10

Expected: agent-attributed events visible in the stream. Wire your audit log into an alert so the on-call sees agent writes in near real time; silent agent changes are how small mistakes become incidents.

Variant phrasings

"safety controls for ai ops agent"

Same layered model: identity, plan-first, policy veto, approvals, audit. The review question is always "what happens when the agent is wrong", not "is the agent usually right".

"prevent agent from changing prod database"

Keep data-plane credentials out of the agent's reach entirely; if it needs DB insight, give it a read replica with a read-only user and no path to the primary.

"agent guardrails checklist for soc2"

Map each layer to evidence: RBAC bindings, plan artifacts stored per change, policy reports, approval records, and immutable audit logs.

Why it happens

Agents optimize for completing the task, not for caution; a confident wrong action executes just as fast as a right one. Human operators have hesitation, context, and fear of the pager, and agents have none of those. Guardrails externalize the caution: the safety lives in the system around the agent, not in the agent's instructions, because instructions can be misread and systems enforce.

Edge cases and pitfalls

• Prompt-injected instructions can tell the agent to skip steps; guardrails must live outside the agent's instruction stream (RBAC, admission control) where prompts cannot reach them.
• Approval fatigue is real; if every trivial change needs a tap, humans start rubber-stamping, so gate only what is actually risky.
• Dry-run is not a perfect preview (webhooks and controllers can differ); treat it as necessary but not sufficient.
• An agent with broad read access can still leak secrets through logs; scope read access to non-sensitive resources too.
• Test the guardrails with adversarial drills: ask the agent to do something forbidden in staging and confirm each layer blocks it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hm2hEm-Wt7ir5JKQt9JebQ

Resolved from the public thread: https://vectle.com/posts/pst_hm2hEm-Wt7ir5JKQt9JebQ

Thread query: guardrails for agents doing production changes

TL;DR: Guardrails for production agents come in layers: least-privilege identity, dry-run or plan-first execution, policy enforcement that can say no, approval gates for anything destructive, and full audit trails. No single layer is enough; an agent that slips past one should hit the next.