Cybersecurity has always changed when computing changes. The internet changed the perimeter. Cloud computing changed infrastructure. Mobile devices changed identity and endpoint security. Software-as-a-service changed supply chains. Artificial intelligence will force another major shift, because it changes both the tools defenders use and the capabilities available to attackers.
The mistake is to think of AI as just another software category that needs to be patched, monitored and governed. AI is that, but it is also a capability layer that can sit inside almost every business process. It can write code, generate convincing messages, analyse logs, summarise incidents, automate workflows, assist fraud, impersonate people, search large data stores and operate through agents connected to tools. Cybersecurity therefore has to develop in two directions at once: it must secure AI systems, and it must adapt to a world in which attackers and defenders both use AI.
The basic security principles do not disappear. Organisations will still need asset management, identity controls, patching, backups, segmentation, logging, incident response, secure software development and vendor risk management. But the application of those principles will have to become more automated, more identity-centric, more data-aware and more focused on the behaviour of systems rather than only the configuration of devices.
AI will accelerate attackers
The most obvious change is speed. AI can help attackers write phishing emails, localise scams, generate malware variants, summarise stolen documents, analyse exposed code, identify vulnerable dependencies and automate reconnaissance. Not every attacker becomes elite, but many mediocre attackers become faster and more convincing.
Social engineering is likely to be one of the clearest early effects. Generative AI can produce personalised messages, mimic tone, create deepfake audio or video and adapt lures to a target’s role. Phishing will become less clumsy. Business email compromise will become more scalable. Voice verification and informal trust cues will become weaker. The old advice to “look for spelling mistakes” was never enough, and in the age of AI it becomes almost useless.
Attackers will also use AI to improve operational tempo. They can ask models to explain code, suggest exploitation paths, translate technical documentation, generate scripts or summarise logs stolen from a target. AI does not remove the need for skill, but it reduces friction. Cybersecurity teams should assume that adversaries can move faster through discovery, adaptation and deception.
Defenders will need AI, but cannot outsource judgment to it
Defenders will also use AI. Security operations centres already face too many alerts, too many logs and too much low-level triage work. AI can help summarise incidents, cluster related events, draft response steps, enrich alerts, search documentation, generate detection logic and help junior analysts understand unfamiliar signals.
This is valuable, but it creates a new risk: over-reliance. An AI system can confidently misread an alert, hallucinate a root cause, overlook a subtle privilege escalation or recommend a response that breaks production systems. AI can help analysts think faster, but it should not silently become the analyst of record for high-impact decisions.
The best future security teams will use AI as an accelerator, not an oracle. They will build workflows in which AI drafts, summarises and correlates, while humans retain responsibility for material decisions. They will log AI-assisted analysis, test AI recommendations and require escalation when confidence is low or consequences are high.
Identity becomes the new control plane
AI makes identity more important. When agents and automation can act across systems, the question “who is allowed to do this?” becomes more complicated. It is no longer only about human users. It is also about service accounts, bots, AI agents, plugins, model endpoints and delegated tool access.
Cybersecurity will need finer-grained identity and authorisation. An AI assistant should not inherit all the permissions of a senior executive merely because it helps that executive. A coding agent should not have production deployment rights unless that is deliberately granted. A customer support agent should not be able to export full customer records when it only needs subscription status.
Least privilege will need to apply to humans, machines and AI agents together. That means short-lived credentials, scoped permissions, approval gates, strong authentication, privileged access management, tool-specific policies and better visibility into non-human identities. Organisations that already struggle with service account sprawl will find AI makes the problem sharper.
Data governance becomes security governance
AI systems are hungry for data. They retrieve documents, index knowledge bases, process prompts, summarise communications and generate outputs from internal information. This means data governance becomes a core cybersecurity issue, not merely a compliance or records problem.
If sensitive information is poorly classified, AI tools may expose it. If access permissions are messy, retrieval-augmented systems may surface documents to people who should not see them. If prompts and outputs are logged carelessly, confidential information may be stored in new places. If model providers use customer inputs for improvement, data may travel further than expected.
Cybersecurity in the AI age will need stronger data maps, classification, retention rules, access controls and monitoring around where data flows. Security teams will need to understand not only databases and file shares, but also embeddings, vector stores, prompt logs, fine-tuning datasets, model outputs and AI vendor data practices.
Prompt injection becomes an application security problem
Prompt injection is often misunderstood as a quirky chatbot issue. It is better understood as an application security problem created when natural language instructions and untrusted data are mixed together. An AI system may read a webpage, email, PDF or ticket that contains instructions designed to manipulate the model. If the model is connected to tools, the result may be data leakage, unauthorised actions or misleading analysis.
This requires a change in security testing. It is not enough to test whether the model refuses obviously harmful prompts. Teams must test whether AI applications treat retrieved content as untrusted, whether tool access is constrained, whether outputs are validated before downstream use and whether agents can be tricked into using authority they should not exercise.
The old web security lesson still applies: never trust user input. In AI systems, “user input” includes prompts, documents, search results, emails, tool outputs, retrieval results and any external content the model can read.
Software supply chain risk will expand
AI adds new components to the software supply chain. Organisations may depend on foundation models, APIs, open-weight models, fine-tuned adapters, prompt libraries, evaluation datasets, vector databases, orchestration frameworks, agent tools, plugins and guardrail services. Each component can introduce risk.
Supply chain security will need to include model provenance, dataset integrity, dependency review, prompt and configuration management, model versioning and vendor assurance. Teams should ask which model is being used, where it is hosted, whether it can change without notice, what data it receives, how outputs are monitored and what happens if the vendor changes its terms or behaviour.
Secure software development will also have to adapt to AI-assisted coding. AI coding tools can improve productivity, but they can also generate vulnerable code, insecure defaults, hardcoded secrets or outdated patterns. Code review, testing, dependency scanning and secure design remain necessary. AI-generated code should not be treated as automatically safer because it looks polished.
Security architecture must include AI systems as first-class assets
Many organisations adopt AI through scattered pilots: a team buys a tool, a vendor enables an AI feature, staff use public models, a SaaS platform adds a copilot and developers connect an API. If those uses are not visible to security teams, they become shadow AI.
Cybersecurity will have to treat AI systems as first-class assets. They need inventory, owners, risk ratings, access controls, logging, vendor review, incident response plans and lifecycle management. Security teams should know which AI systems exist, what they can access, what actions they can take and what business process they affect.
This does not mean every AI feature requires the same level of control. A low-risk drafting assistant is different from an AI system that triages patients, screens job applicants or controls operational technology. But without an inventory and risk classification, organisations cannot tell the difference.
Security operations will become more automated and more adversarial
Security operations will increasingly use AI to handle scale. AI can help correlate alerts, explain attack paths, draft detection rules, recommend containment steps and summarise incident timelines. Over time, some response actions may become semi-autonomous, especially in low-risk, high-volume scenarios.
But attackers will adapt to AI-enabled defenders. They may craft activity to confuse detection models, poison logs, mimic normal behaviour, target the AI tools used by security teams or exploit excessive trust in automated summaries. Security operations will therefore need adversarial testing of AI-enabled workflows, not just deployment of AI tools.
AI-driven SOCs will need controls around model inputs, analyst review, response authority, audit trails and fallback procedures. The question will not be “Can the AI detect this?” but “Can the AI-assisted workflow detect, explain, escalate and respond safely under pressure?”
Incident response must include AI failure modes
AI introduces new incident types. A model may leak sensitive information. A prompt injection may cause an agent to send data to the wrong place. A retrieval system may expose documents across permission boundaries. A model may produce harmful or misleading advice. A vendor may change a model in a way that breaks a workflow. A fine-tuning dataset may be poisoned. An AI coding tool may introduce a systemic vulnerability.
Incident response plans should therefore include AI-specific playbooks. Who can disable an AI feature? How are prompts, outputs and tool calls preserved for investigation? How is affected data identified? What vendors must be contacted? What logs exist? Who assesses privacy, legal, safety and customer impact? How are users warned if an AI-generated output was wrong?
Good AI incident response will combine cyber, privacy, legal, operational and communications expertise. The incident may not fit neatly into an old category such as malware, ransomware or data breach.
Governance and board oversight will become more technical
Boards and executives do not need to understand every model architecture. But they will need to ask better questions about AI and cybersecurity. Where are we using AI? What data does it access? Which AI systems can take action? Which vendors are involved? How do we test them? How do we monitor them? What happens if they fail?
Cybersecurity governance will need to connect with AI governance. The AI register, vendor review process, impact assessment process, security architecture and incident response plan should not be separate islands. AI risk is partly cyber risk, partly privacy risk, partly operational risk, partly legal risk and partly reputational risk.
The organisations that handle this well will not treat AI security as a specialist side project. They will integrate it into ordinary security and risk management while adding the new controls AI requires.
Secure by design must apply to AI products
One of the most important shifts will be pressure on AI vendors to build security into products by default. Customers should not have to discover after deployment that prompts are logged indefinitely, customer data trains models, audit logs are unavailable, permissions are too broad or unsafe features are enabled by default.
Secure by design for AI means clear data boundaries, strong defaults, transparent model and vendor documentation, robust access controls, safe tool integration, monitoring, testing, incident support and predictable change management. It also means vendors should take responsibility for reducing customer risk rather than pushing every control onto the buyer.
Procurement teams will need to ask sharper AI security questions. Security questionnaires will evolve. Vendor contracts will need to address data use, model training, subprocessors, audit rights, incident notification, output limitations and liability.
The future is layered resilience
Cybersecurity in the age of AI will not be solved by buying an AI security product. It will require layered resilience. Organisations will need stronger identity, better data governance, AI-aware application security, secure AI development, improved vendor review, AI-assisted security operations, adversarial testing, incident response and board oversight.
The goal is not to stop using AI. AI will be too useful to ignore. The goal is to use it with enough control that organisations can benefit from automation without handing attackers new paths through their systems.
The security teams that adapt best will be those that keep the old disciplines and extend them. Asset management now includes AI systems. Identity now includes agents and service accounts. Application security now includes prompts, retrieval and model outputs. Vendor risk now includes model providers and data use. Incident response now includes AI failure modes. Governance now includes evidence that AI systems are controlled, monitored and accountable.
AI will make cybersecurity faster, stranger and more consequential. The answer is not panic. It is disciplined adaptation: secure by design, least privilege, data control, human accountability, continuous testing and resilience when systems fail. That is how cybersecurity develops from defending networks and applications to governing intelligent, automated systems embedded across the organisation.
Leave a Reply