|
 |
 |
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.
For Cyber_AI and _secpro subscribers, there is currently a 30% discount too. Make sure you don’t miss out—and see you there!
In the first article in this series, we examined the foundations required before an organisation can make effective use of artificial intelligence in a Security Operations Centre. Reliable telemetry, structured data, accurate identity information and well-defined workflows are not particularly exciting technologies, but they have a direct influence on the quality of any AI-assisted security operation.
The next challenge is architectural: an AI-ready SOC is not simply a SIEM with a chatbot attached to it. It is a collection of interconnected systems in which AI can consume security telemetry, retrieve organisational knowledge, analyse evidence and, where appropriate, initiate actions through existing security platforms. The important question is therefore not which AI product an organisation should buy, but how AI capabilities should fit into the security architecture that already exists.
A useful way to understand this architecture is to divide it into several layers: data, knowledge, intelligence, agents, action and governance. These layers have different responsibilities, but they are interdependent. Weaknesses in one layer can constrain the effectiveness of everything above it.
The data layer
Everything starts with security telemetry. The data layer contains the systems that observe activity across the organisation, including SIEM platforms, Endpoint Detection and Response (EDR), Network Detection and Response (NDR), identity providers, cloud platforms, vulnerability-management systems, firewalls, DNS infrastructure and application logs.
Traditional security operations have generally required analysts to move between these systems during an investigation. An analyst investigating a compromised workstation might search the EDR platform for suspicious processes, query the SIEM for related events, examine authentication records and then investigate activity in the relevant cloud environment. AI can reduce the amount of manual searching involved by querying multiple sources and correlating their results.
Consider an alert indicating that a user has authenticated from an unusual location. The authentication event alone may be relatively weak evidence, of course, and possibly not something that we would use in isolation to launch a fuller investigation. An AI-assisted investigation could retrieve the user’s normal authentication patterns, identify the device involved, examine VPN activity, inspect endpoint events and search for unusual access to cloud resources. The value comes from combining those pieces of information into a coherent investigative context.
This depends heavily on the quality of the underlying data. APIs, timestamps, schemas, asset identifiers and retention policies become important parts of AI security architecture because an AI system cannot reliably correlate events that cannot be consistently associated with users, devices or applications. The data layer therefore needs to be treated as infrastructure rather than simply as a source of logs.
Data normalisation and context
Security telemetry rarely arrives in a common format. Different vendors use different schemas and terminology, while cloud providers and internally developed applications frequently introduce additional variations. SIEM platforms have traditionally addressed this through parsers and normalisation schemes, allowing analysts and detection rules to work with a more consistent representation of events.
AI does not eliminate this requirement. Although a large language model may be able to interpret several different log formats, that capability should not be treated as a replacement for structured data—obviously! Predictable schemas make correlation, statistical analysis and automated response more reliable, while consistent identifiers allow events from different systems to be associated with the same entity.
This becomes increasingly important as AI systems become more autonomous. An experienced analyst can often resolve an ambiguous hostname or recognise that two identifiers refer to the same system. An automated agent has much less opportunity to compensate for poor data engineering. Organisations considering AI-powered security operations should therefore treat normalisation and entity resolution as part of the architecture, rather than assuming that the AI layer will solve these problems.