AI Agents and Cybersecurity: Understanding Business Risk

The next security challenge may not be a human user

For years, organisations built security controls around people. A person signed in, opened an application, accessed a file and performed an action.

AI agents change that model.

An AI agent can be given access to information, tools and business systems and can potentially decide which tool to use based on a task. Instead of a person performing every step, the agent may retrieve information, call an API, create a document, update a system or trigger an automated workflow.

That can create enormous productivity benefits. It also creates a new security question:

What happens when an identity can reason, access systems and take actions at machine speed?

The answer cannot simply be to stop using AI. Businesses need to learn how to give agents useful capabilities without giving them uncontrolled authority.

AI agents are different from traditional automation

Traditional automation usually follows a defined workflow. If a condition occurs, the workflow performs a known set of actions.

An AI agent can operate with more flexibility. It may interpret a request, choose between tools and produce an outcome that was not explicitly written as a fixed sequence.

That flexibility is valuable, but it makes security more complicated.

An agent may have access to:

• Business documents
• Customer information
• Internal APIs
• Email or collaboration systems
• Databases
• Cloud resources
• Financial or operational systems
• Other AI services

The security problem is not simply whether the model is safe. It is whether the entire agent has the right identity, permissions, data boundaries and operational controls.

1. Every agent needs an identity

One of the first principles for AI security is simple: treat an agent as a workload, not as an anonymous piece of software.

The organisation should know which agent exists, who owns it, what it is allowed to access and why it has those permissions.

Where possible, use dedicated workload identities or managed identities rather than sharing a human administrator account.

This creates accountability. If an agent makes an unexpected change, security teams should be able to determine which agent performed the action and which owner is responsible for it.

2. Least privilege becomes even more important

An employee might have access to hundreds of documents because they need broad access to do their job. Giving an AI agent that same access may be unnecessary.

Agents should receive the smallest set of permissions required for their specific purpose.

For example, an internal HR agent might need to retrieve approved HR documents, but it probably does not need the ability to modify employee records. A finance agent might need read access to reports but not the authority to approve payments.

Separate read and write capabilities wherever practical.

The more powerful the agent, the stronger the need for explicit boundaries.

3. Data access is the heart of AI security

An AI system can only protect information if the underlying access model is correct.

This is particularly important in Microsoft 365 environments. If SharePoint permissions are too broad, an AI assistant operating within those permissions may surface information that users should not have been able to access in the first place.

That is why AI readiness should start with data governance.

Review:

• SharePoint and OneDrive permissions
• External sharing
• Microsoft 365 groups
• Guest access
• Sensitive information
• Retention and classification
• DLP controls
• Data owners

AI does not remove the need for information governance. It increases the value of getting it right.

4. Tool access creates a new attack surface

The most interesting part of an agent is often its tools.

An agent that can only answer questions has a different risk profile from an agent that can send email, create records, change permissions or call production APIs.

Each tool should therefore be treated as an additional security boundary.

Ask:

What can this tool do if the agent behaves incorrectly or is manipulated?

For sensitive actions, consider approval steps, restricted APIs, transaction limits or human confirmation.

An agent may be allowed to draft an email automatically while requiring a person to approve the final send. It may be allowed to retrieve financial information but not initiate a payment.

The right boundary depends on the business risk.

5. Prompt injection is a security concern

AI agents can process instructions from users, documents, web pages and other data sources. That creates opportunities for malicious instructions to influence behaviour.

Imagine an agent is asked to summarise documents. One of the documents contains text attempting to instruct the agent to ignore its original task and reveal information or call another tool.

The agent may not distinguish perfectly between trusted instructions and untrusted content.

This is why agent design needs separation between trusted instructions, user input, retrieved data and tool permissions.

Do not assume that because an instruction appears in a document it should be trusted.

6. Protect secrets and credentials

Agents often need credentials to interact with other systems. Those credentials should be protected like any other production secret.

Use appropriate secret management, rotate credentials where practical and avoid placing secrets directly into prompts, source code or configuration files.

A compromised agent identity can become a path into multiple systems if the same credentials are reused.

The principle is simple: one agent should not become a master key to the organisation.

7. Logging becomes essential

When an AI agent performs actions, organisations need to understand what happened.

Logs should help answer:

• Which agent acted?
• Which user initiated the request?
• What information did it access?
• Which tools did it call?
• What action did it perform?
• Was the action successful?
• Did a human approve it?

This creates an important distinction between agent identity and user identity.

If a user asks an agent to perform an action, the audit trail should ideally preserve both identities rather than showing only that an application account performed the action.

8. Human approval is still valuable

Not every agent action needs human approval. If an agent sorts low-risk documents, requiring approval for every action would remove much of the productivity benefit.

But high-impact actions deserve stronger controls.

Consider human approval for activities such as:

• Sending sensitive information externally
• Changing security settings
• Deleting important records
• Approving financial transactions
• Modifying user permissions
• Making irreversible production changes

The objective is not to put a human in every loop. It is to put a human in the right loops.

9. AI security needs an ownership model

One of the risks organisations can easily overlook is ownership.

An employee creates an AI agent for a useful business task. Six months later that person changes roles. The agent remains active, still has access to data and nobody knows who is responsible for it.

Every production agent should have an owner, purpose, business sponsor and review process.

Consider maintaining an inventory containing:

• Agent name
• Owner
• Business purpose
• Data sources
• Tools and APIs
• Identity
• Permissions
• Environment
• Risk level
• Last review date

This turns AI governance from an abstract policy into something operational.

10. Agents should not automatically inherit human privilege

A common design mistake is to let an agent operate with the full permissions of the user who initiated a request.

That may be convenient, but it can produce excessive privilege.

Instead, consider what the agent actually needs to complete its task. If an agent is designed to search a particular knowledge base, it may not need access to every system the employee can access.

This is one of the areas where identity architecture, application design and AI governance meet.

Build AI security into the architecture

A mature AI security model can be thought of as several layers:

Identity — Who is the agent and who owns it?

Access — What can it read, write or execute?

Data — What information can it retrieve?

Tools — Which APIs and actions can it use?

Guardrails — What actions are restricted or require approval?

Monitoring — What happened and can we prove it?

Governance — Who reviews the agent and its permissions?

None of these layers works properly in isolation.

What should companies do now?

You do not need to wait until every AI agent is deployed to start preparing.

First, identify where AI is already being used. This includes approved enterprise tools as well as business teams experimenting with AI applications and automation.

Second, review the underlying identity and data environment. Poor permissions, unmanaged identities and weak information governance will create problems regardless of which AI platform you use.

Third, establish an approval and ownership process for production agents.

Finally, classify agent use cases by risk. A low-risk internal assistant and an agent capable of modifying production systems should not go through the same controls.

The future is not human versus AI

The practical security challenge is more nuanced. Businesses will increasingly operate environments where people, applications and AI agents work together.

That means identity security will expand beyond protecting employees. Data governance will need to account for machine access. Monitoring will need to understand automated behaviour. And security teams will need to ask not only who can access a system, but what an AI identity can do once it gets there.

AI agents can be extremely valuable. But their usefulness should never be measured only by what they can do.

A well-designed agent is one that can do the right things, for the right reason, with the right level of access, and with enough visibility to know what happened.