The AI Security Larsen Effect
A practitioner talk by Maxim Kovalsky of Consortium Networks, a value-added reseller (VAR), at the March 2026 Unprompted Conference.
Source: Conference abstracts page · Conference agenda
The Argument
The Larsen effect is the audio feedback loop — the squeal when a microphone picks up its own output through a speaker. Kovalsky uses it as a metaphor for the AI security buyer market: vendor marketing noise feeds back on itself until buyers can no longer extract signal. Consortium Networks is a VAR whose role is matchmaking — clients arrive with a problem, the VAR identifies the right products in the market. Kovalsky frames his work as “bringing the VA back to the VAR,” restoring the value-added analysis that the noise has eroded.
The dysfunction starts at the first call. A client says “we need AI security, who’s good?” without naming use cases, risk tolerance, or required controls. Kovalsky distinguishes two risk postures that imply different solutions: being concerned about having an incident versus being concerned about filing that incident with the SEC. Buyers tend to skip that discovery and ask only for a vendor name.
Vendor datasheets compound the problem. The talk quotes representative claims as examples of the noise: “swarms of autonomous agents,” “broadest and most comprehensive,” “99% efficiency at sub-30ms latency,” “AI-powered threat detection to automatically block all adversaries.” Some claims may be legitimate; some are public relations. None is verifiable from the datasheet alone.
Scale of the noise
The figures below are the speaker’s own counts, stated as of the talk and moving fast enough that he cited two snapshots six weeks apart.
| Metric | Value |
|---|---|
| Vendor claims to make sense of | 2,000+ (December) → 3,000+ |
| Vendors analyzed | 62 at proposal time → ~80 six weeks later |
| New entrants | ~4 per week — startups out of stealth, or existing vendors bolting on “AI security” |
The broken AI-governance loop
Kovalsky diagrams the procurement loop he sees repeatedly from the VAR seat:
- A need is declared: “we need AI security.”
- Six vendor datasheets arrive.
- A risk register is hand-jammed from OWASP LLM Top 10, NIST AI RMF, or another framework into spreadsheets and GRC tools, because little exists that targets AI security specifically.
- Four vendors are invited to demos.
- Two go to parallel proofs-of-concept, usually with unclear evaluation criteria.
- The POCs stall on objections: doesn’t Bedrock already have guardrails for this? we have DLP — can it do this? there are open-source tools, so why not build it in-house?
- Three months pass; the team decides it needs an AI security strategy and brings in a Big Four firm.
- The process restarts. Meanwhile, the customer chatbot has already shipped — the shipped-while-evaluating risk that makes the whole loop moot.
The Tool: Evidence-Backed Vendor Capability Mapping
Kovalsky built a tool to break the loop, using Claude Code (Opus 4.5, later 4.6). It is an agentic loop orchestrated inside Claude with two roles: a research agent and a QC agent, driven by system prompts and skills files refined over several months.
The research agent searches for substantiating evidence behind each vendor claim — GitHub repositories, API documentation, user forums where people report their experience with a product. Based on the evidence found, it assigns a confidence rating. The top rating, 5 of 5, requires code samples from a GitHub repository showing how the capability is actually instrumented. The process is not flawless: heavy human QC manages hallucinations and context errors.
Each vendor capability is mapped to a custom AI risk taxonomy, published on GitHub, that synthesizes OWASP LLM Top 10, NIST AI RMF, and MITRE ATLAS. Kovalsky’s view is that each of the three is good but partial; the taxonomy attempts to cover the full present-day risk surface that no single framework does.
The Configure / Buy / Build Wizard
The demonstration ran a sample system — “AdjusterIQ,” an insurance claim-adjuster GenAI application — through the tool’s risk-modeling wizard. The sample stack: AWS Bedrock with Sonnet 3.5, Amazon Kendra for RAG, direct API calls with tool calling, and session-scoped memory.
The wizard walks the buyer through a sequence that mirrors the discovery a VAR would do in person:
- Inherent risk profile — data sensitivity (internal confidential, employee access over the internet), autonomy level, and how coding assistants are used by the dev team, since coding assistants become part of the attack surface. Each choice surfaces the risks it activates; choosing autonomous actions over read-only produces a materially different risk profile.
- Architecture patterns — managed PaaS (Bedrock), RAG plus traditional databases, serverless compute, chat interface, tool calling, document analysis. Selections update the risk profile live.
- Existing strategic investments — what platforms the organization already owns (Bedrock guardrails, CrowdStrike, Zscaler). These are examined first, before going to the market.
- Buy-vs-build preference — buy, build, or no preference.
- Implementation-layer preference — capabilities handed to application teams via SDK/API versus capabilities deployed and governed centrally at an infrastructure choke point (network gateway/proxy) or via a managed endpoint agent. “No preference” surfaces vendors that can do both.
- Platform vs. best-of-breed — leaning toward a platform surfaces vendors that provide the most coverage.
The wizard then reports capability gaps at critical and high severity. In the demo, existing vendor relationships covered 8 capabilities, leaving 15 gaps. The buyer marks some gaps as build (for example, internal governance workflows the organization can build itself) and accepts the rest, producing a shortlist of vendors per remaining gap. For one set of 8 gaps the system suggested 5 vendors, each covering part of the set. The output is a printable summary for sourcing/procurement, engineering, or development teams — with configuration guidance for what is built in-house (for example, AWS Bedrock guardrails) alongside the commercial shortlist.
Market Judgment
Asked about consolidating to a platform versus picking best-of-breed, Kovalsky’s assessment was that the AI security landscape is highly fragmented. Even the large platforms — Palo Alto Networks and CrowdStrike — cover only about 50% of the most relevant risks. Wiz is far from that breadth, holding a small handful of relevant capabilities, though it may expand. The tool will recommend a platform when the buyer prefers one, but the consolidation-vs-best-of-breed tension remains open and deployment-specific.
Maintenance
Two agentic workflows keep the database current via GitHub Actions. A nightly workflow (roughly 12 hours each evening) re-researches a subset of vendors so that every vendor is revisited at least once a month. A separate workflow discovers new entrants — startups leaving stealth and traditional vendors adding AI security capabilities.
Where It Fits
This is a configure / buy / build capability-based vendor-selection framework: the buyer/practitioner counterpart to Gartner’s AI-SOC-agent evaluation criteria. Both cut through vendor marketing in a fast-moving category but produce different artifacts. Gartner publishes evaluation criteria a buyer applies to candidates already under review; Kovalsky’s framework runs earlier, deciding whether a vendor purchase is even the right unit of work for a given requirement, or whether the capability should be configured from owned tools or built in-house.
The per-capability sourcing decision maps onto the Agentic AI Security Capability Maturity Model: the CMM enumerates the capability domains an enterprise must mature; this framework supplies the configure/buy/build decision for each one. The structural cousin on the offensive side is the Red-Teaming Capability Framework, which decomposes red-team work into capabilities before assigning them to people, tooling, or vendors. Each reads a vendor-described market capability-first rather than product-first. The shipped-chatbot endpoint of the broken governance loop is the Shadow AI problem — deployment outrunning the evaluation meant to govern it. For the broader market backdrop, see Agentic SOC: State of the Field.
Risk taxonomy not enumerated in the source
Kovalsky’s AI risk taxonomy (the OWASP + NIST + ATLAS synthesis) is published on GitHub, but the repository URL was not stated in the talk. The full capability list and the per-branch decision criteria were demonstrated live rather than written down in the captured source.
Status
summarized — based on the transcript and slide deck captured to .raw/talks/. Vendor-count figures are the speaker’s own, stated as of the talk (March 2026).