An AI tool that helps an employee summarise a document presents a different risk from an agent that can read customer records, update a system and instruct a supplier without waiting for approval. Yet both can end up covered by the same general statement that the organisation has “approved AI”. That is where a formal policy can give the board reassurance while leaving the security team with little control over what happens in practice.
This distinction is becoming vital. According to the 2026 Gartner CIO and Technology Executive Survey, 17% of organisations have deployed AI agents and more than 60% expect to do so within the next two years. As AI moves from producing answers to taking action, the question for CISOs changes. It is no longer enough to know which tools have been purchased. They need to know what each system can reach, what it can change and who is accountable when it acts outside its intended scope.
A risk-based AI security policy should set those boundaries before deployment. It should distinguish between low-impact assistance and activity that could expose sensitive data, affect a customer or alter a production environment. For each use case, it should name the business owner, define permitted data and actions, specify where a human must approve a decision and establish how activity will be recorded, challenged or stopped. The greater the autonomy and potential impact, the stronger those controls should be. This is consistent with the National Cyber Security Centre’s interim advice on agentic AI (August 2026).
Regulation is raising the standard of evidence
The regulatory picture is more complicated than a single new “AI compliance” obligation. The EU AI Act’s transparency requirements began applying on 2nd August 2026. Certain systems must make clear when a person is interacting with AI and when content has been artificially generated or altered, although marking obligations for systems already on the market do not apply until 2nd December 2026. Its reach can extend to UK organisations that place AI systems on the EU market or whose AI outputs are used in the EU, so location alone is a poor guide to exposure.
The Act also sets obligations for high-risk AI systems, including documented risk management and human oversight. Following changes to the timetable (see the Commission’s AI Omnibus announcement), the main rules for systems classified as high-risk under Annex III are due to apply from 2nd December 2027, while those for AI embedded in certain regulated products are due from 2nd August 2028. Organisations should use that time to establish which systems may fall into these categories and what evidence they would need to show that their controls work. A policy drafted shortly before a deadline will not recreate the testing, decisions and records that should have accompanied deployment.
Other regimes matter because AI will change the risks attributed to and managed for systems they already govern. NIS2 requires in-scope entities operating in the EU to address areas such as risk analysis, security policies, incidents, continuity and supply-chain security. DORA requires in-scope financial entities to manage and test ICT risk, including risks involving third-party providers. Neither is a blanket AI policy law for every business, but an agent connected to a critical service or financial workflow can alter the risk that those organisations must control.
In the UK, the proposed Cyber Security and Resilience Bill would strengthen the framework for organisations within its scope, such as operators of essential services and their suppliers. It remains a Bill, so businesses should track its progress rather than treat proposed duties as law already in force.
The consequences of weak governance go beyond a failed audit. EU AI Act breaches can attract substantial, tiered penalties where its provisions apply. Depending on the activity, organisations may also face supervisory action under sector-specific rules, a personal-data incident, disrupted services or the inability to explain how an automated decision was made. The exact legal exposure depends on the system and the organisation. What a CISO can control now is whether the business can identify its AI use, justify its risk decisions and demonstrate the controls behind them.
The board needs a different question answered
Senior leaders often hear a sensible case for AI in terms of speed, productivity and competitive advantage. Security and compliance teams are then asked whether the chosen platform is approved and whether a policy exists. Those questions are useful, but they do not reveal the exposure created when an agent inherits broad access to files or is allowed to execute a workflow that was designed for a human employee.
An AI tool can make information reachable through a simple query when a user already has permission to access it. That should prompt a review of access rights which may have accumulated over years, including folders that were shared for an earlier purpose. An autonomous agent adds another dimension because it may be able to act on the information it finds. A governed strategy must therefore connect the board’s intended benefit to the precise access, authority and failure scenarios the business is prepared to accept.
Start by testing what AI agents can actually do
The practical starting point is an AI security assessment. Inventory approved tools and investigate use outside the formal procurement route. Map the data, identities, integrations and third parties each system depends on. Test what an agent can do with its actual permissions, rather than relying on the permissions described in a design document. Classify use cases by their potential impact and degree of autonomy, then set technical limits, approval gates, monitoring and a way to suspend activity quickly. Where personal data is involved, assess the relevant data protection and accountability requirements (guidance currently under review following the Data (Use and Access) Act).
This review should also expose decisions that have no clear owner. Who approves a new connection between an agent and a customer database? Who checks whether a model or supplier change has altered the original risk assessment? Who can withdraw access when behaviour is unexpected? A formal policy has value when these questions have operational answers and those answers are tested as AI use changes.
AI adoption will not wait for organisations to resolve every uncertainty in the regulatory landscape. That makes it more important to design policy around the risks they can already see: sensitive data, inherited permissions, autonomous actions and weak oversight. For a CISO, the test of readiness is whether an agent can be kept within its authorised task and whether the organisation can prove what happened when it was not.
Join our LinkedIn group Information Security Community!
