← All insights

Current cybersecurity development

AI Agents Need an Employee-Style Access Review Before They Touch Business Data

AI agents are becoming operational identities. Small businesses should govern their permissions, tools, owners, monitoring, and shutdown procedures before deployment.

Office manager reviewing an AI workflow approval sheet with access boundaries and human approval points

The development to watch

Artificial intelligence is moving from question-and-answer tools toward systems that can plan tasks, call applications, create records, send messages, and take actions across a workflow. Microsoft’s current security guidance describes an agent as a first-class principal: it should have a managed identity, explicit roles, tightly scoped permissions, and controlled tool access.

This is an important shift for small businesses. An AI agent may not look like an employee in the directory, but it can still become an account with access to customer records, financial information, email, calendars, ticketing systems, or internal documents.

Start with an inventory

Before approving an AI workflow, record:

  • The business purpose and expected benefit.
  • The owner responsible for the agent.
  • The data it can read, create, change, export, or delete.
  • The applications and tools it can invoke.
  • The identity, credentials, tokens, and service principals it uses.
  • The human approval points for high-impact actions.
  • The logs available for review.
  • The shutdown, credential-rotation, and rollback procedures.

If nobody owns the agent, nobody owns its risk. “The vendor manages it” may describe hosting, not business authorization.

Apply least privilege to tools and data

An agent that needs to read a calendar may not need to send external email. An agent that drafts a support response may not need authority to issue a refund. An agent that searches a document library may not need permission to change retention settings.

Separate read, draft, recommend, approve, and execute capabilities. Use narrowly scoped roles and tool manifests where supported. Limit access to the smallest data set necessary for the defined task. Review whether the agent can follow instructions embedded in untrusted documents or messages and whether that could cause unintended actions.

Do not treat a successful pilot as proof that broad permissions are safe. A pilot may not include unusual data, adversarial instructions, vendor outages, or a compromised user account.

Add human control where consequences are high

Require a person to approve actions involving payments, payroll, legal commitments, deletion, external disclosure, changes to access, or messages that could create reputational harm. Approval should be meaningful: the reviewer needs enough context to understand what the agent proposes and which records it used.

For lower-risk actions, the business may allow automation with thresholds, rate limits, or sampling. Document why the control is appropriate and how the office will detect an error.

Monitor behavior, not only login events

Traditional account monitoring may show that an agent authenticated successfully, but it may not explain whether the agent performed an unusual sequence of actions. Review tool calls, data volumes, destinations, failed authorization attempts, privilege changes, and unusual time or frequency patterns.

Set alerts for bulk exports, repeated failed actions, new tools, changes to prompts or instructions, and access to sensitive repositories. Preserve enough information to reconstruct what the agent was asked to do, what it accessed, and what it changed, subject to privacy and retention requirements.

Revoke and recover

Test how to disable the agent identity, revoke tokens, rotate secrets, remove tool permissions, and undo or compensate for unintended changes. Microsoft specifically recommends practicing revocation and recovery paths for failure cases such as bulk ticket creation, unintended writes, or export attempts.

Do not wait for a production incident to discover that the agent’s credentials are embedded in a workflow owned by a former employee or that the vendor’s shutdown process requires a support ticket.

What is confirmed versus uncertain

Confirmed: AI agents can create identity, authorization, auditability, and least-privilege challenges. Confirmed: current vendor guidance recommends treating agents as managed principals with explicit scope and lifecycle controls.

Uncertain: the risk level of a particular tool or product. Capabilities, permissions, logging, data handling, and product behavior vary widely and are changing quickly. A business should verify the current vendor documentation and test the actual configuration.

A small-business approval rule

Before an agent receives access, require a one-page approval record with purpose, owner, data scope, tools, human approvals, monitoring, expiration or review date, and shutdown steps. Re-review it after a major model, connector, workflow, or permission change.

The immediate lesson is not that every AI agent is unsafe. It is that automation has become part of identity governance. If an agent can act, it needs an owner, boundaries, evidence, and a way to stop.

This article is a human-reviewed draft and should be reviewed with the organization’s technology, legal, privacy, and compliance advisers.

Sources