AI Agent Access Reviews: 3 Essential Security Checks

DEV Community

Add AI agents to your access review in three checks (owner, scope, stop and evidence)

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 lis...

Powered by Readybot.io