How to Audit AI Agent Permissions Before Deployment

How to Audit AI Agent Permissions Before Deployment

To audit AI agent permissions, start with the actions the deployed system can actually perform, not the friendly names in its connector catalog. List every tool, credential, account, data boundary, and downstream effect. Separate read, write, send, execute, and administrative actions; reduce each credential to the smallest working scope; bind approvals to the exact target and payload; then test prompt injection, confused-deputy behavior, and revocation. The OWASP Top 10 for LLM Applications provides the threat context: connected models can turn untrusted instructions or excessive agency into real system effects. A deployable audit ends with evidence, owners, expiry dates, and rollout gates.

Key Takeaways

• Audit concrete tools, accounts, scopes, and effects rather than connector labels.
• Treat read access as consequential when it exposes sensitive or cross-tenant data.
• Use separate credentials for environments, agents, and materially different jobs.
• Bind approval to the exact action, target, payload, identity, and current state.
• Prove denial, expiry, rotation, and revocation before connecting production data.

What belongs in an AI agent capability register?

A capability register is the source of truth for what an agent can attempt and what can happen if the attempt succeeds. One row should represent one distinct effect. “Google Workspace” is too broad. “Read Drive files shared with the support service account” and “Send email as support@company.com” are different rows with different consequences.

Use fields such as:

Record indirect effects. A “write file” tool might write into a watched deployment directory. A database read can include secrets or another customer’s records. A calendar invite can email external recipients. A shell command can reach every permission held by its host process. The visible tool name does not define the security boundary.

The NIST AI Risk Management Framework organizes risk work around governing, mapping, measuring, and managing. The register supports that loop: it maps capabilities, attaches tests, names decisions, and makes later monitoring and review possible.

Step 1: Inventory tools, connectors, accounts, and data

In my workflow for agent permission reviews, I start from runtime evidence because connector names routinely hide several identities and effects.

Start from runtime evidence. Export the registered tool schemas, connector configuration, OAuth grants, service accounts, environment variables, network policies, file mounts, database roles, and command allowlists. Compare this inventory with product documentation, but treat the deployed runtime as authoritative.

For each operation, run a harmless test in a non-production environment and capture:

1. The exact request and tool arguments.
2. The identity presented downstream.
3. The resources returned or changed.
4. The audit log produced by the target system.
5. The model-visible response.
6. Any retry, redirect, or chained call.

Include built-in tools that teams often overlook: browsing, URL fetching, code execution, file conversion, email drafting, scheduled runs, memory, and retrieval. Include administrator surfaces that provision new connectors or change the agent’s own instructions. An agent that cannot send email today may gain that ability when a workspace administrator enables a package tomorrow.

Create a separate row for each environment and identity. A development token and production token are not interchangeable evidence. If a connector acts with each end user’s delegated identity, sample roles with different access levels and confirm that downstream authorization still applies.

Step 2: Classify every downstream effect

Assign an effect class based on outcome:

• Read: retrieves content, metadata, secrets, or state.
• Write: creates or changes internal data or files.
• Send: communicates or publishes to another person or audience.
• Execute: runs code, queries, workflows, or infrastructure actions.
• Admin: changes identities, permissions, policy, billing, or configuration.

Add sensitivity and reversibility. Reading a public webpage is not equivalent to reading payroll files. Creating a draft is not equivalent to publishing it. Updating a reversible label differs from deleting an account. Use these distinctions to decide whether the action is allowed automatically, allowed only in a bounded sandbox, requires approval, or is prohibited.

Do not assign “read-only” a default low-risk status. Read access can leak regulated data into a prompt, expose secrets through retrieval, or give an attacker reconnaissance. Test whether results cross tenant, project, folder, channel, or row boundaries. Confirm whether retrieved content is sent to a model provider and whether retention settings match policy.

Step 3: Reduce credentials to least privilege

Create the smallest credential that completes the approved job. Prefer a dedicated identity with narrow resources over an employee’s broad personal account. Separate production from development, ingestion from publishing, and read from write when the provider permits it.

For OAuth connectors, record requested scopes, granted scopes, token audience, redirect URI, refresh behavior, and revocation path. The OAuth 2.0 Security Best Current Practice documents current protections against token and authorization-flow attacks. The MCP authorization specification likewise defines an OAuth-based model for protected MCP resources. Protocol compliance is a starting point; the resource server must still enforce the right audience, subject, scope, and resource boundaries.

Challenge every broad grant:

• Can a folder, project, repository, channel, table, or host be selected?
• Can a read-only role replace a general role?
• Can send and publish stay disabled until a later rollout?
• Can the credential expire automatically?
• Can the service reject calls outside the agent’s intended task?

Reject a connector when the only available grant is materially broader than the job and compensating controls do not reduce the consequence. Documentation that says “secure” is not evidence that a token cannot reach unrelated data.

Which agent actions should require approval?

Require per-action approval for external communication, irreversible changes, financial or legal commitments, production execution, permission changes, sensitive exports, and any operation whose target or payload came from untrusted content. Lower-risk writes may use policy-based approval only when target, range, and effect are tightly constrained and observable.

An approval preview should show the exact operation, account, target, recipients, payload or diff, affected resource count, and material side effects. The approval must be invalidated if any of those values change. “Allow email?” is not sufficient when the agent can change recipient or body after the click.

Test three bindings:

1. Identity binding: approval applies only to the current user and credential.
2. Intent binding: approval applies only to the displayed operation and arguments.
3. Time and state binding: approval expires and cannot be replayed after relevant state changes.

Separate creation from execution. Let an agent draft a command, message, migration, or plan without granting authority to run or send it. For scheduled agents, unresolved approvals should wait in a review queue rather than being converted into implicit consent.

Step 4: Test prompt injection and confused-deputy paths

Build adversarial fixtures before production. Put instructions in retrieved documents, webpages, issue comments, email bodies, tool results, and filenames. Ask them to reveal secrets, call another tool, change recipients, upload data, or disable safeguards. The expected result is not merely a refusal in prose; verify that no prohibited tool call or data transfer occurred.

Test a confused-deputy scenario: a low-privilege requester asks the agent to use a higher-privilege connector on their behalf. Confirm that the system checks the requesting user’s authority, not only the connector token’s capability. Then test cross-tenant identifiers, stale object references, redirects, encoded arguments, long payloads, and chained tools.

Run independent passes:

• A policy reviewer maps expected allow and deny outcomes.
• An adversarial tester attempts to bypass the boundaries.
• A log reviewer confirms actual calls, identities, targets, and denials.

In ZeroTwo, keep connector documentation, threat scenarios, test outputs, and independent review drafts in one project. Comparing two model analyses can expose missed effects, but downstream logs and deterministic authorization checks remain the evidence.

Step 5: Prove denial, expiry, rotation, and revocation

Happy-path success proves very little about permission control. Attempt an out-of-scope resource, unauthorized operation, wrong tenant, expired approval, and altered payload. Confirm denial at the target service and verify that the agent reports failure instead of claiming success.

Rotate the credential and confirm the old token stops working. Revoke the connector and measure how quickly active sessions, refresh tokens, cached clients, and scheduled jobs lose access. Disable a user and verify delegated grants. Remove a tool from policy and confirm it disappears from runtime registration as well as the interface.

Record the revocation objective and observed result. “Can be revoked” is vague. “The owner can revoke in the identity console; new calls fail within two minutes; scheduled jobs surface an authorization error; the old refresh token cannot recover access” is testable.

Caveat: permissions do not repair an untrusted connector

A narrow scope reduces impact, but it cannot make a malicious or vulnerable connector trustworthy. Review implementation provenance, update controls, secret storage, redirect behavior, dependency risk, logging, and incident response. If the connector can rewrite arguments after approval or exfiltrate within an allowed destination, scope alone will not reveal it.

Step 6: Publish rollout gates and operate the register

For every capability, name a technical owner, business owner, credential owner, log source, review date, expiry, revocation procedure, and incident contact. Link the test evidence. Mark unresolved gaps explicitly rather than converting them into generic “accepted risk.”

Roll out by consequence:

1. Synthetic data with no external writes.
2. Read access to a narrow non-production resource.
3. Reversible internal writes with per-action approval.
4. Limited production access with monitoring and kill switch.
5. Higher-consequence actions only after measured review.

Define launch gates such as zero cross-tenant access, complete approval binding, verified revocation, target-system audit logs, rate limits, alerting on denied calls, and an owner available during rollout. Re-run affected tests whenever tool schemas, scopes, identities, prompts, models, connector versions, or downstream policies change.

Monitor tool-call volume, unusual targets, denial rate, approval changes, data volume, new scopes, repeated retries, scheduled failures, and actions outside the normal time window. A permission audit is a versioned control, not a launch-day spreadsheet.

Frequently Asked Questions

How do I audit AI agent permissions?

Inventory every runtime tool, connector, account, credential, resource scope, and downstream effect. Classify actions as read, write, send, execute, or administrative; reduce credentials to least privilege; require exact approvals for consequential actions; test adversarial inputs and confused-deputy paths; then prove expiry, rotation, and revocation. Publish the evidence in a capability register with owners and review dates.

What belongs in an AI agent capability register?

Record the exact tool operation, acting identity, reachable resources, effect class, sensitivity, reversibility, approval policy, credential owner, logs, test evidence, expiry, and revocation procedure. Split broad connectors into effect-specific rows. The register should let a reviewer reproduce what the agent can do and identify who can stop it without relying on a product label.

Which agent actions should require approval?

Require per-action approval for external sends, publishing, deletion, financial or legal commitments, production commands, permission changes, sensitive exports, and actions whose targets originate in untrusted content. The preview must bind the exact identity, target, recipients, payload, and side effects. Changed arguments or stale state should invalidate approval rather than inherit an earlier click.

How do I test prompt injection against connected tools?

Place adversarial instructions in every untrusted input channel, including webpages, documents, email, comments, filenames, and tool results. Ask them to reveal data, change targets, or call other tools. Verify target-system logs and network behavior, not only the model’s prose. Expected tests should prove that prohibited calls and transfers never occurred.

How often should agent permissions be reviewed?

Review on every material change to tools, scopes, identities, prompts, models, connectors, or downstream policy. Also set an expiry-based review for unchanged capabilities, with shorter intervals for production writes and sensitive reads. Immediately reassess after an authorization failure, prompt-injection finding, anomalous tool call, credential incident, ownership change, or newly available narrower scope.

Permission is a runtime fact

The audit is complete only when the deployed system’s behavior matches the register. Catalog descriptions, policy documents, and approval labels are claims; tool traces, target-service enforcement, denial tests, and revocation results are evidence.

Audit AI agent permissions as a chain from requester to model, runtime, credential, connector, and target service. Keep every link narrow, observable, owned, and removable before the agent receives production authority.