Running a Security Review of an AI Agent’s Access

A security review of an AI agent’s access answers one question for every system the agent touches: what credential does it hold there, who issued it, what can it do, when was it last used, and when does it end? Run it once a quarter and after any change of people or tools. Collect the list from the systems that issued the credentials rather than from memory, write each grant into a register, decide keep, narrow, expire or revoke for each, check that the controls around the agents are still switched on, and file the follow-ups. For a small team it takes an afternoon.

How this differs from the monthly audit

The monthly audit looks at one tool in depth: what each assistant did on the board, whether its finished work holds up, whether its shared notes are still true. A security review is wider and shallower. It ignores quality and activity, and looks across every system for access: code hosting, model providers, MCP servers, cloud accounts, scheduled jobs. The one-page policy says what access should look like. The review checks whether it does.

Step 1: inventory from the issuing side

People forget what they connected. The systems that issued the credentials do not, so start there. Go through each system your agents work in and read its own list of tokens, apps and connections.

• Code hosting. On GitHub, organisation owners can view every fine-grained personal access token↗ (opens in a new tab) that can reach the organisation’s resources, with its owner, repositories and permissions. The same page warns that revoking those does not touch classic tokens, which keep working until they expire unless the organisation restricts them, so list those separately.
• Apps acting for a person. Each person checks the apps they have authorised to act on their behalf. GitHub lists them under Authorized GitHub Apps↗ (opens in a new tab) in account settings, and notes that revoking a person’s authorisation is separate from uninstalling the app from an organisation.
• Each developer’s machine. MCP servers can be configured in several places at once. In Claude Code, claude mcp list shows them, and the MCP documentation↗ (opens in a new tab) sets out the local, project and user scopes, where local and user servers live in ~/.claude.json and project servers in a committed .mcp.json.
• Model provider keys, cloud credentials and service accounts used by scheduled agents. These are often created once, by one person, for a job that has since changed.
• Every tool an agent writes to, such as a task board, a help desk or a document store. Each should list its own tokens and connections.

claude mcp list      # every MCP server this machine will load
claude mcp get <name>  # details for one of them

Step 2: one row per grant

Write each credential into a register with the same fields every quarter, so quarters can be compared. A shared spreadsheet or a task on the board is enough. The fields that matter are the ones that let you make a decision without asking anybody.

System        GitHub org / board / cloud / model provider
Agent         what it is: Claude Code, Copilot cloud agent, triage script
Credential    sign-in, hand-issued token, app, service account
Issued by     the person who created it
Owner now     the person who answers for it today
Can do        scopes, and the role it is capped by
Reaches       repositories, boards, buckets, inboxes
Last used     date, or never
Expires       date, or never
Decision      keep / narrow / set expiry / rotate / revoke

Two fields catch most problems. “Issued by” and “Owner now” differ whenever someone has left or changed role, and a credential whose issuer has gone is one nobody is watching. “Expires: never” marks a credential that will outlive the reason it was created.

Step 3: judge each grant against its job

For each row, ask three questions. Does this agent read content that people outside the team can write, such as issues, emails or web pages? Can this credential reach data that would matter if it leaked? Can it write, publish or send anywhere outside? A grant that answers yes to all three is where prompt injection does real damage, and it should lose one of the three before anything else on the list is touched.

Then look for access that has outlived its purpose. OWASP’s entry on Excessive Agency↗ (opens in a new tab) describes exactly this pattern: an extension trialled during development, replaced by a better one, and never removed, so it stays available to the agent. Its first mitigations are to minimise the extensions an agent has and the permissions each one holds.

Step 4: decide, using standing rules

Decisions go faster when the rules are written before the review starts. These cover most rows.

• Never used, or not used for 30 days: revoke. Reconnecting takes a minute.
• Issuer has left or changed role: revoke, and let the new owner connect afresh under their own name.
• No expiry on a hand-issued token: reissue it with one. Sign-ins that renew themselves are fine; a key that lasts for ever is not.
• Scopes wider than the work in the activity record: narrow them, usually by issuing a smaller credential and revoking the old one.
• Shared by two people or two tools: split it, so each can be revoked alone.
• Stored somewhere it could have been copied, such as a committed file or a chat: rotate it.

Where a system can enforce the rule for you, let it. GitHub, for example, lets organisation owners set a maximum lifetime↗ (opens in a new tab) for personal access tokens and require an owner to approve each fine-grained token before it can reach the organisation.

Step 5: check the controls are still on

Access is half the review. The other half is whether the guard rails you set up last quarter have quietly been loosened. Settings drift for good reasons, such as a sandbox turned off to get a build working, and are rarely turned back.

• Coding agents: sandbox still enabled, prompt-skipping modes still disabled, deny rules for secret files still present. The settings behind each are in security controls for AI coding agents.
• Project MCP files: read the history of .mcp.json since the last review. A new server there reached everyone who pulled.
• Branch rules: pull requests still required on the main branch, and nobody added to the bypass list for convenience.
• Network allowlists: no broad domain added “temporarily”.

Step 6: record it and follow up

Act on the easy decisions during the review itself: revoking takes seconds and waiting only adds exposure. Anything bigger becomes a task with an owner. Keep the register, dated, next to last quarter’s. When something does go wrong, the first question will be who had access to what, and the review is where that answer lives. If something in the review looks like misuse rather than housekeeping, stop and follow an incident checklist instead.

What the fenbs side of the review looks like

On a fenbs board, most of the register for the board itself is already on screen. Settings, “Connect an AI assistant”, lists every token by name with its scopes (read, write, comment), when it was last used or “never used”, and when it expires or expired. Revoked tokens stay on the list, struck through with the date, so the review also shows what used to have access. A sign-in from an assistant appears there with a name such as “Claude Code via sign-in” and its date; it holds an access token that lasts an hour and renews with a refresh token, and revoking the entry ends both. Hand-issued tokens can be given an expiry of 7, 30, 90 or 365 days, or none.

The Your connections page shows each person what is connected to their account now, and every board an assistant acting as them could reach, with their role on each. Roles are defined per company, and a person’s company role is the ceiling for every board, so narrowing a company role during the review narrows every token that person issued at once. History records every change as “Claude via” the person it acted for, which is what you read when a row’s “can do” and its actual use disagree.