Once AI governance is in place, the security job is to turn the policy into enforceable technical controls. Do not start by buying an “AI security platform” and hoping it solves the problem. Start by understanding where AI is being used, what data it can reach, what actions it can perform, and what could go wrong.

Make sure you start with governance!

Read our other post here.

A useful model is:

Discover → Classify → Control → Monitor → Test → Improve

This aligns well with industry standards to govern, map, measure and manage AI risks, and with AI-specific guidance, which highlights risks such as prompt injection, insecure output handling, sensitive information disclosure, excessive agency, insecure plugins and supply-chain vulnerabilities.

Figure 1: An Approach to Securing AI in your Organisation

1. Start with the risk scenarios, not the products

For most organisations, the main AI security risks are:

Risk	Example
Sensitive data leakage	Staff paste client data, credentials, contracts or personal information into public LLMs.
Shadow AI	Users sign up for unapproved AI tools or browser extensions.
AI embedded in SaaS	Existing platforms quietly add AI features that access organisational data.
Prompt injection	Malicious content in emails, documents or websites manipulates an AI tool or agent.
Excessive agency	An AI agent can send emails, modify files, query systems or trigger workflows without enough control.
Over-permissioned agents	Desktop or SaaS agents inherit broad user permissions and access too much data.
Insecure AI-generated code	Developers ship code generated by AI without proper review.
Data poisoning / bad grounding	AI uses untrusted, outdated or manipulated data sources.
Insecure plugins and connectors	AI tools connect to email, files, CRM, finance or ticketing systems without strong controls.
Poor logging and investigation	The organisation cannot reconstruct what prompt, output, action or data flow caused an incident.

The ugly truth: AI agents are a bigger security problem than basic chatbots. A chatbot mostly produces text. An agent can observe, decide and act. That means identity, privilege, data access, logging, approval and kill-switch controls become critical.

---

2. Segment AI use into security tiers

Do not apply the same controls to every AI use case. Classify AI usage into tiers.

Tier	Example	Security posture
Tier 1: Public LLM use	ChatGPT, Claude, Gemini, Perplexity, etc. used for generic drafting or research	Restrict sensitive data, monitor usage, educate users
Tier 2: Enterprise LLM use	Microsoft 365 Copilot, Google Gemini for Workspace, ChatGPT Enterprise, internal knowledge assistants	Strong identity, DLP, data access review, logging, configuration hardening
Tier 3: AI embedded in business apps	CRM AI, HR AI, finance AI, ticketing AI, security AI	Vendor review, role-based access, data-flow review, monitoring
Tier 4: AI applications built by the organisation	RAG tools, chatbots, workflow copilots, AI customer support	Secure SDLC, threat modelling, testing, prompt injection controls, output validation
Tier 5: Desktop or autonomous AI agents	Agents that operate browsers, files, email, desktop apps or workflows	Least privilege, sandboxing, approvals, session recording, egress control, kill switch

For Tier 5 agents, assume compromise or manipulation is plausible. Microsoft and others have acknowledged agentic AI risks such as cross-prompt injection, where malicious content embedded in UI elements or documents can override agent instructions and cause unintended actions such as data exfiltration or malware installation.

---

3. Build an AI security architecture

A practical AI security architecture should have these layers:

Layer 1 — Identity and access control

AI tools and agents must be treated as identities, not just software.

Implement:

• SSO and MFA for all enterprise AI tools.
• Conditional access policies.
• Role-based access control.
• Privileged access management for admin functions.
• Separate service accounts for AI agents.
• No shared AI accounts.
• Least privilege access for AI connectors.
• Regular access reviews.
• Disable consumer AI accounts for business use where practical.

For agents, use the rule:

An AI agent should never have more access than the minimum needed for the specific task, and ideally less than the human user.

Layer 2 — Data security

This is usually the most important layer.

Implement:

• Data classification.
• Data loss prevention.
• Data discovery and labelling.
• Data security posture management.
• SaaS data exposure review.
• SharePoint / OneDrive / Google Drive permission clean-up.
• Controls preventing sensitive data being entered into unapproved AI tools.
• Retention and deletion rules for prompts, outputs and logs.
• Encryption and key management.
• Controls over training, fine-tuning and retrieval datasets.

Before enabling enterprise AI like Microsoft 365 Copilot or Gemini, fix your data permissions. Otherwise, AI will simply make existing overexposure faster and easier to exploit.

Layer 3 — Endpoint and browser control

Users will access AI through browsers, desktop apps, plugins and agents.

Implement:

• Endpoint detection and response.
• Mobile/device management.
• Browser security controls.
• Browser extension control.
• Application allowlisting or application control.
• Local admin restriction.
• Clipboard and upload controls for sensitive data where appropriate.
• Isolation or sandboxing for desktop AI agents.
• Monitoring of AI desktop applications.
• Blocking unauthorised AI executables and plugins.

Desktop AI agents are particularly sensitive because they may interact with local files, browsers, email clients and applications.

Layer 4 — Network, cloud and SaaS control

Implement:

• Secure web gateway or SSE/SASE controls.
• Cloud access security broker capabilities.
• DNS filtering.
• Firewall and proxy controls for known AI services.
• API gateway controls for AI APIs.
• Cloud security posture management.
• SaaS security posture management.
• Logging from AI platforms into SIEM.
• Egress monitoring for unusual data transfers.

You need visibility into both sanctioned and unsanctioned AI use.

Layer 5 — AI application security

For AI systems you build or configure, implement:

• AI threat modelling.
• Secure development lifecycle controls.
• Prompt injection testing.
• Output validation.
• Input sanitisation.
• Retrieval source filtering.
• Guardrails for dangerous actions.
• Rate limiting.
• Abuse detection.
• Secrets scanning.
• Model and API key protection.
• Red teaming for higher-risk systems.
• Human approval before sensitive actions.
• Segregation between instructions, user data and retrieved content.

OWASP identifies prompt injection, insecure output handling, sensitive information disclosure, insecure plugins, excessive agency and overreliance as key LLM application risks, so these should be explicit test cases in your security assurance process.

Layer 6 — Monitoring, detection and response

Implement:

• SIEM integration.
• User and entity behaviour analytics.
• DLP alerting for AI tools.
• AI usage logs.
• Prompt and output logging where legally and operationally appropriate.
• Agent action logs.
• API usage monitoring.
• Model abuse detection.
• Incident playbooks for AI-related incidents.
• Ability to suspend AI tools or agents quickly.

For AI agents, logs should answer:

• Who invoked the agent?
• What was the user trying to do?
• What data did the agent access?
• What instructions did it receive?
• What external content did it process?
• What tools or connectors did it use?
• What actions did it take?
• Was human approval required?
• What output was produced?
• Was data sent outside the environment?

---

4. Product categories you should consider

Do not treat this as a shopping list where every organisation needs every category. For a mid-sized organisation, I would normally prioritise identity, endpoint, DLP, CASB/SSE, DSPM, SIEM and SaaS posture before buying niche AI security tooling.

Core security products

Product category	Why you need it for AI
Identity provider / IAM	Enforces SSO, MFA, conditional access and access reviews for AI tools.
Privileged access management	Controls admin access to AI platforms, plugins, APIs and agents.
Endpoint detection and response	Detects malicious activity from desktop AI tools, agents, scripts and plugins.
Mobile/device management	Enforces device compliance before accessing enterprise AI.
Secure web gateway / SSE / SASE	Detects and controls access to public AI websites and data uploads.
CASB	Discovers shadow SaaS and AI tools, applies controls to cloud services.
DLP	Prevents sensitive data from being uploaded, pasted or shared into unauthorised AI systems.
DSPM — Data Security Posture Management	Finds sensitive data and excessive access across cloud, SaaS and data stores before AI exposes it.
SSPM — SaaS Security Posture Management	Identifies risky AI features, misconfigurations and excessive SaaS permissions.
SIEM / XDR	Centralises AI-related logs and detects suspicious activity.
SOAR / automation	Supports repeatable response to AI data leakage, misuse or agent incidents.
Secrets management	Protects API keys, model tokens and service credentials.
API gateway / WAAP	Secures AI APIs and integrations.
Secure code scanning	Reviews AI-generated code for vulnerabilities and secrets.

AI-specific or AI-enhanced security products

Product category	Use case
AI security posture management	Discovers AI assets, models, datasets, prompts, plugins, agents and risks.
LLM firewall / AI gateway	Mediates prompts and responses, applies policy, blocks sensitive data, logs activity and controls model access.
Prompt injection testing tools	Tests LLM apps and agents against known attack patterns.
AI red teaming platforms	Assesses jailbreaks, prompt injection, data leakage, unsafe outputs and agent abuse.
Model monitoring / evaluation platforms	Tracks accuracy, drift, hallucinations, toxicity, bias and security failures.
AI agent control plane	Manages permissions, actions, approvals, logs and kill switches for agents.
Content provenance / watermarking tools	Helps identify AI-generated content where this is required.

Be careful with vendor claims. The AI security product market is immature and full of overstatement. OWASP itself notes it does not endorse commercial products, and its LLM guidance should be used as a control and testing reference rather than a vendor selection shortcut.

---

5. What I would do first

Step 1 — Discover AI use

Find out:

• Which public LLMs are being used.
• Which enterprise AI tools are licensed.
• Which SaaS platforms have AI features enabled.
• Which browser extensions are installed.
• Which desktop AI agents are installed.
• Which APIs are calling AI models.
• Which departments are using AI for client, HR, finance, legal, cyber or customer-facing work.
• Which data sources are connected to AI tools.
• Which users have elevated access to AI-enabled systems.

Use:

• CASB/SSE logs.
• DNS/proxy logs.
• Endpoint software inventory.
• Browser extension inventory.
• SaaS admin consoles.
• Procurement records.
• Expense claims.
• API gateway/cloud logs.
• Staff survey.
• Business-unit interviews.

Output: AI asset and usage register.

Step 2 — Map data exposure

Identify:

• What data AI tools can access.
• Whether sensitive data is exposed.
• Whether permissions are excessive.
• Whether AI can access email, files, chat, CRM, HR, finance or ticketing systems.
• Whether data is used for model training.
• Whether prompts and outputs are retained.
• Whether data leaves Australia or approved jurisdictions, if relevant.

Use:

• DSPM.
• DLP.
• Microsoft Purview / Google data protection tooling.
• SaaS permission reports.
• Cloud data discovery.
• Records and privacy reviews.

Output: AI data exposure map.

Step 3 — Classify AI use cases

Classify each AI use case by:

• Data sensitivity.
• User population.
• Business criticality.
• External exposure.
• Legal or regulatory impact.
• Degree of autonomy.
• Whether it affects people.
• Whether it can take action.
• Whether it uses untrusted content.
• Whether it integrates with business systems.

Output: risk-tiered AI use-case register.

Step 4 — Threat model the high-risk use cases

For each high-risk AI system or agent, assess:

• Prompt injection.
• Data leakage.
• Excessive agency.
• Insecure connectors.
• Credential exposure.
• Bad output causing business harm.
• Unauthorised action.
• Supply-chain compromise.
• Model or prompt theft.
• Abuse by insiders.
• Overreliance by staff.
• Inability to investigate incidents.

Use OWASP GenAI / LLM Top 10 as a checklist. NIST’s AI RMF can frame this as mapping, measuring and managing risks across the lifecycle.

Output: AI threat model and control plan.

Step 5 — Define control baselines by AI tier

Example:

Control	Public LLM	Enterprise LLM	SaaS AI	Internal AI app	Desktop / autonomous agent
Approved tool only	Yes	Yes	Yes	Yes	Yes
SSO/MFA	Preferred	Required	Required	Required	Required
DLP	Required	Required	Required	Required	Required
Logging	Basic	Required	Required	Required	Detailed
Human approval	For sensitive use	Risk-based	Risk-based	Required for material outputs	Required for actions
Prompt injection testing	No	Limited	Vendor assurance	Required	Required
Data access review	Yes	Required	Required	Required	Required
Vendor review	Yes	Required	Required	N/A or supplier review	Required
Sandbox / isolation	No	No	No	Environment-based	Required
Kill switch	Block access	Disable service	Disable feature	Disable app/API	Mandatory

Output: minimum AI security control standard.

Step 6 — Implement controls in priority order

My recommended order:

1. Block or control unapproved public AI tools.
2. Approve a small number of enterprise AI tools.
3. Implement DLP for AI usage.
4. Clean up excessive data permissions.
5. Disable risky SaaS AI features until assessed.
6. Control browser extensions and desktop AI applications.
7. Require SSO/MFA and conditional access.
8. Log AI activity into SIEM.
9. Add AI to incident response.
10. Test high-risk AI systems and agents.

Step 7 — Monitor and improve

Track:

• AI tools discovered.
• Shadow AI usage.
• Sensitive data attempted in AI tools.
• Approved vs unapproved AI usage.
• AI incidents and near misses.
• Prompt injection test results.
• Agent actions performed.
• High-risk use cases awaiting review.
• Vendor AI feature changes.
• Exceptions granted.
• Training completion.

---

6. Specific guidance for LLMs

For public or enterprise LLMs:

Controls to implement

Area	Controls
Access	SSO, MFA, conditional access, approved users only
Data	DLP, data classification, no sensitive data in public tools
Configuration	Disable model training on organisational data unless explicitly approved
Logging	Capture user, tool, timestamp, data category, prompt/output metadata where appropriate
Usage	Approved use cases, human review, no high-impact decisions without approval
Output	Verification required for legal, financial, security, medical, client-facing or factual outputs
Browser	Restrict AI browser extensions and plugins
APIs	Centralise through approved AI gateway or API gateway
Vendors	Contractual controls for data use, retention, training, incident notification and deletion

Controls for internal LLM apps

Add:

• Secure SDLC.
• AI threat modelling.
• RAG source validation.
• Retrieval filtering.
• Prompt injection testing.
• Output encoding and validation.
• Secrets scanning.
• Rate limiting.
• Abuse detection.
• Red-team testing.
• Evaluation suite.
• User feedback and incident capture.

---

7. Specific guidance for desktop AI agents

This is where I would be strict.

Desktop agents should be treated like semi-autonomous privileged users. They can interact with files, browsers, emails, applications and websites. That creates a material risk of prompt injection, data leakage and unauthorised action.

Minimum controls for desktop agents

Control	Requirement
Formal approval	No desktop AI agent without business, security and privacy approval.
Separate identity	Agent runs under a dedicated constrained identity where possible.
Least privilege	Only access required apps, folders and systems.
Sandboxing	Run in isolated workspace, VM, browser container or managed agent environment.
No local admin	Agent must not have admin rights.
App allowlisting	Agent can only invoke approved applications and tools.
File access control	Limit folders, repositories, drives and sensitive locations.
Network egress control	Restrict external destinations and uploads.
Human approval	Required before sending emails, deleting files, changing records, making purchases, submitting forms, executing code or triggering workflows.
Session logging	Record actions, tool calls, accessed data and outputs.
Kill switch	Security team can immediately disable the agent.
Testing	Prompt injection and malicious document testing before deployment.
Monitoring	EDR, DLP, SIEM and behavioural monitoring.

A desktop agent should not be allowed to freely browse the web, read email, inspect documents, access internal systems and take actions unless you are comfortable defending that design to your board after an incident.

---

8. A practical target-state control stack

For a typical organisation, I would aim for this stack:

Foundation layer

• Identity provider with SSO/MFA/conditional access.
• EDR/XDR.
• MDM/device compliance.
• SIEM.
• DLP.
• Secure web gateway / SASE / CASB.
• Email and collaboration security.
• Vulnerability management.
• Secure configuration management.
• Backup and recovery.

Data and SaaS layer

• Data discovery/classification.
• DSPM.
• SSPM.
• SaaS app governance.
• SharePoint/OneDrive/Google Drive permission review.
• Records and retention tooling.
• Privacy management tooling.

AI control layer

• Approved AI tool catalogue.
• AI gateway / LLM proxy for APIs.
• AI usage monitoring.
• Prompt and response policy enforcement.
• AI application testing/red teaming.
• Agent sandbox or control plane.
• Model monitoring for internally built systems.
• Vendor AI risk assessment process.

Assurance layer

• AI threat modelling.
• Secure SDLC.
• Control testing.
• Internal audit.
• Incident exercises.
• Red teaming.
• Metrics and board reporting.

---

9. Controls mapped to standards and guidance

Security area	Controls	Standards / guidance
AI risk management	Inventory, classification, assessment, monitoring	NIST AI RMF Govern/Map/Measure/Manage
Cybersecurity governance	Policy, roles, risk appetite, oversight	NIST CSF 2.0 Govern; ISO/IEC 27001
LLM application security	Prompt injection testing, output validation, least privilege, plugin controls	OWASP Top 10 for LLM Applications
Data protection	DLP, classification, minimisation, retention, privacy impact assessment	ISO/IEC 27001, ISO/IEC 27701, privacy law
AI management system	AI policy, impact assessment, lifecycle controls, monitoring	ISO/IEC 42001
Supplier management	Vendor due diligence, contract clauses, assurance evidence	ISO/IEC 27036, ISO/IEC 42001
Secure AI design	Secure-by-design architecture, monitoring, threat detection	Google Secure AI Framework / SAIF
Incident response	AI incident playbooks, escalation, containment, lessons learned	NIST CSF Respond/Recover; ISO/IEC 27035

Google’s Secure AI Framework also reinforces the point that many AI risks should be addressed by extending established security practices into AI systems, rather than treating AI as completely separate from existing security architecture.

---

10. The implementation roadmap

First 30 days — gain visibility and stop obvious leakage

Do this first:

• Build an AI usage register.
• Identify public LLM usage.
• Identify desktop AI agents and browser extensions.
• Review enterprise AI licences.
• Identify SaaS platforms with AI enabled.
• Issue interim security rules for AI.
• Block clearly unacceptable AI tools.
• Enable logging for approved tools.
• Add AI sites to proxy/CASB monitoring.
• Start DLP monitoring for AI uploads.
• Identify high-risk users and teams.

Outcome: you know where the obvious AI risk is.

Days 31–60 — classify and design controls

• Classify AI tools and use cases by risk.
• Map data access for enterprise AI.
• Review permissions in document repositories.
• Define approved AI tools.
• Define prohibited AI uses.
• Define minimum controls by AI tier.
• Create vendor AI security questionnaire.
• Create AI incident response playbook.
• Define desktop agent approval criteria.
• Select technology gaps.

Outcome: you have a risk-based AI security control model.

Days 61–90 — implement priority controls

• Enforce SSO/MFA/conditional access.
• Implement DLP policies for AI.
• Block unapproved browser extensions.
• Configure CASB/SSE controls for public AI.
• Clean up over-permissioned data repositories.
• Integrate AI logs with SIEM.
• Review and harden enterprise AI platforms.
• Assess top 10–20 AI use cases.
• Test high-risk AI apps for prompt injection.
• Pilot controls for desktop agents.

Outcome: controls are operating, not just documented.

Months 4–6 — mature the architecture

• Deploy DSPM or strengthen data discovery.
• Deploy SSPM if SaaS AI exposure is material.
• Implement AI gateway for internal AI/API use.
• Build AI red-team test cases.
• Create agent sandboxing standards.
• Update procurement and contracts.
• Add AI scenarios to tabletop exercises.
• Report AI security metrics to leadership.

Outcome: AI security becomes business-as-usual.

Months 6–12 — assure and optimise

• Conduct independent assurance.
• Test DLP and CASB effectiveness.
• Red team high-risk AI apps and agents.
• Review AI incidents and near misses.
• Update control baselines.
• Validate vendor claims.
• Mature monitoring and response.
• Reassess AI risk appetite.

Outcome: you can prove the controls work.

---

Summary

For a normal organisation, the priority is not buying a shiny AI security platform. The priority is:

1. Know where AI is being used.
2. Stop sensitive data leakage.
3. Clean up excessive data access before enabling enterprise AI.
4. Control browser extensions and desktop agents.
5. Treat AI agents as privileged identities.
6. Force high-risk AI through threat modelling and testing.
7. Log enough to investigate incidents.
8. Have a kill switch.