|
 |
SentinelOne's Securing AI Bootcamp: Sept 29-30, Virtual Event. Earn CPEs. Zero Cost.
 |
Join thousands of security practitioners in this two-day bootcamp combining expert keynotes with hands-on technical workshops.
Featured Speaker: Corey Quinn, Chief Cloud Economist, Duckbill
Corey hosts the Screaming in the Cloud and AWS Morning Brief podcasts and writes Artificial Confidence, the AI expository newsletter your CTO forwards you. Corey’s keynote “Lies My Agent Told Me” walks through the lies practitioners get told (and tell themselves) and what’s left once you outgrow the suspension of disbelief.
The first two articles in this series looked at what organisations need before introducing artificial intelligence into security operations, and then at how those capabilities can be assembled into a practical SOC architecture. Good telemetry, reliable identity information, useful internal documentation and well-defined workflows provide the foundation. From there, organisations can connect AI models and agents to SIEM, EDR, identity, threat-intelligence and orchestration systems, allowing machines to take on an increasing amount of investigative work.
That architecture introduces an important complication. Once an AI system can access security telemetry, internal documentation and operational tooling, it becomes part of the organisation’s attack surface. The risks become particularly significant when an agent can do more than analyse information and is given the ability to take action.
Securing an AI-enabled SOC therefore involves more than selecting an accurate model. Security teams need to understand what the system can access, which information it trusts, what actions it is authorised to perform and how its decisions can be examined afterwards. Much of the required thinking will be familiar to experienced security professionals, but AI introduces some unfamiliar failure modes that need to be considered alongside conventional application and infrastructure security.
 |
The Claude Code Security Summit takes place online on 25 September and focuses on the security implications of AI coding agents as they move beyond code completion. Across six hours of practitioner-led sessions, the event will examine how teams can define security requirements, test AI-generated applications, manage coding-agent and MCP trust boundaries, and establish appropriate human approval points. The programme includes Jim Manico, Vandana Verma, Katie Paxton-Fear and Michael Shost, bringing together perspectives from secure development, application security, ethical hacking and enterprise governance.
The sessions are aimed at developers, AppSec and product security teams, DevSecOps practitioners, security engineers and technical leaders working with Claude Code or other coding agents. Rather than concentrating on prompting techniques, the summit looks at the controls surrounding AI-assisted development, including SECURITY.md and CLAUDE.md, adversarial testing, MCP trust boundaries, least-privilege access and production approval. There will also be live demonstrations covering the process from generating code through attacking, remediating and validating it. _secpro readers can register using code SECPRO30.
The AI becomes part of the attack surface
Traditional security architecture generally assumes that software will behave according to defined logic. An application accepts an input, processes it and produces an output, with developers and security teams able to test those pathways against known conditions. AI systems introduce considerably more variability because the same underlying model can produce different results depending on the information and context supplied to it.
That does not make AI inherently insecure, but it does mean that the model cannot be treated as the security boundary. An LLM might misunderstand an instruction, follow an unintended line of reasoning or give too much weight to information that should have been treated as untrusted. An agent can compound the problem by turning that interpretation into a tool call or operational action.
The surrounding application therefore has to provide the controls that the model itself cannot reliably provide. Tool permissions, a