Add AI agents to your access review in three checks

Treat each AI agent like an entitlement in your next access review, and ask three questions of it. Who owns it? What can it reach? How do you stop it, and what evidence shows that you can?

A thread on r/grc asked the question that started this. u/TheAccountableAgent asked whether access reviews include AI agent permissions. They noted that coding agents now store "always allow" rules locally, and that Apiiro had reported 1,379 secrets in public copies of one tool's settings file. Their approach: treat each saved agent permission like an IAM entitlement with an owner, a business reason, the data it reaches and a review date. They asked how others evidence this for auditors.

My answer builds on an argument I made in Agents don't go rogue. Scopes do. Scope is what an agent can technically do whatever its instructions say: the identities it holds, the tools it can call, the hosts it can reach and the actions it can take without a human. The people who deploy an agent set its scope. "Out of scope and nothing stopped it" is a finding, and a finding can be owned, fixed and audited.

Check 1: Who owns the agent?

The AI Security Wiki's Agentic AI Security and Tool Governance standard says no agent should be approved until its owner, identity, tools, APIs, data boundary, approval workflow, logging, kill switch and SOC integration are defined.

The r/grc replies add the practical detail:

• Split the owner in two. LogicManager suggested separating the technical maintainer from the business owner. The maintainer explains how the permission is configured. The business owner explains why the agent needs it. The person who configured the permission shouldn't become its business owner by default.
• Expect orphans. Ok_Statistician_997 said the owner field trips people up. A dev sets the permission, changes teams and nobody updates it. Tying the review date to the service account's own access cycle helped them stop it drifting.
• Make a move trigger a review. LogicManager again: a developer changing teams should trigger a review, not an assumption that the permission is still appropriate.
• Decide your source of truth first. AlwaysAnotherShot pointed out that many of these permissions live in a settings file on a developer's laptop. If endpoint tooling can collect the config files, sample from that like any entitlement list. If not, you rely on developers self-declaring, and the control description should say so plainly.

Check 2: What can it reach?

This is the scope inventory. One row per agent. Here is a sketch built from the fields the thread and the wiki name. The field names are mine.

agent: support-triage-bot purpose: "Summarise and label inbound tickets" business_owner: technical_maintainer: identity: own workload identity # not a person's login, not a shared key tools: [ticket.read, ticket.label] hosts_reachable: [tickets.internal.example] data_scope: "Ticket text only" secrets_in_agent_environment: none can_modify_credentials: false actions_without_human: [label] approval_required_for: [delete, send, change-permissions] last_reattested: 2026-11-01 next_review: 

Fields to include, all from the sources:

• Owner, purpose, data scope, connected tools, secrets, approval boundaries, and whether the agent can create or modify other credentials (macromind on r/grc).
• Effective permissions and recent use at each review. Flag dormant grants and broad wildcard access (macromind).
• Wildcard "always allow" rules on shell commands, or anything that can read .env files: treat as a finding by default, with a written exception and an expiry date (AlwaysAnotherShot).

Then check the inventory against how the agent is actually wired. The r/AskNetsec thread on beginner mistakes securing agent credentials gives a quick list of what to look for:

• A shared admin key "for testing", tokens kept overnight, and tool calls logged without the human, task and scope behind each request. That is the original poster's own list.
• A single token with both read and write scope because it was quicker, so an agent that only needed to look things up can also delete (Secvura).
• An agent running on its own broad service account rather than on-behalf-of the user. Economy_Dust_9606 calls this the confused deputy problem: prompts can then bypass the user's permissions.
• Secrets where the model can see them. Secvura recommends keeping them in the tool layer so the agent calls a tool by name and the tool attaches the credential.

Also test chains. macromind notes the hard part is chained actions, since a low-privilege agent may gain material reach through an authorised integration.

Check 3: How do you stop it, and what is the evidence?

The stop. The Builder Track maps two controls to OWASP's ASI10 Rogue Agents entry: a named owner, and a blast-radius cap with a kill switch. "Exists" is a runbook. "Operated" is a dated test and a revocation propagation table. The wiki's TC-D09-016 test case disables an agent and measures how long each system keeps accepting its tokens. EbbCommon9300 describes a design where revoking an agent means denying it at a broker, instead of hunting down every token it touched.

The record. If the compromised agent wrote the entry, the entry isn't evidence. The fix, step B10 in the Builder Track, is an independent writer: the policy gateway logs every decision, denials included, each entry carries the hash of the one before, and the latest hash sits where the agent cannot write. EbbCommon9300 makes the same point on r/AskNetsec: write the log at the broker (agent identity, session, tool, arguments, allow or deny, who approved) and make it append-only or hash-chained, so the thing being audited can't edit its own record.

What the reviewer should ask for, per agent:

Source for the table: the wiki's AI Security Audit and Evidence Checklist, as I summarised it in the LinkedIn article. Only the "operated" column supports an opinion that the controls worked.

For the thread's evidence question, AlwaysAnotherShot's answer is a good minimum: a dated export of the configs, the reviewer's sign-off per agent, and tickets for anything revoked.

Do this first

1. Pick the population source for agents: endpoint config collection, or developer self-declaration stated plainly.
2. Add the inventory fields above, with a business owner and a technical maintainer.
3. Add a re-attestation date and an automatic restriction for agents whose owner doesn't respond.
4. Move the audit log to a writer the agent cannot reach, and chain the entries.
5. Run one kill-switch test, date it, and record how long tokens kept working.

What does your review use today as the source of truth for agent permissions?

The AI Security Wiki is co-authored with Nachiket Sathaye and published under CC BY-SA 4.0. OWASP is a trademark of the OWASP Foundation.

aisecurity #grc #devsecops #agents