The waitlist is not the control: Why frontier cyber AI needs business-side guardrails | Daily Reports Online
Restricted access sounds like a security control. For frontier cybersecurity AI, it is only the vendor’s admission process.
There is little doubt that cybersecurity AI is transitioning from small-scale demos to early-stage enterprise testing. In fact, some of the most advanced cybersecurity AI systems have the potential to significantly speed up vulnerability discovery; reason across code and infrastructure; and compress work that once required days into hours.
The defensive value is real.
However, the primary issue is not merely whether an organization can gain access to a restricted program. The primary issue is whether the organization is prepared to link this capability to its source code, logs, cloud applications, identified vulnerabilities and/or incident response workflows.
Principal Engineer Principal Engineer and contributes to AI security standards at OASIS CoSAI and the IETF.
A waitlist determines who gets access to a program. It does not determine if that access is safe to use.
This represents the blind spot within many organizations’ evaluation methodologies. When evaluating AI-based cybersecurity solutions, many organizations apply the exact same methodology they would use when purchasing traditional security products.
Specifically, they look at benchmark results, false positive rates, supported languages, deployment models, and cost.
While all these factors will be relevant to an AI-based cybersecurity solution, none of them account for the ability of the solution to think about/analyze vulnerabilities, develop exploit paths for those vulnerabilities, or interact with security-related tools.
As such, any system with these capabilities will be much more than simply another “scanner.” Instead, the system will represent part of the organization’s control environment.
Therefore, before integrating one of these systems with actual business assets, technology leaders need their own acceptance test, which I refer to as the Cyber AI Acceptance Test.
This test consists of five separate “gates”, each of which should result in either a “connect” or “no-connect” answer before the system is permitted to operate on any production data/tools/workflows.
The purpose of the Cyber AI Acceptance Test is not to apply the same level of scrutiny to each experimentation effort. A sandbox test, an internal pilot, a full production deployment and a regulatory-controlled system should not all share the same control baseline.
The problem begins when organizations treat their production access as though it was a sandbox because the vendor has already granted them permission to do so.
Distribution: who can reach the model?
“Restricted access” usually means the vendor has limited admission to selected customers, partners, or critical defenders. It does not necessarily explain who has day-to-day access to the model environment.
Enterprise buyers should ask how access is authenticated, whether credentials are scoped, how contractor and partner access is handled, and whether access paths are monitored separately from regular user activity.
A capability may be restricted by policy, but operationally broad if support staff, contractors, and integration partners all have routes into the same environment.
The distribution review should answer one question: who can touch the system that can touch our data?
Connect or no-connect: Can we trace all access routes into the model environment, including vendor support, contractors, and integration partners?
Data: code is not the only sensitive asset
When a cyber AI model reviews code, logs, telemetry, or vulnerability findings, the organization needs to know what leaves its perimeter. Source code is the obvious concern, but logs may reveal hostnames, customer identifiers, access paths, or incident timelines.
Prompts may contain architecture details. Vulnerability findings may reveal unpatched weaknesses before remediation is complete. Metadata can also become sensitive when pooled across systems.
The vendor should provide a data-flow diagram showing what is sent, where it is processed, where outputs are stored, how long they are retained, and who can access them. If the program involves shared defense, the organization also needs to know what findings may be shared with other participants, and on what basis.
Connect or no-connect: Do we know exactly what code, prompts, logs, telemetry, and findings leave our perimeter when this system runs?
Capability: four levels, four risk profiles
Enterprises must distinguish between what the model knows and what the model can do. A useful starting point is to separate capability into four levels: observe, analyze, recommend, and act.
Observe and analyze are read-only processes. The model reviews a sandboxed copy of code, parses logs, examines configuration data, or summarizes vulnerability findings. The primary risk is data exposure, not operational action. These levels are usually the best candidates for an initial pilot once the data boundary is defined.
Recommend raises the risk. The model drafts detection rules, proposes patches, or identifies exploit paths. The output may be advisory, but it still influences downstream decisions. That means human validation is required before anything moves into production.
Act is the highest-risk level. The model might activate scanners, issue tickets, modify rules, query production telemetry, run remediation scripts, or call cloud services. Once the model can trigger tools, the evaluation must include blast radius, reversibility, approval thresholds, and runtime constraints.
Each action should require explicit sign-off, logging, and rollback planning before the pilot begins.
The model should not decide its own authority. In mature AI security architectures, authorization decisions sit outside the model and are enforced by deterministic policy systems. The model can recommend actions, but policy decides which access, actions, or modifications are permitted.
Connect or no-connect: Is the model limited to observing and analyzing unless an external policy system approves action?
Containment: the kill switch must exist before the pilot starts
Organizations should not wait for an incident to decide how to pull access. Teams need to know how credentials are deactivated, APIs are disabled, and network access is blocked. Expected timeframes should be documented, and exercises should be run before the model sees sensitive data.
If cutting off the model requires multiple teams, a vendor support ticket, and a meeting to agree on ownership, the containment plan is inadequate for a tool that operates at machine speed.
Logging should also sit outside the model’s reach. Prompts, outputs, tool usage, and generated findings should be stored where the model cannot access or alter them. The forensic record must survive the failure mode it exists to investigate.
Connect or no-connect: Can we revoke access and preserve evidence within a defined time, using logs the model cannot access?
Accountability: one owner, not a committee
Frontier cyber AI cuts across security, engineering, legal, privacy, procurement, and executive risk. Shared responsibility is attractive, but shared responsibility often becomes unclear responsibility.
Before entering a restricted-access program, a company should assign one internal owner. That person owns the access scope, monitoring expectations, data-sharing boundaries, incident process, and the decision to maintain, pause, or cut access. Committees can advise. They should not be the only mechanism for action.
Connect or no-connect: Does one person have authority to pause or terminate access without convening a committee?
The real enterprise decision
Frontier cyber AI can improve defensive capability. But access to the program should not be confused with readiness to use it.
The vendor’s restricted-access process answers one question: who is allowed in? The Cyber AI Acceptance Test answers another: what are we about to connect this capability to, and can we govern the outcome?
That is a decision for the enterprise, not the vendor. The waitlist determines who gains access. The acceptance test determines whether access is safe to use.
We’ve featured the best encryption software.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here:
