✓ Human-authored analysis; AI used for formatting and proofreading.
Alan Shimel has been walking the Black Hat show floor for more than twenty years. His Techstrong Special Report from Black Hat USA 2026 asks a question the industry has been avoiding: has cybersecurity become too big for its own machinery?
It may be too big for the commercial structure it has built around the problem.
The data he assembled deserves attention from anyone building or buying security tools.
The numbers from the aisles
Shimel's report draws on IT-Harvest, Futurum Group, Pinpoint Search Group, IBM Institute for Business Value, and Momentum Cyber. The picture is consistent.
IT-Harvest tracks more than 4,100 cybersecurity vendors offering approximately 11,000 products. The 400-plus exhibitors at Black Hat represented about one-tenth of the vendor population.
An IBM Institute for Business Value study found that the average surveyed organization managed 83 security solutions from 29 vendors. More than half of the executives surveyed identified complexity as the largest impediment to security operations.
Futurum's decision-maker survey of 929 respondents found that approximately 56% of major cybersecurity procurements take at least six months to complete. More than a quarter take nine months or longer. Only 9.7% close in less than three months.
The budgets are not shrinking. Approximately 67% of Futurum's respondents expected increases. The market generated an estimated $335.8 billion in 2025. It is on track for $371 billion in 2026.
Shimel's conclusion from these numbers: "The industry is not running out of money. It may be running out of attention, implementation capacity and tolerance for complexity."
Every product costs more than its license
Shimel's point resonates with anyone who has operationalized a security tool: "Every product carries costs beyond its license. It must be procured, tested, deployed, configured, integrated, maintained and eventually upgraded or replaced. Someone must be trained to use it. Someone must decide what data it can collect and where that data can go. Its alerts must be tuned. Its permissions must be governed."
This is the operational tax on every solution in the stack. This is the attention cost. The 83 solutions from 29 vendors each consume a share of the security team's finite capacity. Each has a console, alerts and data model. It requires credentials, permissions, and network access to the infrastructure it protects.
Because it operates inside the cloud, they must be secured. The monitoring tool needs an IAM role. The scanning platform needs network access. The SIEM needs log ingestion permissions. The security tool's own infrastructure is a security surface that needs the same verification the tool was purchased to provide.
The industry's answer to "how do I verify my infrastructure?" requires deploying more infrastructure.
The recursive security problem, by example
AWS published a blog post in August 2026 describing how to identify over-permissioned S3 buckets across a multi-account environment. The recommended solution deploys a Lambda function with an execution role, configures cross-account IAM AssumeRole permissions for every target account, sets up EventBridge scheduled rules for recurring execution, provisions SNS topics with email subscriptions for notification delivery, creates an output S3 bucket for audit reports, enables AWS Config with managed rules, enables Security Hub with a central administrator account, and deploys CloudFormation StackSets for standardized remediation. The cleanup section at the end lists seven resource types to delete when the audit is complete.
The solution checks three properties per bucket: Public Access Block configuration, bucket policy status, and ACL grants. Three boolean checks.
To answer three yes-or-no questions, the recommended approach introduces eight AWS services, cross-account IAM roles, scheduled automation, notification routing, report storage, and a multi-step teardown procedure. Each component is itself a security surface. The Lambda function's execution role: is it least-privileged? The cross-account IAM role's trust policy: is it correctly scoped? The SNS topic receiving security alerts: is the topic policy restricted? The output S3 bucket storing findings: is it encrypted, versioned, and access-logged?
The infrastructure deployed to verify infrastructure must itself be verified. That is the recursive security problem. It is the documented, recommended approach from the cloud provider itself.
The alternative: capture the infrastructure state as a file, evaluate it locally, delete nothing afterward because nothing was deployed. The same three S3 properties + over 3,000 others across 121 services checked in three seconds on the engineer's laptop. No Lambda, cross-account roles, EventBridge, SNS, output bucket or cleanup required. This avoids recursive security surface.
The ratio tells the story. Eight services deployed to check three properties is not a security architecture. It is accidental complexity institutionalized as a best practice.
From tool sprawl to agent sprawl
Shimel's Section 07 identifies the next escalation. Nearly every vendor at Black Hat 2026 was selling some combination of an autonomous SOC, AI-powered threat intelligence, agentic governance, or automated remediation.
His observation: "Ten autonomous products do not necessarily create an autonomous SOC. They may create 10 separate agents operating with partial context, drawing from different data layers and exercising overlapping authority over the same environment."
He asks the questions the booths didn't answer: "Who decides which agent is allowed to isolate an endpoint, disable an identity or block a production workload? What happens when two agents reach different conclusions? Where is the audit trail?"
His conclusion: "The answer to tool sprawl cannot be agent sprawl."
The agent is the 84th solution. It requires procurement, deployment, credentials, permissions, monitoring, and governance. The same operational tax as every tool before it, plus the additional complexity of autonomous action. Each agent needs an identity. Each identity needs scoping. Each scope needs verification. Each verification needs infrastructure.
Verification without infrastructure
There is an alternative architecture where the verification layer adds nothing to the stack.
A snapshot of the cloud infrastructure's configuration state such as every IAM policy, security group, route table, encryption setting and detection service captured as a file. The evaluation runs on the engineer's laptop. No deployment, console, platform or credentials required at evaluation time. No infrastructure of its own.
The snapshot captures the state. The evaluator checks properties against it. The output tells you what's misconfigured, what's missing, and what to do next. Then it's done. There is no service to maintain, agent to govern, data pipeline to monitor, permissions to rotate or platform to patch.
The operational cost is one command. The infrastructure cost is zero. The evaluation completes in seconds. There is no 84th solution to operationalize because the verification layer is not a solution in the stack. It is a binary on the engineer's machine that reads a file.
This is how Stave works. Stave is an open-source AWS configuration verifier with a catalog of 3,000+ formal specifications. One command, snapshot and output. The snapshot is the input. The binary is the evaluator. The output separates confirmed findings from data gaps and tells you which four tags to add to unblock thirty more checks.
The complexity test
Shimel estimated that a meaningful Black Hat presence costs approximately $250,000. That is for a booth, not for the product. The product already existed before the company booked the floor space.
He observes: "The company with the best booth is not necessarily the company with the best product. It may simply be the company with the most capital to convert into visibility."
"A founder with an important technical breakthrough but a modest balance sheet may never receive a serious evaluation. If that company fails, the industry may conclude that the market rejected the innovation. The market may never have seen it."
There is a simpler test for whether a security tool addresses the complexity problem or contributes to it:
Does adopting this tool increase the number of things the security team must operate?
If the answer is yes such as another console, agent, data pipeline, set of credentials, integration or procurement cycle, the tool is part of the 83, not the answer to it.
If the answer is no. The engineer downloads a binary, runs it against a snapshot, reads the output, and is done. The tool exists outside the stack entirely.
The agent question, answered differently
Shimel asks what happens when every vendor adds an agent to its product. The agents need identities. The identities need scoping. The scoping needs verification.
The verification question underneath the agent question is: before deploying the agent, is the infrastructure the agent will operate on correctly configured? Is the agent's IAM role scoped to its task? Is the VPC the agent runs in isolated from production? Is the detection service covering the agent's actions delivering to the SIEM? Is the agent's credential rotating? Does the agent's network namespace have unrestricted internet egress?
Each of these is a configuration property. These properties can be inspected in a snapshot. It can be verified before the agent starts. It does not require deploying another agent to check.
The UK government's AI Safety Institute reported in July 2026 that AI agents in a routine evaluation took unsanctioned action against real people and organizations. The agents didn't escape their sandbox. They used the internet access they were deliberately given. The remediation was configuration: tighter egress controls, real-time monitoring, and isolation by default.
The configuration was verifiable before the evaluation started. Nobody verified it.
The question underneath the question
Shimel's report asks whether the cybersecurity industry has become too big. His answer is that it may be too big for its own commercial machinery, not too big for the problem.
There is a related question for anyone buying or building security tools: has the verification layer become too complex?
The 83 solutions generate alerts. The alerts require triage. The triage requires context. The context requires integration. The integration requires infrastructure. The infrastructure requires verification.
If the verification itself requires infrastructure such as an agent, a platform, a console, credentials, permissions, a deployment, a procurement cycle, then the verification is part of the complexity it was supposed to resolve.
If the verification requires nothing such as a file and a binary, it is outside the cycle entirely.
The industry is adding solutions. The engineer needs answers. The distance between the two is measured in operational complexity. Every tool that closes the distance by adding more complexity moves the answer further away.
Shimel saw it from the aisles of Mandalay Bay. The rest of us see it from the terminals where the 83 solutions produce their alerts.
We need more security. Does the next thing we add require a booth to explain it?
Alan Shimel's "Is the Cyber Industry Too Big?" is published as a Techstrong Special Report, August 2026. The data cited in this article is from his report's sources: IT-Harvest, Futurum Group, IBM Institute for Business Value, and Pinpoint Search Group.
Stave is an open-source AWS configuration verifier. Apache 2.0 license. No infrastructure required.
