When rules of engagement say "automated tools are permitted," what does that actually authorise? When a vendor markets a product as "autonomous threat detection," what does that mean in practice? When a regulator asks whether a security operation was conducted with appropriate human oversight, what standard are they applying?
These are not rhetorical questions. They come up in real engagements, in real procurement conversations, and in real regulatory discussions while the cybersecurity industry has no agreed way to answer them.
That is the problem I set out to solve with COAST.
What is COAST?
COAST stands for Cybersecurity Operations Autonomy Scale for Tooling. It is a classification framework I developed to give practitioners, vendors, and clients a shared, precise vocabulary for describing and discussing the degree of autonomy exhibited by security tooling. At Securify, we work across a wide range of security disciplines and engagements, offensive testing, incident response, threat hunting, malware analysis. The absence of this shared language is something we run into constantly. COAST is our contribution to the community to help address that gap.
The framework draws inspiration from the SAE vehicle autonomy scale, a six-level model that gave the automotive industry a universal reference for manufacturers, regulators, insurers, and consumers alike. The analogy is instructive but imperfect. Vehicles always perform the same fundamental task. Security professionals do not. A red team operator pursuing lateral movement, a malware analyst reverse engineering a binary, and a SOC analyst triaging alerts are performing fundamentally different types of work with different notions of scope, risk, and goal.
COAST addresses this by focusing on a single axis that is consistent across all of those disciplines: who decides what to do next, and what triggers human involvement. Everything else such as what techniques are used, what the objective is, what the risk profile looks like, is context that sits around the framework, not inside it. This makes COAST applicable across the full breadth of cybersecurity work while remaining precise enough to be operationally useful.
The Three Components
COAST consists of three complementary classification components designed to address different but related dimensions of autonomous tool operation.
COAST Levels (CL0–CL5) form the core of the framework. They define six levels of autonomy based on observable differences in who decides what to do next and what triggers human involvement. Every tool, system, or engagement can be assigned a COAST level.
Audit Levels (AL0–AL3) are a supplementary classification for systems operating at CL3 and above. At these levels, a system generates its own reasoning independently of any human decision or pre-authored logic. Without explicit logging, that reasoning is simply lost and post-engagement review, accountability, and incident reconstruction become significantly harder or impossible. Audit levels define the degree to which autonomous reasoning and the actions it produced are captured and reconstructable after the fact.
Data Handling Levels (DH0–DH2) define the boundaries within which sensitive engagement data may be processed during tool operation. Critically, these apply at any autonomy level. A CL1 tool can send engagement data to an external service just as a CL5 system can. Data handling requirements must be defined independently of autonomy level and are relevant across all disciplines and engagement types.
The complete classification notation looks like this: COAST 1.0: CL4, AL2, DH1. Autonomy level, audit requirement, and data handling boundary in a single, unambiguous string that can appear in a rules of engagement document, a procurement requirement, or a methodology section of a report.
The Six COAST Levels
Here is a brief overview of each level. A quick reference graphic is included below, and the full definitions — including runtime behaviour, failure handling, and examples across multiple disciplines — are in the white paper.
CL0 - Manual Operation The human initiates every action. The tool performs a single, atomic, predetermined operation per invocation and returns output. No follow-up action is taken automatically. Every subsequent step is a conscious, deliberate decision by the operator.
CL1 — Automated Execution within Fixed Scope The tool executes a human-authored decision tree automatically within a single consistent operation type. It may extend the same operation to newly discovered in-scope items, but the fundamental nature of what it does does not change based on findings. All logic governing what happens with intermediate results was pre-authored by the human.
CL2 — Automated Multi-Phase Orchestration The tool executes a human-authored chain of distinct operations in sequence, where the findings from each step automatically feed into a different type of operation next. Results accumulate in a shared knowledge base. Newly discovered in-scope subjects are automatically subjected to the full chain. Every transition is governed by pre-authored logic.
CL3 — Autonomous Reasoning within Provided Toolset The system autonomously reasons about how to pursue the defined goal using the available toolset. It decides what to invoke, in what order, and with what parameters based on its findings. It can generate code or scripts that operate internally to process data, correlate findings and parameterise provided tools. It does not generate capabilities that reach outside the system to interact with subjects. High-impact actions are paused and submitted for human approval before execution.
CL4 — Autonomous Reasoning with Self-Expanding Capability The system operates as at CL3, but can additionally generate new capabilities, tools, scripts, probes, or code, that actively reach outside the system and interact with subjects in the target environment when its provided toolset is insufficient. The human retains control over high-impact actions through approval gates.
CL5 — Full Autonomous Operation The system pursues the defined goal without requiring human approval for any action, including those that would be classified as high-impact at lower levels. The human defines the goal and scope before execution begins and has no further required involvement during execution.
It is worth being explicit about what the levels do not measure. A higher COAST level does not imply superior results. A skilled practitioner at CL1 may identify critical findings that a fully autonomous CL5 system misses entirely. COAST level does not correlate directly with operational risk. A human manually executing a destructive action is CL0 but potentially catastrophic in consequence. It measures one thing: the degree of human involvement in tool operation.
The paper also addresses the boundaries of the scale itself, including why it stops at CL5 rather than extending to a hypothetical fully unrestricted, scopeless system, and why the Data Handling Levels stop at DH2 rather than defining a stricter tier. Both are deliberate design decisions, not oversights, and the reasoning is laid out in full in the paper for anyone weighing edge cases.
Capablity vs Operational Level
Of all the concepts in COAST, the one I think will immediately change how practitioners and clients talk about tooling is the distinction between capability level and operational level.
A tool's capability level is fixed. It reflects the maximum degree of autonomy the tool can exercise when fully utilised. It is an intrinsic property that does not change based on context or configuration.
A tool's operational level reflects how it is deployed in a specific engagement. A CL5-capable tool can be deliberately operated at CL4, with human approval gates enabled for high-impact actions, because a client's rules of engagement require it, because regulation demands it, or because the operator's own risk assessment calls for additional oversight. The tool's capability has not changed. Only the operational constraints applied to it have.
This distinction has direct practical consequences:
- Vendors classify their products at capability level. This reflects what the product can do and enables informed procurement decisions.
- Practitioners classify engagements at operational level. This reflects how the tool is being used and supports accurate methodology documentation.
- Clients set a permitted operational level ceiling and define what degree of autonomous action they are actually authorising.
All three classifications are valid and serve different purposes. A complete engagement record should note both the capability level of tools used and the operational level at which they were deployed.
It is also worth noting that operational level does not need to be a single setting applied uniformly across an entire engagement. Different phases carry meaningfully different risk profiles. Higher autonomous operation may be appropriate during passive information collection, while strict human control may be required during active system interaction, privileged access operations, or sensitive data handling. Defining the permitted operational level per phase rather than per engagement gives clients and practitioners significantly more precise control over risk and oversight.
Why This Matters Now
Security tooling is becoming increasingly autonomous. What used to require explicit human initiation at every step is now being done by systems that reason independently, chain operations across multiple phases, generate novel capabilities mid-execution, and make consequential decisions without a human in the loop. That trend is not slowing down, and the pace at which AI-driven tooling is entering the market means the gap between what tools can do and what clients, practitioners, and regulators understand them to be doing is widening.
Without a shared framework for describing this, clients cannot make informed decisions about what they are authorising. Practitioners cannot precisely communicate their methodology. Vendors cannot objectively position their products. Regulators cannot write enforceable requirements. The consequences of that imprecision compound as tooling becomes more capable.
COAST does not resolve all of those challenges on its own, it is a classification framework, not a certification body, and v1.0 operates on a trust-based model that acknowledges the absence of independent verification as a meaningful gap and an area for future development. What it does provide is a common reference point for the conversations that need to happen: between clients and practitioners when defining rules of engagement, between procurement teams and vendors when evaluating products, and between the industry and regulators when discussing what appropriate human oversight actually means in practice.
Read the Paper and Share Your Feedback
COAST v1.0 is available now on the Securify website. The full framework covers the complete level definitions across four dimensions each, a classification decision tree, the supplementary audit and data handling level classifications, a fully worked rules of engagement example across a complete red team engagement, and guidance on operational best practices including scope enforcement, guardrail definition, and audit requirements.
This is a v1.0 framework and I am actively seeking feedback from the community. If you have thoughts, disagreements, edge cases you think the model handles poorly, or discipline-specific perspectives I should account for in the companion documents, I would very much like to hear from you. You can reach me via LinkedIn or e-mail.
The framework is published under CC BY 4.0, use it, adapt it, reference it, and share it freely.