Organizations are rapidly deploying AI agents that can access enterprise data, invoke tools, and execute actions across business systems. Many of these deployments rely on the Model Context Protocol (MCP). While MCP accelerates agent capabilities, it also introduces new attack surfaces that security teams must evaluate before large-scale adoption.

The Securing the Model Context Protocol Summit is designed for security professionals responsible for assessing, approving, and defending AI agent deployments. Attendees will gain practical guidance from OWASP contributors, security researchers, and practitioners actively working to define secure MCP adoption patterns.

Read the agenda and get your tickets!

For Cyber_AI and _secpro subscribers, there is currently a 30% discount too. Make sure you don’t miss out—and see you there!

Key takeaways

• AI cannot compensate for poor telemetry, fragmented systems or weak security processes.

• High-quality, normalised security data is one of the most important foundations of an AI-ready SOC.

• Identity and least privilege become particularly important as AI systems gain access to security infrastructure.

• RAG can turn organisational security documentation, threat intelligence and previous investigations into a searchable knowledge layer.

• The best starting point is usually a narrow, high-volume workflow where AI can demonstrate measurable value.

• AI should reduce repetitive work and extend analyst capabilities rather than replace security expertise.

  ---

Artificial intelligence is increasingly being presented as the answer to many of the problems facing Security Operations Centres. AI can analyse enormous quantities of telemetry, identify unusual behaviour, summarise incidents and help analysts write detection queries. Newer systems can go further, using AI agents to investigate alerts, retrieve information from multiple security platforms and recommend or even execute response actions.

There is a temptation to see this as primarily a technology purchasing exercise. Deploy an AI security platform, connect it to the SIEM and start looking for results. Of course, in practice, it is rarely that simple.

AI does not eliminate the need for good security data, reliable processes or experienced analysts. In fact, the introduction of AI often exposes weaknesses in all three. An organisation with incomplete telemetry, poorly managed identities and inconsistent incident-response procedures will struggle to get reliable results from even the most capable AI system.

Building an AI-ready SOC therefore begins somewhere less exciting than selecting a large language model. It begins by making sure the security operation itself has the foundations required for AI to work effectively.

AI is reshaping quant trading, investment research, risk analytics, fintech infrastructure, and corporate decision systems. This 4-day intensive certification is designed for practitioners who want to build production-grade financial AI agents, not toy prototypes. Design and deploy a portfolio-grade Financial AI Agent architecture for trading, research, and enterprise finance workflows. Work directly with market data, SEC filings, earnings transcripts, etc.; master agentic system design; build applied systems for portfolio analytics, investment research automation, and corporate financial intelligence; and, earn a Packt-endorsed Agentic AI for Finance Certification to validate your applied AI skillset.

If you’re aiming to transition into AI-driven finance roles, quant-adjacent engineering, or applied LLM systems in enterprise environments, this is a high-signal, hands-on program.

Reserve your seat

AI needs something useful to analyse

The most important ingredient in an AI-powered SOC is not the AI, but, rather, the data. Modern security operations already generate enormous amounts of telemetry. Endpoints produce process and network events. Identity platforms record authentication and privilege changes. Cloud environments generate API activity and configuration events. Network infrastructure produces DNS, firewall and proxy data. Applications create their own authentication and operational logs.

AI can potentially correlate all of this information, but only if the information is available, sufficiently complete and presented in a form that the system can understand. Consider an investigation into a suspicious account. An AI system might be able to identify an unusual login from a new location. That becomes considerably more useful if it can also access the user’s normal authentication patterns, device information, VPN activity, endpoint telemetry and recent privilege changes.

If half of that information is missing, the AI has to reason with an incomplete picture. This creates an important distinction between more data and better data. Sending every available log into an AI system does not automatically improve security and, indeed, poorly structured, duplicated, or irrelevant telemetry can increase cost while making investigations harder.

The telemetry foundation

This starts with the conventional security stack. A mature SOC will normally have some combination of SIEM, Endpoint Detection and Response (EDR), Network Detection and Response (NDR), identity monitoring, cloud security and vulnerability-management systems. AI does not necessarily replace these technologies and, instead, it provides another layer capable of connecting information between them.

An analyst investigating a compromised workstation might previously have had to search the EDR platform, then the SIEM, then the identity provider and finally the cloud environment. An AI-assisted investigation can potentially perform those searches automatically and combine the results.

But that only works if the systems are properly integrated. This makes API availability, consistent timestamps, useful metadata and reliable asset identifiers surprisingly important components of an AI strategy. An AI agent cannot correlate events effectively if one platform identifies a machine by hostname, another by IP address and another by an internal asset identifier that nobody has mapped correctly.

Normalisation in practice

Security data rarely arrives in a convenient common format. Different vendors use different terminology and schemas. One platform may describe an authentication event in one way while another uses completely different fields. Cloud providers have their own logging structures, while applications may produce inconsistent custom logs. Traditional SIEM platforms have spent years addressing this problem through parsers, schemas and normalisation.

AI does not make this problem disappear. A large language model can sometimes interpret inconsistent formats surprisingly well, but relying upon this behaviour is not a substitute for structured data. Predictable schemas make correlation, statistical analysis and automated response significantly more reliable.

An AI-ready SOC should therefore treat data normalisation as an architectural requirement rather than an optional optimisation. This is particularly important as organisations move towards autonomous agents. An analyst can often compensate for confusing data because they understand the environment. An automated system has considerably less opportunity to recover from ambiguity.

Centring identity

Identity is another fundamental component of AI-powered security operations. Moving forward from traditional threat hunting, we’re now positioning ourselves to answer the question: “Who was responsible, what were they authorised to do, and what did they subsequently access?”

This requires reliable identity data. User accounts, service accounts, privileged identities, machine identities and application identities all need to be mapped accurately. Privilege changes and authentication events need to be visible to the security operation.

This becomes critical when AI agents themselves are introduced. An AI investigation agent may need access to multiple security platforms. Giving it a powerful shared service account is convenient but potentially dangerous. If that account is compromised, an attacker could inherit the agent’s permissions.

The better approach is to treat AI systems as identities within the security architecture. They should authenticate, receive narrowly defined permissions and have their activity logged. An agent investigating an endpoint might need read access to EDR telemetry but have no ability to modify endpoint configurations. The principle is familiar: least privilege applies to AI too.

Build a security knowledge base

AI-powered security operations also require more than raw telemetry. Security teams possess large amounts of contextual knowledge that is often scattered across documentation, previous incidents, detection rules and individual analysts’ experience.

This might include information about:

• critical systems,

• normal administrative behaviour,

• internal naming conventions,

• known service accounts,

• previous incidents,

• approved software,

• detection logic,

• response procedures,

• threat intelligence,

• vulnerability information.

This information becomes particularly valuable when using Retrieval-Augmented Generation (RAG). Instead of asking an LLM to answer a security question entirely from its general training, a RAG system can retrieve relevant organisational information and provide it as context.

An analyst asking why a particular PowerShell command is suspicious might therefore receive an answer grounded in the organisation’s own investigation procedures and previous incidents. This turns organisational knowledge into something that can be queried rather than something that exists only in documents or inside experienced analysts’ heads.

The process also creates a useful incentive for security teams to improve their documentation. If procedures are poorly documented, AI has less reliable material to retrieve. If the knowledge base is outdated, AI may confidently provide outdated recommendations. AI therefore creates a strong argument for treating security documentation as an operational asset.

Fix the workflow before automating it

There is another common mistake when organisations introduce AI: automating processes that are already inefficient. Suppose an SOC has an incident workflow involving eight manual steps, several of which exist only because two security platforms do not communicate properly. Adding an AI agent on top may make the workflow faster, but it does not necessarily make it better.

The team should first understand what actually happens during an investigation—for example, you might want to use the following as a pro forma to apply in the process:

• Which tasks are repetitive?

• Which require human judgement?

• Which systems are consulted?

• Which decisions require approval?

• Where do analysts regularly have to search for information manually?

• Where do investigations get stuck?

A useful rule is to automate information gathering before decision-making. An AI system can often safely collect logs, retrieve threat intelligence, build timelines and summarise evidence. Deciding whether to disable an executive’s account or isolate a critical production server is a different matter. Keeping those distinctions clear makes AI adoption considerably easier to manage.

Analysts are still king

Building an AI-ready SOC does not mean reducing the importance of analysts. Security professionals regularly perform tasks that are intellectually straightforward but operationally expensive. They search logs, translate queries between platforms, read lengthy threat reports and produce incident documentation.

These are excellent candidates for AI assistance. The analyst can then spend more time asking why an attack occurred, what the adversary was attempting to achieve and whether existing security controls should be improved. This also creates an opportunity for less experienced analysts.

A junior analyst investigating an unfamiliar Windows event can ask an AI assistant for an explanation, potential security implications and suggested investigative queries. A senior analyst can then review the investigation rather than having to perform every preliminary step personally. AI can therefore help organisations distribute expertise more effectively. It does not remove the skills gap, but it can reduce the amount of specialist knowledge required for routine tasks.

AI literacy becomes a SOC skill

The other side of this equation is that analysts need to understand the systems they are using. AI-generated investigation results cannot simply be accepted without question. Models can hallucinate. They can misunderstand ambiguous evidence. They can generate technically valid queries that do not answer the question the analyst actually intended to ask. They may also overstate the significance of an anomaly.

Analysts therefore need enough AI literacy to recognise these limitations. They should understand concepts such as LLMs, embeddings, RAG, model context, prompt injection and AI agents. They should know when an AI-generated answer needs verification and how to provide better investigative context.

At the same time, they need to retain their underlying security skills. Understanding Windows internals, networking, authentication, cloud infrastructure and attacker behaviour remains essential. AI should make those skills more productive, not make them unnecessary.

Start with a narrow problem

Organisations do not need to build an autonomous SOC on day one. A much more sensible approach is to identify one high-volume, reasonably well-understood workflow. Let’s start with the alert triaging:

• An AI system could receive an alert, retrieve relevant endpoint and identity information, search for related events, consult threat intelligence and produce a concise investigation summary.

• An analyst then validates the result and decides whether the alert should be closed, escalated or investigated further.

• This creates a controlled environment for measuring the technology.

• The organisation can determine whether AI actually reduces investigation time, whether analysts trust the results and where errors occur.

The same approach can then be extended to other workflows. Threat intelligence processing, phishing analysis, malware triage, detection engineering and incident documentation are all potential candidates. The important thing is to demonstrate measurable value before increasing autonomy.

Measuring whether AI is helping

AI projects can easily become difficult to evaluate because impressive demonstrations do not necessarily translate into operational improvements.

A security team should therefore establish a baseline before introducing AI.

• How long does an analyst currently spend investigating an alert?

• How many alerts can the team process?

• How frequently are false positives escalated?

• How long does it take to produce an incident report?

• How many proactive hunts can the team complete each month?

These measurements can then be compared after AI is introduced. The goal should not simply be reducing the number of human hours spent on security. If AI reduces investigation time by 50 per cent but produces unreliable conclusions that analysts must constantly correct, the apparent efficiency gain is misleading.

A better measure is whether the organisation can investigate more activity, more accurately, without proportionally increasing its workforce. That is the real promise of an AI-ready SOC.

The foundation comes first

Artificial intelligence can make security operations significantly easier. It can reduce repetitive work, accelerate investigations and allow analysts to examine relationships across datasets that would be impractical to process manually.

But those benefits depend upon the environment surrounding the AI. The foundations are less exciting than an autonomous AI agent investigating an attack, but they are considerably more important.

An organisation that gets these fundamentals right is in a much stronger position to introduce increasingly sophisticated AI capabilities. That is the subject of the next article in this series: building the AI security operations stack, and understanding how telemetry, knowledge, models, agents and automated response can be connected into a coherent security architecture.