The most dangerous thing about agentic AI isn't that it makes mistakes — it's that it makes them autonomously, at scale, with credentials your security team issued without fully understanding what they were authorising. As enterprises move from passive generative AI tools to autonomous agents that can query databases, trigger workflows, and interact with external systems, the cybersecurity perimeter doesn't just shift — it dissolves. Managing that risk requires transitioning from traditional perimeter-based defence to a zero-trust architecture where every request — human or machine — is continuously verified, never assumed trustworthy.

This isn't a future problem. If you've deployed any form of agentic AI in the last eighteen months, you already have an expanded attack surface. The question is whether you've noticed yet.

Why Is Agentic AI a Cybersecurity Problem Specifically?

Most enterprise security frameworks were designed around a fairly stable cast of characters: employees, devices, applications, and the occasional contractor. Agentic AI introduces a new category of actor — one that holds credentials, makes multi-step decisions, accesses sensitive systems, and operates at a speed no human auditor can match in real time.

Unlike a generative AI tool that waits to be prompted, an agentic AI system (think: autonomous workflow agents, AI-driven RPA, or multi-agent orchestration frameworks) can initiate actions independently. It might query your CRM, pull financial records, call an external API, and update a customer record — all without a human signing off on each step.

That's genuinely useful. It's also a significant liability if the agent is compromised, misconfigured, or operating with broader permissions than its task actually requires.

"I've sat in rooms where a board has approved an AI automation programme and simultaneously been briefed on a cybersecurity strategy that doesn't mention AI agents once. Those two conversations need to be the same conversation."
— Nicholas Hodder

What's the difference between a generative AI tool and an agentic AI system?

It's worth being precise here, because the security implications are categorically different.

The distinction matters because organisations routinely apply the security posture of the first column to systems that operate like the second. That gap is where incidents happen.

How Does Digital Transformation Expand the Attack Surface?

Every integration point you add is, from a security perspective, a door. Some of those doors have good locks. Many of them have the key taped to the frame because someone needed to get the integration working by end of quarter and the security review "was going to happen later."

When you connect legacy ERP systems to cloud platforms, deploy API-driven middleware, and then layer autonomous AI agents on top of all of it, you're not just building capability — you're creating a distributed, interconnected attack surface that grows faster than most security teams can map it.

According to IBM's 2024 Cost of a Data Breach Report, the average cost of a data breach reached $4.88 million globally — a figure that climbs significantly when the breach involves cloud environments or third-party integrations. The organisations most exposed are often those mid-transformation: past the point of simple perimeter defence, not yet at the point of mature zero-trust implementation.

What specific threats are targeting enterprises in 2025 and 2026?

The threat landscape hasn't just evolved — it's been industrialised. Cybercriminals now use AI with the same enthusiasm as legitimate enterprises, and considerably fewer governance meetings.

• AI-generated phishing campaigns: Highly personalised, contextually accurate, and generated at scale. The "Nigerian prince" era is over. Modern phishing emails reference your actual job title, your real colleagues, and your genuine projects — scraped from LinkedIn and synthesised by an LLM.
• Automated ransomware: Faster propagation, adaptive evasion of endpoint detection, and increasingly targeted at operational technology (OT) systems and critical infrastructure.
• Supply chain attacks: Compromising a trusted vendor or software dependency to gain access to multiple downstream organisations simultaneously — the SolarWinds model, now more common and harder to detect.
• Prompt injection against AI agents: A genuinely new category of attack where malicious instructions are embedded in content that an AI agent processes — effectively hijacking the agent's actions through its own inputs.
• Credential harvesting from over-permissioned service accounts: AI agents often run under service accounts created quickly and reviewed rarely. These are attractive targets precisely because they hold broad system access.

The last item on that list is one I'd particularly flag for any organisation that's moved fast on AI automation. Speed of deployment and principle of least privilege are in constant tension, and speed usually wins until it doesn't.

What Is Zero-Trust Architecture and Why Does It Matter Now?

Zero-trust architecture (ZTA) is a security model built on a simple, uncomfortable principle: trust nothing and no one by default, regardless of whether they're inside or outside your network perimeter. Every access request — from a human employee, a third-party application, or an autonomous AI agent — must be continuously authenticated, authorised, and validated against policy.

This is the opposite of the traditional "castle and moat" model, where once you're inside the network you're broadly trusted. That model made sense when your perimeter was a physical office and a server room. It makes considerably less sense when your "perimeter" is a hybrid cloud environment, a remote workforce, and a fleet of AI agents operating across multiple external APIs.

What are the practical steps to implementing zero-trust?

Zero-trust isn't a product you buy — it's an architectural philosophy you implement incrementally. The following is a realistic sequence, not a vendor's marketing roadmap:

1. Map your identity landscape completely. This means human identities, service accounts, and — critically — AI agent identities. If you can't enumerate what holds credentials in your environment, you can't protect it.
2. Apply the principle of least privilege rigorously. Every entity — human or machine — should have access only to what its current task requires. Not what might be convenient later. Not what was easier to configure. The minimum necessary access, reviewed regularly.
3. Implement continuous authentication, not point-in-time. A user (or agent) authenticated at 9am is not necessarily trustworthy at 2pm if their behaviour has changed. Adaptive authentication systems monitor for anomalies throughout a session.
4. Segment your network microscopically. Micro-segmentation limits the blast radius of a breach by preventing lateral movement. If an agent or user account is compromised, they should not be able to traverse freely across systems.
5. Establish comprehensive audit logging for AI agent actions. Every action taken by an autonomous agent should be logged with enough fidelity to reconstruct what happened, why, and what data was accessed. This isn't just good security — it's increasingly a regulatory requirement.
6. Conduct regular red-team exercises that specifically include AI systems. Your penetration testing programme needs to model attackers who understand agentic AI, not just traditional network vulnerabilities.

None of this is simple, and all of it takes longer than the timeline your vendor's implementation guide suggests. That's not cynicism — it's an honest account of how infrastructure change actually works in organisations with legacy systems, competing priorities, and finite security team capacity.

How Does "Shadow AI" Create Security Vulnerabilities?

Shadow IT — employees using unauthorised tools because the authorised ones are inadequate — has been a security concern for years. Shadow AI is its considerably more alarming successor.

When employees paste customer data into a consumer-grade AI tool to save themselves an hour of work, that data has left your control. When a team builds an internal automation using a free-tier AI API without security review, you've acquired an integration point nobody mapped. When a manager subscribes to an AI productivity tool on their corporate card without procurement involvement, you've added a vendor relationship with unknown data handling practices to your risk register — whether or not it's on your risk register.

A 2024 survey by Salesforce found that 55% of employees are using AI tools their employer hasn't officially approved. That's not a rogue workforce — that's a workforce doing what workforces do when the official tools don't meet their needs. The security response to shadow AI cannot be purely prohibitive, because prohibition without alternative is just friction that eventually gets routed around.

How do you control shadow AI without killing productivity?

The answer, frustratingly, involves both policy and culture — which means it's slower and less satisfying than a technical control, but considerably more effective.

• Publish a clear, accessible AI acceptable use policy — not a 40-page legal document, but a usable guide that tells employees what they can use, what they can't, and why. Most employees aren't trying to create security incidents; they just want to know the rules.
• Create a fast-track approval process for AI tools. If the alternative to shadow AI is a six-month procurement cycle, shadow AI will win every time. A lightweight review process for lower-risk tools removes the incentive to go around the system.
• Deploy data loss prevention (DLP) controls at the endpoint and network level to detect when sensitive data categories are being transmitted to unapproved destinations.
• Make approved tools genuinely better than the shadow alternatives. This is the hardest one, and the one most IT strategies skip. If the sanctioned AI tools are slow, restricted, and frustrating, employees will use the fast, capable consumer tools. The security team cannot win that fight through enforcement alone.

Cybersecurity, Compliance, and the Board: Why This Is No Longer an IT Problem

The regulatory environment has made cybersecurity a board-level obligation in a way that cannot be delegated downward and forgotten about. Two frameworks in particular deserve attention from any UK or EU-operating organisation:

What does DORA mean for financial services organisations?

The Digital Operational Resilience Act (DORA) came into force in January 2025, applying to financial services organisations operating in the EU. It mandates specific requirements around ICT risk management, incident reporting, third-party risk management, and operational resilience testing. For any financial services organisation using AI systems — including agentic AI in trading, compliance, or customer service workflows — DORA creates direct accountability at board level for the resilience and security of those systems.

Non-compliance isn't a theoretical risk. Penalties can reach 2% of total annual worldwide turnover, and national competent authorities have explicit powers to impose operational restrictions.

How does the EU AI Act intersect with cybersecurity obligations?

The EU AI Act — phased implementation running through 2026 and beyond — introduces specific security requirements for AI systems classified as "high-risk." These include requirements for robustness, accuracy, and cybersecurity throughout the AI system's lifecycle. Critically, organisations deploying high-risk AI must maintain detailed technical documentation and demonstrate that their systems are resilient to attempts to alter their behaviour through adversarial manipulation — which is precisely the threat model for prompt injection attacks against agentic AI.

The intersection of AI regulation and cybersecurity obligation is one of the least-discussed areas of compliance complexity, and one of the most practically significant. If you're running autonomous AI in a regulated sector, these frameworks aren't separate workstreams — they're the same workstream.

The cumulative effect of these regulations is that a robust security posture is no longer just risk mitigation — it's a competitive differentiator and a prerequisite for operating in regulated markets. Organisations that treat compliance as a checkbox exercise will find the checkbox has teeth.

What Does "Security by Design" Actually Mean in Practice?

Security by design means embedding security considerations into the architecture of systems from the beginning, rather than bolting them on after deployment. In the context of AI transformation, it means asking security questions at the point of design, not the point of incident response.

In practice, this looks like:

• Threat modelling before deployment: For any new AI system or integration, conducting a structured analysis of what could go wrong, who might attack it, and what the blast radius of a failure would be.
• Security review as part of the AI development lifecycle: Not a sign-off gate at the end, but an ongoing function throughout design, build, and testing.
• Secure-by-default configurations: AI systems should ship with the most restrictive settings as default, requiring deliberate choices to open up permissions — not the reverse.
• Human-in-the-loop for high-stakes actions: Autonomous agents should require human authorisation for actions above a defined risk threshold. Defining that threshold is a governance decision, not a technical one.

The honest reality is that most organisations I've encountered are not doing threat modelling before AI deployment. They're doing it after the first incident, which is a significantly more expensive curriculum.

Frequently Asked Questions

What is the biggest cybersecurity risk of agentic AI specifically?

The most significant risk is over-permissioned service accounts combined with inadequate audit logging. Agentic AI systems need credentials to operate, and those credentials are often configured quickly and reviewed rarely. If an agent's service account is compromised, an attacker gains automated, scalable access to every system that agent can reach — which, in a poorly governed deployment, can be extensive.

Do SMEs need to worry about zero-trust architecture, or is that just for large enterprises?

SMEs are, in many ways, more exposed than large enterprises — not because they face more sophisticated attacks, but because they have fewer resources to detect and respond to them. Zero-trust principles scale down: even a small organisation can implement multi-factor authentication, least-privilege access controls, and basic network segmentation. The principle is universal; the complexity of implementation scales with the size of the environment.

What is prompt injection and how do I protect against it?

Prompt injection is an attack where malicious instructions are embedded in content that an AI agent processes — for example, a document the agent is asked to summarise might contain hidden instructions telling the agent to exfiltrate data or take unauthorised actions. Defences include input validation and sanitisation, sandboxing agent execution environments, limiting the actions agents can take based on their current task context, and monitoring for anomalous agent behaviour patterns.

How often should we be reviewing AI agent permissions?

At minimum, quarterly — but ideally, permissions should be reviewed whenever an agent's function changes, whenever there's a change in the systems it connects to, and as part of any broader access review cycle. The principle of least privilege decays over time as systems evolve; permissions that were appropriate at deployment are often excessive six months later.

Is cybersecurity insurance still viable as a risk transfer strategy?

Cyber insurance remains a legitimate part of a risk management strategy, but insurers have become significantly more rigorous in their underwriting requirements. Most policies now require evidence of specific security controls — MFA, endpoint detection, patch management, and increasingly, AI governance policies. Treating insurance as a substitute for security investment is a strategy that tends to fail at the worst possible moment.

Who owns cybersecurity responsibility in an AI transformation programme?

Formally, the CISO. Practically, everyone involved in the programme, with the board holding ultimate accountability under current regulatory frameworks. The most effective model I've seen is a shared responsibility structure where the security team sets standards and provides tooling, but programme teams are accountable for operating within those standards. Security as a centralised veto is slower and less effective than security as an embedded discipline.

Nicholas Hodder is a digital transformation and technology leadership advisor with over 20 years of experience helping organisations navigate the gap between technology strategy and operational reality. He works with enterprise, public sector, and mission-driven organisations on AI adoption, data governance, and the human dimensions of large-scale change. If your organisation is scaling AI deployments and your security architecture hasn't kept pace, that conversation needs to happen before the architecture makes the decision for you.

Schedule a Digital Security and Architecture Review to assess your current exposure and build a roadmap to a genuinely resilient AI operating environment.