least-privilege tool grants for agents

Not specified by the original author.

least-privilege tool grants for agents

TL;DR

Give each agent the smallest tool set that completes its task, for the shortest time it needs it, and nothing else. Write the grants down as a matrix, default to deny, expire them automatically, and re-certify on a schedule. Permission creep in agents looks exactly like permission creep in humans, except the agent never complains about missing access until it silently works around it.

least-privilege tool grants for agents

Use this when

• You are granting an agent access to tools, APIs, or data
• A new capability is being added to an existing agent
• An audit asks who (or what) can do which actions
• An agent's task changes and its old grants no longer fit
• You are designing the permission model for an agent platform

Not for this skill when

• The question is about human user roles and RBAC
• You are configuring OS or container-level isolation (see sandboxing skill)
• The agent calls no tools at all
• You need a formal access certification for compliance auditors

Steps

1. Write the grant matrix before granting anything

For each agent and task, list the exact tools, the actions allowed on each, and the data scope. "Read access to the tickets API for queue Q" beats "API access".

cat [HOME]/...

Expected: the file exists, names agents, tools, actions, and scopes, and has an owner and review date. Grants that live only in someone's head do not exist.

2. Default deny, then add narrowly

Start from zero permissions and add only what the task demonstrably needs. "It might need write later" is not a grant; it is a future request to file later.

Expected: a new agent deployment starts with no tools and gains them one reviewed grant at a time. The review trail shows each addition with its justification.

3. Separate read, write, and destructive actions

Read, create, update, and delete are different grants. An agent that summarizes tickets needs read; the one that closes them needs the close action explicitly, scoped to the right queue.

Expected: the matrix distinguishes action classes per tool, and a read-only agent demonstrably cannot perform writes in testing.

4. Time-box grants to the task lifetime

Permissions should expire when the task ends: per-run grants for one-shot jobs, short leases for ongoing work. Permanent grants are the ones nobody remembers approving.

Expected: grants carry expiry, and an expired grant fails closed in testing. The renewal process is lightweight enough that people use it instead of asking for permanent.

5. Re-certify on a schedule

Review the matrix quarterly or on every incident: does each agent still need each grant, is the scope still right, did the task change. Remove what is unused without ceremony.

grep -c "grant" [HOME]/...

Expected: the count trends down or stays flat over time, never silently up. Each review is logged with what changed and why.

6. Test the boundaries, not just the happy path

For each agent, attempt the adjacent forbidden action in a dry run: the read-only agent tries a write, the scoped agent tries outside its scope. The denials are the proof the matrix is real.

Expected: boundary tests exist and pass, and they run in CI so a config change cannot silently widen access.

Variant: agents with tiered capabilities

Some agents need broad read plus narrow write. Model that as two grant sets with different expiry and approval paths rather than one mushy "power user" grant that nobody understands.

Variant: break-glass access

For incidents, allow temporary elevation with a ticket reference, a short TTL, full logging, and automatic revocation. Break-glass that nobody can find during the incident will be bypassed; break-glass without logging will be abused.

Variant: third-party agent platforms

When the platform controls the tool surface, your grants are the platform's permission settings plus your own policy layer. Audit both, because the platform default is usually broader than you think.

Why this happens

Granting feels productive and restricting feels like friction, so every agent accumulates permissions "just in case" until its access resembles an admin's. Unlike humans, agents do not get phished for credentials they do not have, which means every unnecessary grant is pure risk with no upside. Least privilege is the only control that shrinks the blast radius before anything goes wrong.

Edge cases and pitfalls

• Agents that hit denials sometimes reframe the request to dodge the policy ("summarize" becomes "summarize and file"); monitor for grant-shaped workarounds.
• Scope creep via broad reads: a read grant on "tickets" quietly becomes PII access when tickets contain PII; scope to fields, not just endpoints, where it matters.
• Shared service accounts blur which agent did what; prefer per-agent identities so the audit trail names names.
• Emergency grants issued verbally never get revoked; require them in the matrix within 24 hours or they auto-expire.
• Overly tight grants push users to shadow agents with no controls at all; keep the request process fast.

Provenance

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

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

Thread query: least-privilege tool grants for agents

TL;DR: Give each agent the smallest tool set that completes its task, for the shortest time it needs it, and nothing else. Write the grants down as a matrix, default to deny, expire them automatically, and re-certify on a schedule. Permission creep in agents looks exactly like permission creep in humans, except the agent never complains about missing access until it silently works around it.

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.