Secure your first AI application. Then the next hundred. Most AI security guidance focuses on protecting a single application. Real-world AI deployments aren’t simple. Organizations quickly go from securing one AI app to managing dozens, and before long, autonomous agents that reason, use tools, and take action on their own. And with organizations still struggling with web application and API security, both genAI and agentic AI add significant complexity. This webinar introduces a practical 30-60-90 day framework for evolving your AI security program from a single application to an enterprise AI ecosystem and autonomous agents. You'll leave with a blueprint for building a repeatable AI security program that scales with your organization's AI ambitions.

AI is accelerating cyberattacks, enabling adversaries to move from reconnaissance to exploitation faster than ever. Yet many organizations still rely on historical threat intelligence, leaving security teams reacting to risks that have already emerged. This session explores how CISOs can leverage real-time Internet visibility and predictive intelligence to anticipate threats, prioritize risk, and strengthen security operations. 

Key Takeaways: 

• Identify emerging threats and adversary activity before attacks unfold 
• Improve risk prioritization and maximize existing security investments through real-time visibility 
• Use automation to accelerate response and scale security teams without adding headcount

At 5PM ET on a Friday, your security lead tells you a backdoored NPM package may have been merged into production. Do you notify customers? The SEC? Your insurance provider? Is this an insider?

This session walks through a real-world supply chain breach that included post-exploitation payloads using AI, showing why proof matters more now than ever. Attendees will learn how to:

• Trace a supply chain compromise from NPM, to a developer's laptop, through CI/CD into production and the AI agents running there
• Add a prove function to the NIST framework by mapping every action to the originating identity, whether AI, human, non-human, or third party
• Determine whether an event is an incident, how quickly you can know, and who you need to contact and when

We’re now taking a break!

Take this opportunity to visit the Exhibit Hall and explore our sponsors’ resources, solutions, and latest insights. Their subject matter experts are available now and ready to answer your questions and connect with you. Be sure to stop by before the next session begins!

AI has produced no shortage of demos, claims, and new terminology. But after the initial wave of experimentation, TPRM teams need a more useful conversation: What is actually working? Where is AI improving the process? And where is it simply adding another layer of complexity and cost, when workflow automation could get the job done just as well? 

This session shares practical lessons from applying a Hybrid AI approach across the third-party risk lifecycle. Hybrid AI introduces a realistic way of adopting AI that includes giving AI a clearly defined job, grounding it in reliable evidence, keeping it inside a governed workflow, and being deliberate about where human review belongs. We’ll look at the use cases delivering real value at companies today, the ones that remain more gimmick than solution, and the pros and cons of using AI vs. traditional workflow automation.  

We’ll also make the case that subject-matter expertise matters more, not less, as AI becomes more capable. AI can gather evidence, summarize documentation, and help teams work through larger portfolios. It cannot decide what good risk management looks like on its own. The strongest results come from combining AI with risk expertise, established processes, and a clear record of how conclusions were reached. 

Attendees will leave with a practical view of what AI can do well in TPRM today, what still requires caution, and how to build on those lessons as the technology evolves. 

AI is not creating entirely new cyber risks; it is changing the speed and economics of familiar attacks. For CISOs, the challenge is no longer simply managing more vulnerabilities. It is knowing which exposures could materially affect the business, where to direct limited resources, and whether risk is actually declining. In this session, Maril Vernon will explore how to move from fragmented findings and activity metrics to evidence-based decisions grounded in validated attack paths. A seemingly low-priority credential weakness that enabled domain-admin access in under an hour illustrates why business impact can differ sharply from severity scores. She will discuss how continuous validation can test assumptions, confirm whether remediation changes attacker outcomes, and give leaders a clearer view of progress.

We model threats against our networks with rigor, then ignore the most predictable failure mode in the building: the exhausted human holding the pager. Burnout is not a wellness footnote. It is dwell time, alert fatigue, missed signals, and attrition that walks institutional knowledge out the door. In this session I draw on nearly thirty years in security operations and on validated instruments like the Maslach Burnout Inventory to show how to treat burnout as measurable operational risk. You will see how to baseline fatigue across a SOC, spot the leading indicators before resignation letters arrive, and build prevention into staffing, on-call, and incident response rather than bolting it on after a crisis. The goal is a security program that stays sharp under sustained pressure, because resilient systems depend on resilient people.

Learning objectives for attendees:

1. Frame burnout as quantifiable operational risk tied directly to detection, response, and retention outcomes.
2. Baseline and track fatigue across a security team without invasive surveillance.
3. Identify the leading indicators of burnout early enough to intervene.
4. Build prevention into on-call rotations, staffing, and incident response playbooks, with board-ready language to fund it.

Most talks on the EU Cyber Resilience Act (CRA) are about manufacturers. This one is for the buyer.

Since 11 September 2026, manufacturers selling products with digital elements on the EU market must send an early warning within 24 hours of becoming aware of an actively exploited vulnerability in their product. This also applies to products placed on the market before that date, and manufacturers must inform affected users. Products placed on the market from 11 December 2027 must also meet security requirements. Their manufacturers must tell buyers at the point of sale how long they will receive security updates, and provide those updates free of charge during that period, unless a business buyer agrees otherwise for a tailor-made product.

Some things you used to negotiate are now law. Others are not, and that is where buyers often get it wrong. Many assume suppliers must hand over a full SBOM. They do not: manufacturers must keep one, but sharing it with users is optional. Many also assume the new legislation creates a right for businesses to recover their own losses from suppliers. It does not. Liability between buyer and supplier remains primarily a matter of contract and national law.

I work with manufacturers on their CRA obligations, and this session ends with a one-page checklist: what the law now gives you, when each obligation applies, and what you still need to put in the contract.

Coming soon!

AI is moving beyond copilots and chatbots into connected systems that can retrieve data, call tools, interact with APIs, and operate across enterprise workflows, creating a new runtime attack surface. This session explores the security risks behind today’s most urgent AI trends, including prompt injection, excessive agency, unauthorized tool use, insecure MCP servers, RAG and agentic workflow abuse, harmful outputs, and sensitive data exposure. Attendees will learn how F5 AI Guardrails, F5 AI Red Team, runtime policy enforcement, and AI security integrations help organizations test, govern, and protect AI apps, models, agents, tools, APIs, and data before autonomous AI becomes a business risk.

Workday’s CTO recently showed a custom MCP returned job requisitions its user had no business seeing, then moved the wrong employees between teams with no approval required. Nothing was hacked. No CVE was filed. The wiring simply allowed too much. In this session, Said Syed puts his own thesis on trial: that AI hasn’t invented new attacks, just put old ones on a machine-speed clock. He cross-examines nine AI security disclosures from a single week in October 2026, sorting what’s old, what’s new, and what no vulnerability database can see. He then introduces the REC score (reachability, exploitability, chainability), a new model for scoring potential attack paths instead of individual bugs. You’ll leave with a verdict on where the thesis holds, where it breaks, and six moves to make now.

As AI speeds up development, teams can add dependencies faster than they can review them. Attackers exploit that gap with malicious packages disguised as familiar components, plugins, and developer tools. Sonatype logged 149,329 malicious packages in Q3 2026, about 1,600 a day, bringing the total tracked since 2017 to nearly 2 million. In this session, we’ll examine how those attack chains unfold, including a malicious PyPI package published by an AI agent and the Mini Shai-Hulud campaign’s use of stolen npm credentials to republish compromised packages. You’ll learn practical ways to prevent malicious components from executing, detect suspicious behavior, limit credential exposure, and investigate what happened after a package entered your environment.

We’re now taking a break!

Take this opportunity to visit the Exhibit Hall and explore our sponsors’ resources, solutions, and latest insights. Their subject matter experts are available now and ready to answer your questions and connect with you. Be sure to stop by before the next session begins!

Coming soon!

An AI agent can have permission to read sensitive information, change records or trigger a business workflow. But when it does something it shouldn’t, the organization still needs a human who can explain what happened—and take responsibility.

“An agent without a clearly defined purpose is just a credential with better branding,” says Stephen Garcia, CISO at BreachRx. His argument is straightforward: treat agents as non-human identities, with defined responsibilities and limited authority, rather than treating AI accountability as something a policy document can settle.

In this session, Stephen will work through four questions CISOs should ask before an agent goes live: Can we name the actor? Is its authority bounded? Can we reconstruct what it did? And is a specific person or team accountable for it?

He’ll use those questions to examine everyday governance decisions: why an agent built to read information should not have write access, what teams need to record to understand an agent’s actions, and how ownership should carry through changes to its configuration and permissions.

The discussion will also address what happens when AI participates in incident response. If an agent gives incorrect advice or takes an inappropriate action, teams need to understand who configured it, who approved its authority and who is responsible for the response.

Attendees will leave with a four-question review framework they can use to challenge deployment decisions, identify gaps in ownership and bring security, AI and business teams into a more concrete conversation about accountability.

Learning objectives

After this session, attendees will be able to:

- Use four questions to assess an agent’s identity, permissions, auditability and human ownership.

- Identify where an agent’s access exceeds its stated purpose.

- Define the records and ownership information needed to reconstruct an agent-related incident.

- Apply the framework to AI used in incident response, including responsibility for configuration, advice and actions.

After February 2022, the security operations center of Kyiv's municipal cybersecurity enterprise had two problems at the same time. Attacks grew, from massive DDoS on the city's digital services to attempts to exploit telecom equipment during blackouts. And many city employees started working remotely through VPN, often during air raid alerts, from shelters and at strange hours. Our SIEM was drowning in alerts that looked like attacks but were just people trying to keep the city working.

This session shows how we rebuilt detection for a city of three million: moving from signatures to behavior, structured around the NIST CSF 2.0 functions, and automatically adding context to every event: how critical the asset is, where it is physically, and who is responsible for it. By our internal monitoring, false positives dropped by about 90%, mean time to respond for high-severity incidents went from about 45 to about 30 minutes for known attack patterns, and key city services stayed at about 99.9% availability.

Vendor-neutral, with real numbers, and honest about what these numbers can and cannot prove.

Learning objectives:

1. How to enrich SIEM events with asset criticality, location and ownership to cut alert noise.

2. How to tell legitimate crisis behavior (remote work, shelters, odd hours) from real attacks.

3. How to keep detection working when your own environment changes overnight.

AI agents aren't coming through the front door. They arrive quietly. A vendor adds an agentic feature to a platform you already run. A business unit connects AI to email and file shares. Someone builds an automation around an API key. Each one shows up holding credentials and exercising authority, often before anyone has decided who owns it.

Most organizations are answering with committees, and a lot of that is governance theater. Governance tells an agent what it should do. Architecture decides what it can do. When an agent goes wonky, and it will, the question that matters is how far the damage travels.

Jason Elrod, a healthcare CISO who secures an environment where a surgical robot can sit a room away from a fax machine, makes the case that you don't secure autonomy by assuming perfect behavior. You secure it by limiting the consequences of imperfect behavior. That means giving every agent its own identity, segmenting it to only what its job requires, and removing the pathways that have no reason to exist. He'll be just as candid about where containment stops helping, and what has to pick up from there.

Coming soon!