The AI Security Larsen Effect: How to Stop the Feedback Loop

The AI Security Larsen Effect: How to Stop the Feedback Loop

Speaker: Maxim Kovalsky, Managing Director, AI Security CoE, Consortium Networks

Conference: [un]prompted 2026 — The AI Security Practitioner Conference

Date: March 3–4, 2026, San Francisco

Watch on YouTube: https://www.youtube.com/watch?v=U1TJpMpxZiU

Reading time: ~8 minutes

TL;DR

Enterprises buying AI security products face a broken procurement loop: vague marketing claims, no standardized evaluation framework, and vendor landscapes that expand by four new companies every week. Maxim Kovalsky of Consortium Networks built an AI-powered tool — backed by a synthesized risk taxonomy and a live vendor database of nearly 80 companies — to break that loop and give buyers evidence-backed recommendations in minutes.

Introduction

There is a cruel irony at the center of enterprise AI security procurement. Organizations know they need to secure their AI deployments. They reach out to a VAR (value-added reseller), collect vendor data sheets with claims like "swarms of autonomous agents" and "99% efficiency at sub-30ms latency," sit through demos, run parallel POCs — and then put everything on hold because someone just asked whether AWS Bedrock Guardrails already covers all of this.

Maxim Kovalsky calls this the "AI governance loop," and it's his day job. As Managing Director of the AI Security Center of Excellence at Consortium Networks, he serves as the matchmaker between enterprises with AI security problems and vendors claiming to solve them. His talk at [un]prompted 2026 — named after the Larsen Effect, that ear-splitting audio feedback screech — argued that the AI security market is caught in an analogous feedback loop: requirements circling back to the beginning without producing decisions or protection. His solution is a purpose-built AI-powered tool that uses agents, a synthesized risk taxonomy, and structured vendor evidence to break the cycle.

▶ Watch: Introduction and the VAR's Reality (00:00)

The Governance Loop That Keeps Repeating

Kovalsky laid out the anatomy of the loop with the weary precision of someone who has lived through it many times. It goes like this:

1. A business unit ships a customer-facing AI chatbot and announces, as an afterthought, that they need "some AI security."
2. The security team builds a risk register — typically a spreadsheet manually mapped to fragments of OWASP, NIST, and other frameworks not specifically designed for AI — because, as Kovalsky noted, "not a ton out there focuses on AI security specifically."
3. Six vendor data sheets arrive. Four vendors make it to demos. Two get POC invites.
4. POCs run in parallel without clear evaluation criteria.
5. Someone asks if the existing cloud provider (AWS, Azure, GCP) already handles this. Then someone else asks if DLP covers it. Then a Big Four consultant gets called in to build a strategy from scratch.
6. Meanwhile, the customer chatbot has shipped.

The market dynamics make this worse. When Kovalsky submitted his talk proposal, his database tracked 62 AI security vendors. By the time of the conference — roughly six weeks later — it had grown to nearly 80. "Roughly four new startups emerge out of stealth that claim to do AI security, or existing cybersecurity vendors bolt on AI security features," he explained. Buyers cannot possibly keep up through manual research.

▶ Watch: The AI Governance Loop (04:00)

Building the Tool: Architecture and Risk Taxonomy

Kovalsky's response was to build an agentic system using Claude Code (originally Opus 4.5, now updated). The system consists of a research agent and a QC agent, backed by carefully refined system prompts and skills files developed over several months. The agents' job: go find actual evidence for vendor claims.

"Evidence could be contained in GitHub repos, it could be contained in API documentation, it could even be in user forums," Kovalsky explained. The agents assign confidence ratings on a five-point scale — a score of five requires extracting actual code samples from a GitHub repo demonstrating how a specific capability is instrumented.

The underlying risk taxonomy that maps vendor capabilities to real risks is publicly available on GitHub. It's a deliberate synthesis of three frameworks, each of which Kovalsky sees as incomplete on its own:

• OWASP LLM Top 10 — strong on application-layer risks
• NIST AI RMF — strong governance structure with four functions: Govern, Map, Manage, Measure
• MITRE ATLAS — strong adversarial attack taxonomy

"Each of those three I think have really good components," he said, "but they don't tell the whole picture." The combined taxonomy covers the full range of risks he encounters in practice, organized so vendor capabilities can be mapped against specific control requirements.

▶ Watch: Tool Architecture and Risk Taxonomy (06:01)

Live Demo: AdjusterIQ Through the Risk Modeling Wizard

With five minutes on the clock, Kovalsky ran a live demonstration using a fictional system called "AdjusterIQ" — an insurance claim processing AI built on Claude Sonnet 3.5 via AWS Bedrock, using Amazon Kendra for RAG, direct API calls for orchestration, and session-scoped memory.

The wizard walked through a series of structured questions that mirror what a competent security architect would ask in a discovery session:

• Data sensitivity: Internal confidential data
• User access: Employees over the internet
• AI system type: Document analysis, chat interface, tool calling
• Autonomy level: Interactive coding assistance for the dev team
• Architecture patterns: AWS Bedrock, RAG with traditional databases, serverless compute
• Existing vendor relationships: Palo Alto Networks and Zscaler

As each answer was selected, the system surfaced and updated the risk profile in real time. After the inherent risk profile was established, the wizard moved to architecture-specific risks, then asked about security platform investments already in place, and buy-vs.-build preferences.

The output was a prioritized gap analysis. Of the risks mapped at "critical" and "high" levels, eight capabilities were already covered by existing Palo Alto and Zscaler investments. Fifteen gaps remained. The system then identified which gaps were candidates for in-house build (using open-source tools), which warranted new vendor evaluation, and surfaced a shortlist of five vendors whose documented capabilities addressed the remaining requirements.

▶ Watch: Live Demo — AdjusterIQ Risk Assessment (10:05)

What the Vendor Research Actually Shows

Before running the wizard, Kovalsky demonstrated the underlying vendor database by pulling up the card for CrowdStrike Falcon AI DR. The system showed which risk taxonomy categories the product addresses, whether it operates at the application layer or infrastructure layer, and the agent-collected evidence: specific API documentation excerpts, configuration examples, and confidence ratings for each claimed capability.

A key feature is the implementation-layer dimension. Many AI security vendors offer two deployment paths: an SDK/API path that integrates at the application layer (developer-facing), and an infrastructure path that operates as a network choke point or endpoint agent (centrally managed). The tool tracks both, allowing buyers to filter recommendations based on their team's ability to absorb each type of integration.

Kovalsky was candid about the tool's limitations. "There's still a lot of human QC that goes into managing all the hallucinations and context issues," he acknowledged. Even with extensive agent refinement, the system requires ongoing human review before results are acted upon.

▶ Watch: Vendor Card Demo — CrowdStrike Falcon AI DR (12:05)

Q&A: Platform vs. Best-of-Breed

A question from the audience cut to the heart of a persistent enterprise security debate: should buyers pursue a platform play (one vendor covering many risks) or best-in-class point solutions?

Kovalsky's assessment was frank: "The AI security landscape is very, very fragmented. Even the big companies like Palo Alto and the CrowdStrikes — even those big platform plays are still gonna give you about fifty percent of the risks that are most relevant." No single vendor covers the full taxonomy, including from the largest players. Wiz, frequently cited as a platform play, has only a small number of relevant AI security capabilities today.

On maintaining the database at velocity, Kovalsky noted the tool itself is the maintenance mechanism — agents continuously run to update vendor evidence as products evolve, though he acknowledged that the pace of change is the hardest operational challenge.

▶ Watch: Q&A — Platform vs. Best-of-Breed (20:06)

Notable Quotes

"We need AI security, we think. Who do you recommend? Well, hold on. Like, that's not enough information."

"The customer chatbot has shipped. And in the meantime, we just went back to the beginning."

"Not a ton out there focuses on AI security specifically, so most teams are building this in-house using spreadsheets and kind of hand-jamming it into their GRC tools."

"Even those big platform plays are still gonna give you about fifty percent of the risks that are most relevant."

Key Takeaways

• The AI security procurement loop is a real operational problem — not a theoretical one. Most enterprises cycle through requirements, demos, and POCs without landing on clear decisions, while AI systems ship regardless.
• No existing framework is sufficient on its own. A practical AI security risk taxonomy requires synthesizing OWASP LLM Top 10, NIST AI RMF, and MITRE ATLAS — none of them individually covers the full picture.
• Vendor claims require evidence, not trust. Confidence ratings grounded in GitHub repos, API docs, and user forums are more useful than marketing data sheets, even if they require ongoing human QC.
• Existing vendor relationships matter. A procurement tool that surfaces what your current investments already cover — before sending you to new vendors — saves time and budget.
• The AI security vendor landscape is growing by ~4 companies per week and no single platform covers more than roughly 50% of relevant risks. Buyers need a structured approach, not just more demos.