Every enterprise wants the upside of AI — faster workflows, sharper decisions, leaner teams. Far fewer have asked the harder question: what happens when the same systems delivering that upside are also quietly rewriting who, or what, has access to the crown jewels? Autonomous agents are now reading contracts, touching customer data, writing production code, and triggering workflows once reserved for trusted employees. The attack surface hasn't just grown — it's changed shape entirely. Mohammad Arif, Head of Information Security at Guild Group, has been on the front line of that shift, helping enterprise leaders separate genuine AI-driven cyber risk from the noise around it. In this interview with The Cyber Express, he makes the case that AI security isn't a niche technical concern to be handed off to a working group — it's a boardroom issue, sitting at the intersection of data protection, vendor risk, identity, and human accountability. His warning is blunt: organisations still treating AI security as tomorrow's problem are already behind, and the cost of catching up only rises from here.

The Cyber Expres: Everyone is talking about AI productivity. From a security leadership perspective, what is the biggest shift AI is creating for enterprises?

From a security leadership perspective, the biggest shift is that AI is changing the enterprise trust model. It is no longer only about protecting systems, networks, and users. Organisations now need to consider what AI can access, what data it can process, what decisions it may influence, and what actions it may trigger. AI can significantly improve productivity, cyber defence, and business decision-making. But the risk increases when adoption moves faster than governance. If AI tools are connected to sensitive data, enterprise workflows, identity systems, APIs, or business processes without clear controls, the risk is no longer just a technology issue. It becomes a data, privacy, operational resilience, and trust issue. So the real shift is this: AI is not just another productivity tool. It is becoming part of the enterprise operating model, and therefore it needs to be governed and secured like any other critical capability.

The Cyber Express: What worries you most about the current pace of AI adoption across organisations?

What worries me most is the gap between the speed of AI adoption and the maturity of AI governance. Many organisations are moving quickly to unlock productivity benefits, but they may not yet have clear rules around approved use cases, sensitive data handling, vendor assurance, retention of information, model outputs, and human accountability. The immediate risk is uncontrolled or "shadow" AI adoption, where employees or teams use public or unapproved AI tools without understanding what data is being entered, how that data may be retained, or whether it could be used to improve external models. This can create confidentiality, privacy, intellectual property, and regulatory risks. The challenge for enterprises is not to slow down innovation unnecessarily. The challenge is to enable AI safely — giving employees approved pathways to use AI, while putting the right controls around data protection, access, monitoring, and risk-based governance.

The Cyber Express: At what point does AI stop being just a productivity tool and become a real enterprise security challenge?

AI becomes a real enterprise security challenge when it moves from simply generating content to being connected to enterprise data, identity, applications, APIs, tools, and workflows. A standalone AI assistant used for drafting general content has a different risk profile from an AI agent that can access customer information, analyse internal documents, write code, trigger workflows, or make recommendations that people rely on. The risk increases further when AI has autonomy, can call external tools, or can operate across multiple systems. This is where agentic AI becomes important. The question is no longer only "what can the model say?" It becomes "what can the AI access, what can it do, and who is accountable for the outcome?" That is the point where traditional security controls need to extend into AI governance, identity, permissions, logging, monitoring, and human oversight.

The Cyber Express: Do you think most organisations are prepared for AI-driven cyber threats, or are many still treating AI security as a future problem?

Preparedness varies significantly. Some organisations are taking AI security seriously and are building governance, security review, data protection, and monitoring into their AI adoption programs. But many are still treating AI security as a future problem, even though AI is already inside the enterprise through productivity tools, SaaS platforms, coding assistants, analytics tools, third-party services, and employee-led experimentation. The issue is that AI adoption is often decentralised. It may start in business teams, technology teams, vendors, or individual users before the organisation has a complete view of the risks. That means security leaders need to shift from reactive control to proactive enablement. AI security readiness should include clear acceptable-use guidance, approved tools, data classification, vendor due diligence, secure development practices, incident response scenarios, awareness training, and monitoring. Without those foundations, organisations may not know where AI is being used, what data is exposed, or where the risk is accumulating.

The Cyber Express: What AI-related security incidents do you realistically expect enterprises to face over the next 12 months?

Over the next 12 months, I expect most enterprises to see AI-related incidents in a few practical areas. The first is AI-assisted social engineering. Phishing, impersonation, business email compromise, and executive fraud will become more convincing because AI allows attackers to generate personalised and credible content at scale. The second is sensitive data leakage into AI tools, which may happen when employees enter confidential business information, customer data, source code, contracts, security information, or internal documents into tools that have not been approved or assessed. The third is insecure AI integration. As teams connect AI to internal knowledge bases, applications, plugins, and workflows, weaknesses such as prompt injection, excessive permissions, poor output validation, or weak monitoring may create new attack paths. The fourth is AI supply-chain risk. Organisations increasingly rely on third-party models, APIs, datasets, plugins, open-source components, and AI-enabled SaaS platforms — each introducing dependencies that need to be assessed and monitored. So the threat is not one single scenario. It is an expanded attack surface across people, data, applications, vendors, and business processes.

The Cyber Express: AI-generated phishing and deepfakes are receiving significant attention. Have these threats become genuinely dangerous, or are they still more hype than reality?

They are genuinely dangerous, but the risk needs to be understood properly. The concern is not only that AI can create fake emails, voices, images, or videos. The bigger issue is that AI reduces the effort required to create believable, personalised, and scalable deception. Traditional phishing often had indicators such as poor grammar, generic wording, or obvious formatting issues. AI reduces those indicators. Attackers can tailor messages to specific roles, business processes, recent events, or organisational language. Deepfakes also create risk where organisations rely heavily on voice, video, or informal executive instructions for approvals or sensitive actions. This does not mean every organisation will face sophisticated deepfake attacks immediately. But it does mean that trust-based processes need to be strengthened. Payment approvals, changes to bank details, privileged access requests, sensitive data transfers, and executive instructions should have strong verification controls that do not rely on one communication channel alone.

The Cyber Express: Do enterprises fully understand the risks of feeding sensitive data, business context, or internal information into frontier AI systems?

Not always. Many organisations understand the general concern, but they may not fully understand the practical ways sensitive information can be exposed through AI usage. The risk is broader than simply entering customer data into a public tool. Employees may enter internal strategies, contracts, security designs, source code, incident information, board papers, commercial terms, or confidential business context. Even if the data is not used for model training, there may still be risks around retention, access, logging, jurisdiction, vendor terms, and downstream use. Enterprises need to apply the same discipline to AI that they apply to other sensitive platforms — understanding what data is allowed, which tools are approved, whether enterprise-grade privacy and security settings are enabled, how data is retained, and whether the vendor's contractual terms align with the organisation's obligations. The practical starting point is data classification. If organisations do not know what data is sensitive, they cannot consistently govern how that data should or should not be used with AI.

The Cyber Express: We have seen supply-chain attacks target software and open-source ecosystems. Could AI models, tools, plugins, agents, datasets, and integrations become the next major supply-chain risk?

Yes, AI supply-chain risk is likely to become a major area of focus. In traditional technology environments, organisations already assess software vendors, cloud providers, managed service providers, open-source libraries, and third-party integrations. AI expands that supply chain. The AI supply chain can include foundation models, fine-tuned models, datasets, model providers, APIs, plugins, orchestration platforms, vector databases, prompt libraries, AI coding tools, agent frameworks, and embedded AI features in SaaS products. A weakness or compromise in any of these areas can affect the confidentiality, integrity, or reliability of AI-enabled systems. A poorly governed dataset could introduce bias or inaccurate outputs. A vulnerable plugin could expose data. A compromised package could affect an AI-enabled application. An over-permissioned AI agent could access more information than it needs. These are not only technical risks; they are third-party, operational, and governance risks. Enterprises should therefore treat AI supply-chain assurance as part of broader cyber risk and vendor risk management, including due diligence, contractual controls, security testing, data protection review, monitoring, and clear accountability between the organisation and its providers.

The Cyber Express: How should security leaders rethink traditional cybersecurity strategies in a world where AI can write code, analyse vulnerabilities, automate tasks, and support attackers as well as defenders?

Security leaders should not abandon traditional cybersecurity principles. Instead, they need to extend them into AI-enabled environments. Identity and access management remains critical, but now we need to consider identities and permissions associated with AI agents, service accounts, APIs, and automated workflows. Data protection remains critical, but now we need to monitor prompts, outputs, embeddings, and knowledge retrieval systems. Secure development remains critical, but now we need to assess AI-generated code, model behaviour, prompt injection risks, and third-party AI components. The same applies to monitoring and incident response. Security teams need visibility into AI usage, unusual activity, sensitive data exposure, misuse of AI tools, and unexpected agent behaviour. Incident response plans also need to consider AI-specific scenarios such as data leakage through AI platforms, compromise of AI integrations, prompt injection, poisoned data, or misuse of AI-generated code. The key point is that AI security should not sit outside the cybersecurity operating model. It should be integrated into governance, architecture, procurement, engineering, monitoring, awareness, and incident response.

The Cyber Express: Are existing cybersecurity teams equipped to handle AI-era threats, or does the industry need new skills and operating models?

Existing cybersecurity skills remain highly relevant, but they need to be expanded. The fundamentals still matter: identity, data protection, secure architecture, vulnerability management, incident response, third-party risk, and governance. However, AI introduces new concepts that security teams need to understand. Security professionals now need AI literacy — how large language models work at a practical level, how AI applications are integrated, how prompts and outputs can be manipulated, how retrieval-augmented generation works, how AI agents interact with tools, and how AI supply chains are structured. The operating model also needs to evolve. AI security cannot be owned by security alone. It requires collaboration between cybersecurity, technology, data, privacy, legal, risk, procurement, HR, and business teams. In many organisations, the most effective model will be a cross-functional AI governance group supported by security-by-design processes. So yes, the industry needs new skills, but not at the expense of existing cybersecurity disciplines. The future is a combination of traditional cyber expertise, AI literacy, risk management, and business enablement.

The Cyber Express: AI vendors promise speed, scale, and automation. Where should organisations avoid over-relying on AI in cybersecurity and business decision-making?

Organisations should avoid over-relying on AI in areas where decisions are high-impact, sensitive, difficult to reverse, or require strong judgement. AI can assist, but accountability should remain human. In cybersecurity, this includes incident severity decisions, containment actions, identity and privileged access approvals, regulatory interpretation, legal assessments, and decisions that could materially affect customers, employees, or critical operations. AI can help summarise information, detect patterns, prioritise alerts, and recommend actions, but those recommendations should be validated by qualified people. There is also a risk of automation bias, where people trust AI outputs because they appear confident or well-structured. That can be dangerous if the output is incomplete, inaccurate, or based on weak context. Organisations need clear rules for where AI can automate, where it can recommend, and where human approval is mandatory. A practical principle is this: the greater the potential impact, the stronger the need for human oversight, auditability, and accountability.

The Cyber Express: If you were advising enterprise leaders today, what are the first three things they should do to prepare for the security impact of frontier AI models?

The first priority is to establish AI governance. Organisations need clear policies on approved use cases, acceptable tools, data handling, human oversight, and accountability. Governance should not be theoretical — it needs to be embedded into procurement, technology delivery, data management, security review, and business processes. The second priority is to protect sensitive data before scaling AI adoption. This means strengthening data classification, access controls, data-loss prevention, retention rules, and monitoring. Enterprises should know what data can be used with AI, under what conditions, and through which approved platforms. The third priority is to integrate AI into the cyber risk management operating model — including third-party risk assessments, threat modelling, secure development, incident response, employee awareness, logging, monitoring, and assurance activities. Security teams should also start preparing for AI-specific risks such as prompt injection, insecure integrations, sensitive data exposure, excessive agency, and AI supply-chain compromise. AI can create significant value, but only if organisations adopt it with discipline. The organisations that treat AI security as a future issue may already be behind.

"AI adoption without governance is not innovation — it is unmanaged risk. The next phase of enterprise security is about controlling what AI can access, what it can do, and who remains accountable." — Mohammad Arif, Head of Information Security, Guild Group

As enterprises race to bolt AI onto every business process, security leaders are being forced to answer a harder question than "should we adopt it" — it's "who's accountable when it goes wrong." To unpack this, The Cyber Express sat down with Harsha Reddy, Head of Information Security at Veterinary Emergency Group (VEG).

With nearly two decades in security leadership — including senior roles at Lixil and American Standard before joining VEG — Harsha brings a practitioner's view of where AI is genuinely changing the CISO's job, and where it's mostly just hype and shadow adoption.

Watch the Full Interview:

Harsha Reddy Explains Why AI Will Replace Tasks, Not Defenders

Harsha pushes back on the narrative that AI will hollow out security teams, pointing to Gartner research showing that while most fields are projected to lose jobs to AI, cybersecurity is expected to gain them. In his view, the technology is mainly absorbing the "toil" — log review, alert triage, evidence gathering — that keeps analysts from actually defending.

Also listen to S1 Episode: Awareness and Education at Young Age is the Answer to Cybersecurity Skill Gap

“It's the analyst who refuses to use AI that will get replaced by an analyst who uses it,” he says.

On adoption, Reddy points to a 2024 Microsoft-LinkedIn survey in which most executives called AI critical to their business, yet a majority had no formal plan and most had employees already bringing in their own tools. That gap, he argues, is why so many organizations are now dealing with AI-related data leaks. "Many organizations started onboarding AI like software when they should be onboarding it like staff." His fix isn't more restrictions — blocking AI just pushes it into the shadows — but guardrails, an internal AI enablement committee, and measuring actual business value instead of token consumption.

The conversation also digs into deepfake-driven fraud, why training employees to spot deepfakes is “a losing bet” at machine speed, and how he decides when to greenlight a new AI tool versus telling a business unit “not yet.”

The conversation closes with our newly introduced rapid-fire round "Express Shots" — Claude vs. ChatGPT, passkeys vs. passwords, and Reddy's prediction for the biggest cybersecurity threat of 2030.

💾

The convergence of SRE and Security Engineering is reshaping how organizations build, operate, and protect modern cloud environments. As infrastructure grows more complex and distributed, reliability, security, identity management, and observability are becoming increasingly interconnected disciplines rather than separate functions.

Advait Patel, Senior Site Reliability Engineer at Broadcom and author of DockSec, has witnessed this shift firsthand. With experience spanning cloud infrastructure, DevSecOps, and observability platforms such as Wavefront (Tanzu Observability), he has worked on systems processing more than 10 million data points per second while leading initiatives in IAM, cloud migration, and security engineering.

In this interview, Patel shares his insights on securing observability platforms at scale, managing identity across multi-cloud environments, balancing automation with human oversight, and the role AI is playing in the future of DevSecOps and incident response.

Advait Patel Breaks Down SRE and Security Engineering 

TCE: How are you seeing SRE and security engineering converge in modern cloud environments? 

Advait Patel: The short version is that the failure modes started overlapping and the org charts are catching up. A misconfigured IAM policy that takes down a service and a misconfigured IAM policy that exposes data are usually the same mistake. SREs already own the deployment pipeline, the observability stack, and the incident process, which happen to be the three places security has to live if it wants to be effective instead of decorative.  What changed it for me was security as code. When I ran the zero-downtime migration of our observability platform from AWS to GCP, security could not be a review step bolted on at the end. It had to be expressed the same way reliability was, as policy in the pipeline, with the same testing and the same rollback story.   That is the real convergence. Not security and SRE attending the same standup, but security becoming something you can measure and enforce the way you measure latency or error rate. We are not all the way there as an industry. Plenty of shops still treat security as a gate at the end. But the teams moving fastest have stopped pretending the two disciplines are separate. 

TCE: What are the biggest challenges in securing large-scale observability platforms handling high-volume data streams? 

Advait Patel: This one is close to home, since I spent a long time on a platform ingesting north of 10 million data points per second. A few things make it genuinely hard.  First, telemetry is one of the most underrated attack surfaces in a company. Your metrics, traces, and logs describe your entire architecture. Get read access to that and you do not need to break into anything, the map is already drawn for you. And secrets leak into logs constantly. Someone logs a full request, the token rides along with it, and now your observability store is a credential store you never meant to build.  Second, at that volume you cannot inspect everything inline. Any control you add has to be cheap or it becomes the exact bottleneck you were hired to prevent. That single constraint rules out a lot of textbook advice.  Third is tenant isolation. When many teams share one pipeline, one team seeing another team's data is both a security incident and a trust failure at once. Getting that right without wrecking throughput was one of the harder problems in that migration. 

TCE: How do you approach identity and access management (IAM/CIAM/WIAM) in multi-cloud architectures? 

Advait Patel: I have spent enough time here to have written a couple of books on identity in the cloud, and the honest summary is that multi-cloud IAM is hard mostly because the providers disagree with each other. AWS, GCP, and Azure each have a different mental model for what an identity even is and how permissions attach to it. The abstractions do not map cleanly, so anyone selling you one tidy policy language across all three is usually hiding the seams.  The part I am most interested in right now is workload identity. For years, we secured machines the same way we secured people, with long-lived static credentials sitting in config files waiting to leak. That model is finally dying. Short-lived, attested identities through approaches like SPIFFE and workload identity federation are a much better answer, because the credential expires before an attacker can do much with it.  For human and customer identity, the rules are simpler, but the stakes are higher. Kill static keys, federate to one source of truth, and treat access review as something continuous rather than an annual audit nobody reads. Entitlement creep is the quiet killer here. People accumulate access and almost never lose it. 

TCE: What role do you see AI playing in improving reliability and security operations (AIOps/DevSecOps)? 

Advait Patel: I will give you the unfashionable version. AI is genuinely good at one specific thing in security operations and oversold at most of the rest.  The thing it is good at is the layer between detection and action. You run a scan, you get 200 findings, and historically, a human burns half a day working out which three actually matter for their system. AI is very good at that triage and at explaining a finding in the context of your specific setup. That is most of the real value, and it is the whole reason I built DockSec the way I did.  Where it gets oversold is autonomous action in production and the idea that it replaces the analyst. It does not. The right pattern is AI sitting on top of deterministic signals, not in place of them. A coding assistant telling you a Dockerfile looks fine does not survive an auditor's first question. You still need the scanner underneath and the human judgment on top.  And there is a twist people forget. AI is also a new attack surface. Agentic systems can be manipulated through their own inputs in ways we are only starting to score properly, which is part of why I put time into AI-specific vulnerability scoring. We are adding capability and risk in the same motion. 

TCE: How can teams balance automation with human oversight in incident response? 

Advait Patel: My rule of thumb is to automate the reversible and the boring and keep humans on the irreversible and the ambiguous.  Automation is excellent at the parts of incident response that are well understood and repetitive. Detect a known pattern, enrich it, page the right person, contain something you have contained a hundred times.   That should all run at machine speed. Where I get nervous is letting automation take actions with real blast radius on its own, because automation fails confidently and at scale. A human making a bad call breaks one thing. A bad automated remediation can take the whole fleet down before anyone has read the alert.  So I think of it as trust earned in increments. New automation runs in suggest mode first, where it only tells you what it would have done. Once it has been right enough times on low-risk actions, you let it act on those, and you keep the high-consequence decisions with a person. The piece people skip is the after. Humans own the retro and the learning. You do not automate understanding why it broke. 

TCE: What are the most important security practices for containerized environments today? 

Advait Patel: A few that matter more than the rest.  Start small. Minimal base images and multi-stage builds do more for your posture than almost any tool you can buy, because you cannot be vulnerable to something that is not in your image. Most containers ship with a full operating system that they never touch.  Do not run as root, and drop the capabilities you do not need. It is basic, and people still skip it.  Care about provenance. Sign your images, generate an SBOM, and know where your base layers came from, because you inherit every vulnerability in them, whether you wrote that code or not. The supply chain is where the interesting attacks are now.  But the practice I would push hardest is making your scanning actionable. A report with 200 CVEs that nobody can act on is security theater. The problem most teams actually have is not detection, it is prioritization and remediation. Coverage without a path to a fix just manufactures guilt. Closing that gap between found and fixed is what genuinely moves your risk down, and it is the problem I have spent the most time on. 

Conclusion

From securing observability platforms handling millions of data points per second to managing identity across multi-cloud environments, Advait Patel's experience highlights the practical challenges facing today's infrastructure teams. His views on automation, AI, incident response, and container security reinforce a common theme throughout the discussion: the growing overlap between SRE and Security Engineering.

As organizations continue to modernize their cloud environments, the ability to balance reliability, security, and operational efficiency will become increasingly important. For teams navigating that shift, Patel's insights offer a grounded perspective on what it takes to build and secure systems at scale.