How to Secure AI Agents Before They Access Business Data

An employee creates an AI agent to search SharePoint documents, summarise customer information and prepare reports.

It works.

Then someone gives the agent permission to send emails, update CRM records or access financial documents. Nobody stops to document exactly what the agent can access, which identity it uses or what happens when it receives a malicious instruction.

That is where AI security becomes an IT operations problem.

An AI agent is not just another chatbot. Once it can call APIs, read company data or make changes, it becomes an identity with delegated authority. It needs the same basic controls you would apply to a user, application or server: an owner, limited permissions, logging, monitoring and a process for removing access.

Microsoft's recent security work reflects this shift. Its July 2026 security updates highlighted agentic defence, AI threat protection, identity and data security, while Microsoft has also described AI and cloud environments as requiring a more unified security control plane.

The sensible approach is not to stop employees using AI. It is to control what AI is allowed to do.

Start with an inventory of every AI agent

The first problem is usually visibility.

Most businesses can identify their laptops and servers reasonably well. Fewer can produce a reliable list of every SaaS application employees use. AI agents make this problem worse because they can be created quickly inside development platforms, Microsoft 365, CRM systems and other business applications.

An AI inventory should record at least:

• Agent name and business purpose.
• Owner responsible for it.
• Platform where it runs.
• Identity or service account it uses.
• Applications and APIs it can access.
• Data it can read.
• Data it can modify or delete.
• External services it can call.
• Authentication method.
• Logs available for investigation.
• Date of the last access review.

Do not assume that a small company does not have this problem.

A 30-person business can create an agent with access to a Microsoft 365 tenant just as easily as a larger organisation.

The risk is not the number of agents. It is the authority they have.

If an agent can only summarise public documents, the security requirement is relatively modest.

If it can read payroll files and change financial records, the controls need to be considerably stronger.

Give agents their own identities and minimum permissions

An agent should not operate using a permanent Global Administrator account.

That sounds obvious, but broad permissions are often granted because they make development easier.

The better approach is least privilege.

If an agent needs to read a particular SharePoint site, give it access to that site rather than the entire tenant.

If it needs to create CRM records, give it that permission without automatically granting deletion or administrative rights.

If it needs to send email, consider whether it needs unrestricted mailbox access or only permission to send from a specific account.

This becomes particularly important when an agent acts on behalf of a human user.

The security team should be able to distinguish between:

Who requested the action?

and

Which agent performed the action?

That distinction becomes critical during an investigation.

Microsoft has been developing controls around agent identity, observability and governance because organisations are increasingly dealing with large numbers of AI agents rather than a small number of manually managed applications.

The principle is straightforward: an agent should have an identifiable owner and a defined permission boundary.

Prompt injection is an access-control problem as well

Prompt injection is often described as an AI model problem.

For businesses, the more useful way to think about it is as an interaction between untrusted content and privileged tools.

Consider an agent that reads incoming emails and summarises them.

An attacker sends an email containing instructions designed to manipulate the agent. If the agent can then call internal tools, search confidential documents or execute actions, the malicious content may influence what the agent does.

The problem becomes more serious when three conditions exist together:

• The agent processes untrusted input.
• The agent has access to sensitive information.
• The agent can take actions without human approval.

You cannot solve this simply by telling the model, "Do not follow malicious instructions."

Security controls need to exist outside the model's reasoning.

For example, an agent could be allowed to read a customer record but not delete it. It could draft an email but require approval before sending it. It could search a document library but be prevented from accessing payroll or legal folders.

This is the same principle used elsewhere in security: do not rely on instructions when a technical permission can enforce the boundary.

What organisations often get wrong

The first mistake is treating AI security as a software purchasing exercise.

Buying an AI security product without knowing which agents exist does not solve the underlying problem.

Start with inventory and permissions.

The second mistake is giving agents the same access as the employee who created them.

That can be unnecessarily broad.

An employee might legitimately have access to hundreds of documents. The agent performing one narrow task may only need five.

The third mistake is allowing agents to perform high-impact actions automatically.

There is a major difference between generating a draft and sending it, or between identifying an invoice and approving payment.

A useful rule is:

The more irreversible the action, the stronger the approval requirement.

Deleting a document, changing a bank account, creating an administrator account or sending a legally significant message should not be treated like generating a summary.

The fourth mistake is assuming existing application logs provide enough information.

They may show that an account accessed a record, but not necessarily whether a human or an agent initiated the request.

Agent activity needs enough context to reconstruct the chain of events.

Log the complete chain of activity

When an AI agent makes a decision or takes an action, the audit trail should answer several questions.

For example:

• Which employee or system initiated the request?
• Which agent processed it?
• Which identity did the agent use?
• Which application or API did it call?
• What information did it access?
• What action did it perform?
• Was human approval required?
• What was the result?

This information becomes especially important when something goes wrong.

Suppose an agent modifies 200 customer records overnight.

An administrator needs to determine whether the activity was authorised, whether the correct agent performed it and which input triggered the behaviour.

Without a usable audit trail, the investigation quickly turns into guesswork.

The same applies to security monitoring.

Useful events may include unusual agent activity, permission changes, new OAuth consent, unexpected API calls and access to data outside the agent's normal scope.

The goal is not to log every piece of AI output forever.

It is to retain enough evidence to understand important actions and investigate abnormal behaviour.

What to do next, in order

Start by discovering which AI agents are already being used. Include Microsoft 365, development platforms, CRM systems, automation platforms and third-party SaaS applications.

Next, document the owner, identity, permissions and data access for each agent. Remove permissions that are not required for its stated purpose.

Then classify agent actions by risk. Reading information is different from modifying it, and modifying information is different from deleting records or approving financial transactions.

After that, implement approval controls for high-impact actions. Keep low-risk automation automatic where it provides genuine business value.

Finally, make sure agent activity is logged and monitored. Test realistic scenarios involving malicious documents, prompt injection, compromised credentials and attempts to access information outside the agent's intended scope.

AI agents are becoming part of the infrastructure rather than remaining simple productivity tools. The security response should therefore be familiar: know what exists, assign ownership, restrict permissions, monitor activity and test the controls.

The mistake is not allowing AI to act.

The mistake is allowing it to act without knowing exactly what authority you have given it.