How to Limit the Blast Radius of an AI Agent Security Incident

In this blog post How to Limit the Blast Radius of an AI Agent Security Incident we will explain how to stop one compromised agent, stolen account or bad instruction from becoming a business-wide problem.

“Blast radius” simply means how far the damage can spread. You may not be able to prevent every AI mistake or attack, but you can control which systems an agent can reach, what actions it can take and how quickly your team can contain it.

This matters because an AI agent is more than a chatbot. It combines an AI model such as OpenAI or Anthropic Claude with company data, memory and software tools that let it complete tasks. Depending on its permissions, an agent might search SharePoint, update customer records, send emails, create cloud resources or change files.

Why AI agents change the impact of a security incident

A traditional chatbot usually produces an answer for a person to review. An AI agent can decide on a series of steps and then carry them out through application programming interfaces, or APIs, which are the connections software uses to communicate with other systems.

The risk is not simply that the model produces a wrong answer. The real danger is that a manipulated or confused agent uses legitimate access to perform an unauthorised action at machine speed.

This can begin with prompt injection, where malicious instructions are hidden inside an email, document, website or code repository. The agent reads those instructions as part of its work and may treat them as commands. We explored this issue further in the security risks affecting AI coding agents.

The safest assumption is that an agent will eventually receive misleading input. Your controls should ensure that even if the agent makes a bad decision, it cannot cause unlimited damage.

1 Give every agent its own identity and limited permissions

The fastest way to create a large blast radius is to let an agent use an employee’s account, a shared administrator login or an access key that works across several systems. If that access is compromised, it becomes difficult to identify the agent, revoke its permissions or determine what it changed.

Each production agent should have a separate digital identity. In a Microsoft environment, Microsoft Entra ID, which controls access to Microsoft 365 and Azure, can be used to identify the agent and restrict the resources it is allowed to access.

Apply the principle of least privilege. This means giving the agent only the minimum access needed for its specific job, rather than granting broad permissions because they are easier to configure.

For example, an invoice follow-up agent may need to read approved invoice records and prepare an email. It should not be able to change bank details, export the full customer database or send thousands of messages without approval.

{
 "agent": "invoice-follow-up",
 "allowed": [
 "read-approved-invoices",
 "draft-customer-email"
 ],
 "approval-required": [
 "send-customer-email"
 ],
 "blocked": [
 "change-bank-details",
 "export-customer-list"
 ]
}

This example is not tied to one AI platform. It shows the business rule that should sit behind the technical configuration.

2 Separate agents by task, data and environment

One all-powerful agent may appear cheaper and easier to manage, but it creates a single pathway into every connected system. A better approach is to use smaller agents with clearly defined responsibilities.

A human resources agent should not be able to access finance systems. A sales agent should not be able to change Azure infrastructure. A development agent should not have unrestricted access to live customer data.

Development, testing and production should also remain separate. Test agents should work with sample or masked information, where sensitive details have been removed, instead of real employee and customer records.

Network boundaries add another layer of protection by limiting which systems can communicate. Within Azure, this may involve separate subscriptions, resource groups or private network connections. In plain English, you are placing each agent in its own controlled lane rather than giving it access to the entire motorway.

This approach also reduces cost because workloads can be monitored and limited individually. Our guide to safer AI agent orchestration patterns explains how to coordinate multiple agents without creating unnecessary complexity.

3 Require approval for high-impact actions

Not every action needs a person watching it. Requiring approval for every routine task would remove much of the productivity benefit of AI.

Human approval should instead be placed around actions that are expensive, difficult to reverse or likely to affect customers. Examples include changing payment information, deleting records, publishing content, sending bulk communications, modifying security settings or approving a financial transaction.

Approval is only one control. Practical limits can also include:

• A maximum transaction value.
• A limit on records changed in one hour.
• An approved list of email recipients or business systems.
• A waiting period before destructive actions are completed.
• A second approval for unusually large or sensitive requests.

These controls turn a potentially unlimited incident into a contained one. An agent might still make an incorrect change, but it cannot alter 20,000 records before anyone notices.

4 Make every action visible and easy to revoke

You cannot contain an incident if you cannot see what the agent is doing. Logs should record the agent’s identity, the data it accessed, the tools it called, the approvals it received, the actions it attempted and whether those actions succeeded.

A central security monitoring system should then look for unusual behaviour. Warning signs might include an agent accessing a new data source, operating outside business hours, exporting large volumes of information or repeatedly attempting a blocked action.

Microsoft Defender, which detects suspicious activity across Microsoft environments, can help identify threats involving identities, devices and cloud services. Wiz, which provides a consolidated view of cloud risks, can help reveal exposed resources, excessive permissions and risky connections that increase the potential blast radius.

Your response plan should be able to disable the agent identity, revoke its access tokens, block its network connections and disconnect individual tools. Do not rely on a single dashboard button. Our article on creating an emergency off switch for AI agents covers this containment process in more detail.

5 Design recovery before the agent goes live

Stopping an agent is only the first part of recovery. Your team must also determine what it accessed, what it changed and whether those changes can be safely reversed.

Use soft deletion, version history and staged processing wherever possible. These features retain earlier information or hold actions in a queue, giving your team an opportunity to review and restore changes.

Regular, tested backups remain essential. This connects AI agent security directly to the Essential Eight, the Australian Government’s cybersecurity framework that many organisations use to reduce common security risks.

The Essential Eight does not contain a special exemption for AI. Its principles still apply, particularly restricting administrative privileges, using multi-factor authentication, patching systems, controlling applications and maintaining reliable backups.

Before production deployment, document the agent’s owner, data access, maximum financial impact, recovery method and shutdown process. Our pre-production AI agent risk assessment provides a practical starting point.

What controlled blast radius looks like in practice

Consider a 200-person professional services company introducing an agent to process support requests. The first design gives it access to email, SharePoint, the customer database and an administrator account used to reset passwords.

If a malicious instruction arrives inside an email attachment, the agent could potentially search confidential files, alter customer records and misuse the administrator account. One poisoned document could affect several parts of the business.

A safer design gives the agent its own identity, read-only access to a dedicated knowledge library and permission to create draft support tickets. Password resets require approval, customer exports are blocked and the agent can process no more than 20 requests within ten minutes.

The second agent can still save employees hours of repetitive work. However, if something goes wrong, the likely impact is a small queue of incorrect draft tickets rather than a reportable data breach or widespread system outage.

A practical 30-day containment plan

1. Inventory your agents. Record each agent’s owner, purpose, identity, data sources, connected tools and current permissions.
2. Remove shared and administrator accounts. Replace them with separate identities and narrowly defined access.
3. Set action limits. Add approval requirements, transaction caps, recipient restrictions and rate limits.
4. Centralise monitoring. Ensure agent activity reaches the same security monitoring process used for employees, applications and cloud infrastructure.
5. Test containment and recovery. Run a simulation in which an agent behaves unexpectedly, then measure how quickly your team can stop it, investigate it and reverse its actions.

The broader risks are covered in our guide to controlling hidden AI agent security risks. The key lesson is that security should not depend on the model always interpreting information correctly.

Keep the value and contain the risk

AI agents can reduce manual work, improve response times and help employees make better use of company information. Those gains do not require giving an agent unlimited access.

The goal is to make the safe path the easiest path. Separate identities, limited permissions, controlled data access, approval gates, detailed monitoring and tested recovery plans allow your business to use AI without turning every error into a major incident.

CloudProInc brings more than 20 years of enterprise IT experience to this problem. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations across Australia build practical controls around Azure, Microsoft 365, OpenAI, Claude, Defender and Wiz without creating unnecessary red tape.

If you are not sure how far one of your AI agents could reach today, we are happy to review the setup and identify the largest exposure points — no strings attached.