How much access does your AI agent really need?

An agent is an accumulation of authority

A user may have permission to read information. A workflow may have permission to update records. A service account may have permission to access systems after hours. An agent can bring those authorities together.

That is what makes agents useful. It is also what makes them different from most traditional applications. The security review is not simply about whether access exists. The review is about understanding the combination of authorities the agent is allowed to exercise and whether that combination is still justified.

An agent that can read one system is different from an agent that can read five. An agent that can recommend an action is different from an agent that can perform it. Each additional source, permission and action increases both capability and risk.

The question is not whether the agent has access. The question is whether the authority created by that access is appropriate.

An inventory is a start, not proof of control

An agent may appear in a catalog and still have:

• Permissions nobody has reviewed
• A connection nobody maintains
• A knowledge source nobody owns
• No agreed response when it acts outside its purpose
• No process to disable it if something goes wrong

Start with what the agent can actually do, not the label attached to it. In our security guide, identity, threat monitoring, information protection and continuing ownership are separate review areas. Bringing them together requires the people responsible for each area to agree what evidence they need. A product purchase does not perform that review for you.

Be precise about whose authority is being used

An agent working with a signed-in person and an agent running in the background need different access questions. Identify the user, application or agent identity involved at each step. Find out what happens when:

• The person signs out
• The person changes roles
• The person leaves the organization
• The agent owner changes
• The connected service changes

Treat the actual identity path as a review artifact. Don’t assume anyone knows it from memory.

Not all agents carry the same risk

Many reviews treat every agent as though it creates the same exposure. They do not. Consider the difference between:

• Observation: The agent can read information and answer questions.
• Recommendation: The agent can suggest actions but cannot execute them.
• Preparation: The agent can create documents, summaries, drafts or updates for human review.
• Execution: The agent can change records, send communications or trigger downstream processes.
• Delegation: The agent can coordinate work across multiple systems and services.

Moving up this ladder increases the consequences of an error. An incorrect summary and an incorrect workflow execution are not the same problem. An incorrect recommendation and an unauthorized system change are not the same risk.

The most important security question is often not “What can the agent see?” but “What can the agent cause?”

A review record for one agent

At minimum, the review should establish the following.

The completed record should allow another team to understand how the agent works without relying on tribal knowledge.

Test the resource side of the connection

The agent’s instructions might say it should only work on one project. That is not evidence that the file store, CRM system or API prevents access to another project. Review the authorization at the resource as well as the guidance given to the agent.

Illustrative example. An agent helps prepare a sales review. It needs to read approved opportunity information. That does not automatically justify:

• Changing opportunity stages
• Sending customer emails
• Updating forecasts
• Accessing unrelated customer records

Use non-sensitive test data to demonstrate:

• The permitted read
• The denied update
• The denied access to unrelated information

Then inspect the evidence. If the test succeeds only because a human notices a mistake and stops it, record that dependency rather than describing it as an enforced boundary.

Least privilege must include the workflow

Organizations often review permissions one system at a time. The agent experiences those systems as a workflow. Each individual permission may appear reasonable when reviewed in isolation. Combined together, they may enable actions nobody intended. Examples include:

• Reading customer information and sending messages
• Reading financial information and updating forecasts
• Reading HR information and creating tickets
• Combining data from multiple systems into a new output

The question is not whether each permission is justified individually. The question is whether the resulting workflow is justified. Least privilege for the agent requires reviewing both the individual permissions and the combined capability they create.

A working connection is not enough

For an MCP server or other tool connection, establish:

• Who approved it
• What it can do
• What information it can access
• How credentials are protected
• Who maintains it
• How usage is monitored

A familiar server name is not an access review. Neither is a successful connection test. Review the destinations and operations exposed through the connection. Ask the security team:

• What suspicious activity could be detected?
• Which signals are being collected?
• Who receives the alert?
• Who investigates?
• How would the incident be contained?

Trace a controlled test through that process. The catalog entry, the activity record and the incident response are different pieces of evidence.

Security reviews expire

An agent that passed review six months ago may now have:

• Additional permissions
• Additional tools
• Additional instructions
• Additional users
• Additional data sources
• Additional workflow actions

A review performed at deployment does not establish that the same conditions still exist today. Re-evaluate when:

• New sources are connected
• New actions are enabled
• Sensitive information becomes available
• Business processes change
• Ownership changes
• New integrations are approved

The question is not whether an agent was secure. The question is whether it is secure now.

Keep ownership separate from sponsorship

The operational owner looks after the service. The business sponsor decides whether the service should continue and whether its access remains justified. Those are different responsibilities.

The operational owner focuses on availability, maintenance, support and configuration. The sponsor focuses on business value, risk acceptance, scope and continued justification. Both roles need to be identified. Neither role should be assumed.

Give someone authority to stop it

Every agent should have a defined process for pause, disablement or retirement. Determine:

• Who can disable it
• What event triggers a review
• What happens to its access
• What happens to its connections
• How critical work continues

An organization should never discover during an incident that nobody knows how to stop an agent.

Leave the review with something usable

The result should be more than a completed checklist. The review should leave behind:

• A current agent record
• Tested access boundaries
• Evidence supporting permissions
• Identified owners
• Known limitations
• Unresolved gaps
• Follow-up actions

Use that information to decide what is ready, what needs correction and what should not be expanded.

Final thought

An agent review should be able to answer five questions:

What can the agent see? What can the agent do? Under whose authority? Who is watching? Who can stop it?

If those answers depend on assumptions, undocumented knowledge or somebody’s memory, the review is not complete. An agent is not secure because it exists in a catalog. An agent is secure because its authority, access, ownership and behavior are understood, tested and actively governed.