AI & Security Strategy: A Practical Framework for Secure AI Adoption

AI use is no longer confined to controlled pilots or innovation teams. Employees use public AI services to draft content and analyse information, software platforms introduce embedded AI features and business teams create agents that can access data or act across connected systems.

This creates a practical question for business and security leaders: how can the organisation scale useful AI while maintaining control over its data, access, decisions and risk? The answer is to connect each use case to a defined business objective, an accountable owner and controls proportionate to its access and potential impact.

Those controls should cover the AI lifecycle, from design and procurement through deployment, operation, change and retirement. The UK National Cyber Security Centre (NCSC) provides a useful foundation with guidance spanning secure design, development, deployment and operation and maintenance.

A practical AI security strategy gives leaders the visibility and accountability to scale successful use cases with appropriate safeguards. Controls should become stronger as a system gains access to more sensitive information, broader permissions or greater authority to affect business activity.

What Does AI & Security Mean for a Business?

AI security covers the data, identities, applications, models, infrastructure and business processes involved in using artificial intelligence. It also governs what a system can access, which recommendations or decisions it can influence and which actions it can perform.

Organisations need to consider risks to AI systems themselves, including prompt injection, sensitive information disclosure, insecure outputs, vulnerable dependencies, manipulated data and excessive permissions for agents or connected applications. Attackers may also use generative AI to support phishing, social engineering, reconnaissance or malicious automation, increasing the speed or reach of established attack methods.

For most organisations, the immediate priority is understanding how AI changes existing flows of data, identity and authority. A drafting assistant working with public information presents a different level of exposure from an agent that can access customer records, send external communications or modify financial data.

An effective strategy applies controls according to the consequences of each use case. Leaders should understand what a system can see, which decisions it can influence and what it can do within the organisation’s environment.

How Should Business Objectives Shape the AI Security Strategy?

AI security should begin with the outcome the organisation wants to achieve. A clearly defined use case gives business and security teams the context to assess value, identify exposure and decide what controls are appropriate.

Before approving a use case, document:

• The business problem or opportunity;
• Intended users and beneficiaries;
• Information the system requires;
• Applications, models and suppliers involved;
• Decisions the AI will support;
• Operational actions it may perform;
• Potential impact of error, disclosure or unavailability;
• Stages that require human review or approval and
• Conditions that would trigger suspension or retirement

This information supports proportionate governance. A tool that summarises public information may need only a lightweight assessment, while a system processing regulated data or changing business records requires deeper assurance, stronger monitoring and clear approval boundaries.

The need for business clarity grows as organisations adopt agentic AI. Gartner forecast in June 2025 that more than 40% of agentic AI projects would be cancelled by the end of 2027, citing factors including escalating costs, unclear business value and inadequate risk controls. This is a forecast, not a reported cancellation rate, and it underlines the commercial risk of deploying agents without a clear business case or operating model. 

Business leaders should measure productivity, quality, cost and speed alongside security, compliance and operational resilience. A strong strategy helps valuable use cases proceed with defined controls and gives leaders a basis for challenging projects that seek sensitive information or powerful permissions without a credible business case.

How Can Organisations Discover Shadow AI & Establish Ownership?

Effective governance depends on an accurate view of how AI is already being used. An AI inventory should include centrally purchased platforms as well as public AI services, embedded software features, browser extensions, meeting assistants, coding tools, custom applications, external model APIs and locally created agents.

For each identified system, record:

• Its business and technical owners
• The users and departments involved
• The supplier and contractual arrangement
• The information it can access
• Its connections to other applications
• Its authentication method and permissions
• The available audit and security logs
• Its approval status
• Its review or retirement date

A maintained inventory gives teams an operational basis for identifying changes in ownership, access, integrations and supplier terms. It also helps them understand where AI is used and which business processes could be affected.

Shadow AI often develops when employees need capabilities that approved services do not provide quickly or conveniently. Organisations should combine discovery and proportionate technical controls with a practical route for requesting suitable AI services.

Clear acceptable-use rules can explain which information may be used with different categories of AI service. Approved alternatives should also address genuine user needs, so employees can work productively within defined boundaries.

CyberOne’s guidance on effective AI governance starting with visibility describes an approach based on discovery, assessment, governance, protection and continuous monitoring. The aim is to maintain a view of AI assets, accountable owners, information flows and potential business consequences.

What Are the Most Important AI Data Security Risks?

AI makes information easier to retrieve, combine, summarise and transfer. These capabilities can improve productivity, but they may also expose weaknesses in existing permissions and data governance.

An enterprise AI platform can apply a user’s access rights correctly and still surface content more efficiently than the organisation expects. For example, a user who can access an overshared SharePoint site may be able to locate and synthesise its information quickly through an AI assistant.

Every significant use case should include a map of its data pathway. The review should cover prompts, uploaded information, grounding sources, retrieved organisational data, generated outputs, interaction logs, training arrangements, processing locations, retention and deletion.

Important AI data security risks include:

• Over-permissioned SharePoint, Teams and OneDrive content
• Public or organisation-wide sharing links
• Stale groups, accounts and guest access
• Unclassified or incorrectly labelled sensitive information
• Confidential material entered into unmanaged services
• Generated outputs that reproduce protected information
• Agents or connectors that provide access to additional systems
• Inconsistent retention across prompts, outputs and logs

These risks require a combination of controls. Sensitivity labels can identify and protect information, while accurate permissions, access reviews, retention, Data Loss Prevention and monitoring help govern how it is used.

Organisations should distinguish between individual AI products and service tiers. Contractual commitments, administrative visibility, data handling and available controls may differ across enterprise services, consumer tools and third-party agents.

Microsoft states that Microsoft 365 Copilot respects users’ existing permissions and that prompts, responses and data accessed through Microsoft Graph are not used to train the foundation large language models used by the service. Microsoft also documents how interaction data is stored and how Microsoft Purview can support retention and investigation. These commitments relate to the documented Microsoft services, so teams should confirm the terms and controls for every AI product, model and agent they use.

How Should Identity, Permissions & AI Agent Actions Be Controlled?

Exposure increases when an AI system has authority to take action. An agent may act through a human identity, service account, application identity or delegated token, so security teams need to know which identity is acting and which resources it can reach.

Least privilege remains essential, alongside a related principle of limiting an agent’s authority. Organisations should restrict both the information an agent can access and the actions it is permitted to perform.

Controls should distinguish between permission to:

• Read information
• Create records
• Modify existing records
• Communicate externally
• Initiate transactions
• Delete data
• Change permissions
• Perform administrative actions

Approval boundaries should reflect potential business impact. Low-risk actions may be suitable for autonomous operation, while actions involving customers, payments, legal commitments, security configurations or sensitive records may require user confirmation or independent approval.

Every agent should have a containment plan. Authorised teams need the ability to disable the agent, revoke credentials, remove permissions, disconnect integrations, stop downstream workflows and preserve relevant evidence.

Recovery requirements should also be considered during design. Where an agent can modify information or trigger operational processes, teams need to know how they will identify affected records, reverse unintended changes and restore normal service.

CyberOne’s guidance on questions to ask before giving AI access to business systems provides a practical assessment of permissions, information pathways, monitoring, accountability and containment. Reassess an agent when its purpose, data access, permissions or integrations change. 

How Should AI Applications, Models & Suppliers Be Assured?

An AI service may depend on models, datasets, software libraries, APIs, cloud infrastructure, plug-ins, connectors and downstream business systems. Supplier assurance should examine this wider service chain because weaknesses in any component can affect the confidentiality, integrity or availability of the application.

The assessment should establish:

• Where information will be processed and stored
• Whether customer data can be used for model improvement
• Which subprocessors and external services are involved
• How vulnerabilities are identified and corrected
• Which audit and diagnostic logs are available
• How service or model changes are communicated
• What happens to data when the contract ends
• How quickly the supplier must report an incident
• Whether information and configurations can be exported
• How the organisation will operate during a service outage

Internally developed AI requires assurance from the design stage onwards. Development teams should use threat modelling, dependency testing, segregated environments, release controls, change management and documented rollback procedures.

Testing should cover the complete application and its connected tools. A model may behave as expected in an isolated evaluation but respond differently when it processes instructions hidden inside documents, websites or data returned from external systems.

Generated outputs also need attention when other applications process them automatically. The business impact may be significant if an output triggers code, changes a record, starts a workflow or sends an external message.

The NCSC’s guidance for secure AI system development covers supply-chain security, documentation, asset management, infrastructure protection, incident management, logging and updates across the lifecycle. It can inform assurance for both purchased platforms and internally developed AI systems. 

What Does Effective AI Monitoring & Incident Readiness Look Like?

AI governance should continue throughout a system’s operational life. Security, risk and operational teams need evidence that each system remains within its approved purpose, access boundaries and authority.

Useful monitoring signals may include authentication events, identity changes, permission grants, data access, API activity, agent actions, administrative changes and unusual consumption. The relevant signals will depend on the business process, technical architecture and telemetry available from suppliers.

Monitoring should focus on activity that could indicate a material deviation. Examples include an agent accessing a new repository, a service identity receiving additional permissions or a system initiating more external communications than its approved use case requires.

Visibility varies across products. Some platforms provide detailed application and audit logs, while others offer limited access to prompts, outputs or tool activity. Procurement and design reviews should define logging requirements before deployment.

Incident response plans should address plausible scenarios such as:

• Sensitive information entered into an unapproved AI tool
• Compromise of an agent or service identity
• Prompt injection causing unintended behaviour
• Unauthorised autonomous action
• Poisoned data or model components
• Compromise of an AI supplier
• Inaccurate output affecting a material decision
• Loss of an AI service supporting an important process

Each scenario should define containment authority, evidence requirements, access-revocation steps, stakeholder escalation and recovery. Teams should also test whether emergency actions can be performed quickly and whether available logs support a reliable investigation.

Microsoft Sentinel can contribute to centralised analysis when the required telemetry is available. CyberOne’s guidance on detecting AI threats with Microsoft Sentinel explains how identity, cloud, API and application logs can support investigation, while recognising that monitoring depends on data quality, architecture knowledge and carefully designed detections.

What Should an AI Governance Framework Include?

An AI governance framework establishes who can approve AI use, who owns the associated business risk and how the organisation evaluates whether controls remain effective. It should give teams a repeatable decision process that reflects each use case’s value and potential consequences.

Material use cases should have named accountability across several areas:

• A business owner responsible for value and acceptable operational risk
• A data owner responsible for appropriate information use
• A technical owner responsible for design and reliability
• A security owner responsible for controls and monitoring
• Legal, privacy or compliance input where obligations apply
• An operational owner responsible for support, incidents and retirement

Committees can provide oversight and specialist advice, but each use case still needs a named decision-maker. Clear accountability helps prevent gaps between the team pursuing productivity, the team granting access and the team expected to respond when activity falls outside the approved design.

The framework should define acceptable use, prohibited use, risk tiers, procurement requirements, development gates, testing, human oversight, exceptions and periodic reassessment. It should also cover change management because a new integration, model or permission can materially alter a system’s exposure.

Measurement should focus on outcomes that show whether governance works in practice. Useful indicators may include:

• The percentage of AI assets with named owners
• The percentage of high-risk systems assessed before deployment
• Unapproved AI activity identified and resolved
• Excessive permissions removed
• High-impact agent actions requiring approval
• Overdue exceptions
• AI-related incidents detected and contained
• Controls tested successfully
• Business value delivered by approved use cases

How Does Microsoft 365 Copilot Fit Into the Wider Strategy?

Microsoft 365 Copilot is one implementation case for organisations using Microsoft 365. Preparation should cover information permissions, oversharing, external access, identity governance, retention, agents, monitoring and incident response.

Microsoft states that Copilot uses a user’s existing permissions to access organisational information. This means poorly governed or overshared content may influence the information returned to that user. 

Microsoft Purview can support information classification, Data Loss Prevention, retention and investigation. Microsoft Entra can govern identities and access, while Microsoft Defender and Microsoft Sentinel can contribute risk signals, investigation and response.

These capabilities work best within an operating model that defines ownership, review responsibilities and escalation. Organisations still need to decide which information AI may access, which agents can operate and which actions require human approval.

Microsoft describes two relevant dashboards. The Copilot security dashboard in the Microsoft 365 admin centre focuses on Copilot data protection and compliance insights, while the Microsoft Security Dashboard for AI provides a broader view across supported Microsoft and third-party AI assets. 

Microsoft currently identifies the Security Dashboard for AI as being in public preview. Availability and coverage may change, so confirm supported products, permissions and licensing requirements before deployment. 

What Is a Practical Roadmap for Secure AI Adoption?

A practical roadmap should prioritise high-value use cases and material exposure. The following sequence is an example, not a fixed timetable; organisations should adapt it to their scale, regulatory exposure, data maturity and the authority granted to each system.

Phase One: Discover & Prioritise

During the first 30 days, identify approved, embedded and unapproved AI services, assign preliminary owners and select use cases with the greatest value or exposure. Teams should also map critical data access, contain urgent weaknesses and establish baseline measures for future improvement.

The output should be a prioritised inventory connecting each use case to business value, ownership, information and permissions. This gives leaders evidence for deciding which projects can proceed and which need further control.

Phase Two: Establish Guardrails & Run Controlled Pilots

During the following 60 days, publish acceptable-use rules, establish a proportionate approval process and address critical permission or data exposure. Apply identity controls, supplier assurance, monitoring requirements and response procedures to selected pilot use cases.

Each pilot should have measurable business and security criteria. These may include time saved, output quality, user adoption, information accessed, policy exceptions and the ability to contain unexpected activity.

Phase Three: Operationalise & Scale

Over the next three to six months, integrate relevant AI activity into security monitoring, automate repeatable controls and extend successful use cases. Review ownership and exceptions regularly, and reassess when new data sources, integrations, models or permissions are introduced.

The organisation should also establish processes for updates and retirement. AI systems evolve, so continued approval should depend on each system remaining aligned with its defined purpose and the organisation’s risk tolerance.

Map Microsoft capabilities to defined security outcomes. Teams should first understand the use case and exposure, then specify the required control and assess how existing investments in Microsoft Purview, Entra, Defender and Sentinel can help address the gap.

Secure AI Adoption Depends on Sustained Control

Secure AI adoption requires visibility into the systems being used, clear ownership of business outcomes and controls that reflect access and authority. A lifecycle approach maintains that control after deployment through monitoring, reassessment, incident readiness and planned retirement.

Organisations do not need to resolve every historic data or security issue before making progress. Prioritising high-impact use cases and material exposure creates a practical route to adoption while strengthening the foundations for future scale.

CyberOne’s AssureAI readiness review and roadmap assesses AI usage, identity, data security, device management, governance, monitoring and attack-surface exposure. It produces a prioritised roadmap connecting control gaps to Microsoft capabilities, ownership and measurable business readiness.

The outcome should be a more controlled path from AI opportunity to operational value. Leaders gain clearer evidence of how AI is being used, where exposure exists and which improvements will support confident expansion.

Frequently Asked Questions