Securing AI: your newest attack surface

AI adoption has outpaced AI security

In most organisations I speak with, AI did not arrive through a formal program. It arrived through a browser tab. Someone in finance started summarising reports with a chatbot. Marketing connected a writing assistant to the shared drive. A developer plugged a coding assistant into the repository. Then Microsoft 365 Copilot was switched on, and suddenly an AI could see everything a user could see.

None of that is inherently bad. The productivity gains are real, and the organisations that learn to use AI well will have a real advantage. The problem is that security usually finds out last.

When I ask leadership teams three simple questions, the answers are revealing:

1. Which AI tools are being used across the business today?
2. What data are those tools allowed to see?
3. What are they allowed to do with it?

Very few can answer all three with confidence. That gap is where the risk sits. AI is not a separate technology sitting off to one side. It is now connected to your identities, your data, your applications and, more and more, your business processes. It needs to be secured with the same discipline as anything else that touches those assets.

The risks are new in shape, not in nature

Having spent years in red teaming and incident response, I tend to look at AI the way an attacker would. What has changed is not the attacker's goal. It is the number of new doors we have opened.

Shadow AI. Staff paste customer records, contracts and source code into public AI tools to get their work done faster. Once that data leaves your environment, you have limited control over where it is stored, how long it is kept or whether it is used to train a model.

Oversharing through AI assistants. Tools like Copilot respect existing permissions, which sounds reassuring until you remember how many organisations have years of loose SharePoint and Teams permissions. AI does not create that exposure. It makes it searchable in seconds.

Prompt injection. Large language models cannot reliably tell the difference between an instruction and the data they are processing. A malicious instruction hidden in an email, a web page or a document can redirect an AI tool to leak information or take an action the user never intended. It sits at number one in the OWASP Top 10 for LLM Applications 2025 ↗ for good reason.

Agents with too much authority. The next wave of AI does not just answer questions. It sends emails, updates records, raises tickets and calls APIs. Every agent is effectively a new identity, often with broad, standing access and very little monitoring. If it can be manipulated, that access can be misused.

The AI supply chain. Third-party models, plugins, browser extensions and SaaS features with AI switched on by default all extend your attack surface. Many organisations have not updated their vendor risk process to ask where AI sits in the products they already use.

Attackers using AI too. Phishing is now fluent, personalised and produced at scale. Deepfake voice and video are being used to impersonate executives and approve payments. Your people and your processes need to assume that a convincing message is no longer proof of a genuine one.

A practical way to secure AI

You do not need an entirely new security program. You need to extend the one you have across five areas.

1. Governance: decide before you deploy. Set a clear AI use policy that tells people which tools are approved, what data can and cannot be used, and who signs off on new use cases. Keep an inventory of AI tools and features in use, including those embedded in existing SaaS platforms. Align it with frameworks your board already recognises, such as ISO 27001, ISO 42001 ↗ for AI management and the Australian Signals Directorate's guidance on engaging with artificial intelligence ↗.
2. Data: fix the foundations first. Before switching on an AI assistant, clean up permissions, classify sensitive information and apply data loss prevention controls. Tools such as Microsoft Purview and Netskope can see and control what flows into AI applications, including public ones, without simply blocking productivity.
3. Identity: treat every AI agent as a user. Give agents their own identities, the minimum access they need and time-bound permissions where possible. Require human approval for high-impact actions like payments, deletions or external communications. Enforce strong authentication for anyone who can configure or administer AI tools.
4. Application and model security: test it like an attacker. If you are building on AI, include prompt injection, data leakage and jailbreak testing in your security assessments and penetration tests. Validate inputs and outputs, restrict what connected tools can reach and threat model the whole workflow, not just the model.
5. Detection and response: watch what AI does. Log prompts, responses and agent actions where appropriate, feed them into your SOC and build AI scenarios into your incident response plan. If an agent is manipulated at 2am, you want to know before the damage is done, not when the audit finds it.

Where to start in the next 90 days

If this feels like a lot, start small and build momentum.

1. Discover. Find out which AI tools and features are actually in use. The answer is almost always more than leadership expects.
2. Decide. Publish a simple AI use policy and name an owner for AI risk. Clarity beats perfection here.
3. Protect the data. Review permissions and sensitivity labels before any wider AI rollout, starting with your most sensitive repositories.
4. Control the agents. Inventory any AI that can take actions, reduce its access and put a human in the loop for anything high impact.
5. Test and monitor. Add AI to your next penetration test and make sure your SOC can see AI activity.