Threat Analysis

OpenAI Astra Cybersecurity: What "Critical" Really Means

CT
CyberOrbit Team
27 min read
Share

On 1 September 2026, OpenAI announced that Astra is the first of its models to reach the "Critical" cybersecurity tier of its Preparedness Framework. The company's own evaluations describe a system that found and exploited previously unknown vulnerabilities without being walked through each step. That is the fact, and it deserves to be read flat, without the framing the news cycle put around it.

The interesting question is not whether the model is impressive. It is what happens to the report your auditor reads. If a model can find a zero-day on its own, does the document you hand to a QSA, an ISO lead auditor, or a customer's procurement team become less valuable, or more?

The answer runs the opposite way to the intuition. A finding is evidence. A signature is attestation. Two different artefacts doing two different jobs, and an announcement that makes machine-generated evidence more abundant raises the value of the second rather than lowering it.

🎯Key Takeaway
A model finding a zero-day produces evidence. A named, qualified, independent professional signing the report produces attestation. Both jobs exist; the announcement raises the value of the second.

What OpenAI Actually Announced (and What It Did Not)

Strip the coverage back to what OpenAI published and the claims are narrow and specific.

Astra scored 100% on ExploitBench, an evaluation that measures whether a model can turn a known vulnerability into a working exploit, against 78.5% for GPT-5.6 Sol, the previous frontier cyber-capable model. That headline number measures weaponisation of disclosed flaws, not discovery of unknown ones.

100%
Astra's score on ExploitBench, turning known vulnerabilities into working exploits, up from 78.5% for GPT-5.6 Sol (OpenAI, September 2026)
ExploitBench measures how reliably a model can turn a known vulnerability description into a working exploit. A perfect score marks a meaningful capability shift.

The discovery result came from a different evaluation: an internal port of ExploitBench built from 20 high-severity V8 vulnerabilities disclosed more recently. On that set OpenAI reports higher arbitrary code-execution rates than GPT-5.6 Sol using far fewer output tokens, not a perfect score. What made it notable is that the model found and used two previously unknown vulnerabilities as part of an exploit chain. Nobody asked it to find new bugs. It found them while working the assigned problem, and OpenAI says it is disclosing both to the maintainers.

Worth naming the domain, because it bounds the result. V8 is Chrome's JavaScript engine: a large C++ codebase where exploitation means memory corruption, heap grooming and sandbox escape. That is a specialist discipline, and it is not the discipline that finds a broken access control in your billing API. The result says frontier models are getting good at memory-safety exploit development against a target class with public fuzzing corpora and a decade of published prior art. Read across to "AI now finds any bug in any system" and you have over-read it.

OpenAI also said it delayed parts of Astra's development and release while strengthening protections against cyber misuse, then concluded the safeguards sufficiently minimise the risk of severe harm for release. Those safeguards include training the model to refuse harmful cyber requests more reliably, layered classifiers against misuse, and monitoring intended to stop unauthorised model actions even without a malicious user in the loop. At launch, the most advanced cyber capabilities go to a small group of vetted alpha testers, the generally available model refuses proof-of-concept exploit generation, and OpenAI has said it will widen access for vetted defenders through its Daybreak Blue programme over the following weeks.

Now the part the headlines skipped. OpenAI did not claim Astra routinely and autonomously compromises arbitrary production estates, and it did not make the capability that earned the Critical rating generally available. Nothing in the announcement establishes that a model pointed at your unremarkable corporate network will chain its way to domain admin this quarter.

Three columns, then, and most coverage collapsed them into one:

A 100% score on ExploitBench, turning known vulnerability descriptions into working exploits, up from 78.5% for the previous frontier model. Two previously unknown vulnerabilities found and used as part of an exploit chain during an internal port of that benchmark built from 20 high-severity V8 flaws. Discovery that was unprompted: the model was not asked to hunt for new bugs, it surfaced them while working the assigned problem. All of it under evaluation conditions, on targets OpenAI selected, in one specialist domain (memory-safety exploitation of a C++ JavaScript engine).

Why the gating matters more than the benchmark

A capability demonstrated under evaluation conditions is not a capability distributed, and that distinction does most of the work in your risk calculation. Evaluation conditions mean a defined target, a known environment, and an operator who wants the system to succeed. Production adversary conditions mean unknown topology, monitoring, rate limits, breakage risk, and an operator who needs to stay quiet.

The gating tells you where this capability sits on the distribution curve today: with OpenAI and a small set of vetted testers. Be careful how long you assume that holds. OpenAI itself framed the expansion to vetted defenders in weeks, not years, and gating at one lab does nothing about the open-weight models that trail frontier capability by months. So the planning horizon is weeks to quarters, not this afternoon and not next year. Which brings us to the rating word itself, because "Critical" is carrying more weight in the coverage than its definition supports.

What "Critical" Means in OpenAI's Preparedness Framework

In OpenAI's Preparedness Framework, the Critical cybersecurity threshold is reached when a model can identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention, or devise and execute end-to-end novel strategies for cyberattacks against hardened targets given only a high-level desired goal. No step-by-step human direction, in either branch. That is the bar Astra was judged to have crossed.

ℹ️What Critical means in OpenAI's Preparedness Framework
A model reaches the Critical cybersecurity tier when it can do either of two things without human intervention: identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems, or devise and execute end-to-end novel strategies for cyberattacks against hardened targets given only a high-level desired goal. This is OpenAI's own internal classification against its own framework. No external body certified the result, OpenAI is the party that decides what counts as "hardened" and "many", and it is not an industry standard you can cite as one.

Two things follow, and they pull in opposite directions. The first is a reason to take it seriously: this is a self-assessment by the model's developer, who had every commercial incentive not to make it. A Critical rating triggers safeguard obligations, delays a launch, restricts a capability to vetted partners, and hands regulators a headline. Costly disclosures are generally more credible than free ones.

The second is a reason not to over-read it. This is an internal classification against an internal framework. No external body certified the result, there is no cross-vendor definition of "hardened real-world critical systems", and no published methodology a third party can rerun. Treat it as you would any vendor's own benchmark: informative, directionally useful, not a substitute for independent measurement. It is honest signal about where frontier capability sits, not a number you can drop into a risk register as though it came from NIST.

What Actually Changes in Your Threat Model (and What Does Not)

Here is where a lot of security teams will spend the next month badly, so it is worth being precise about the delta.

What changes. Exploit-development time is compressing. The step between "a CVE is disclosed" and "a working exploit exists in the wild" was a skill bottleneck, and it was the rate limiter patch windows were built around. Turning an advisory into a weaponised exploit took a competent person days to weeks. A 100% ExploitBench result says that step is getting cheap under evaluation conditions, and capability at the frontier reliably reaches cheaper and less restricted models within months. The constraint was never the vulnerability, which is public the moment it is disclosed. It was the number of people who could build a reliable exploit from the advisory, and that number is going up.

Be precise about the strength of that claim, because it is a forecast rather than a measurement. Nobody has shown a general collapse in observed time-to-exploit attributable to Astra, and the model that produced the benchmark result is gated. What the result does is remove the assumption's safety margin: a patch SLA for internet-facing assets premised on two weeks of exploit-development lag is now resting on a bottleneck you can watch eroding, so it needs a deliberate decision this quarter rather than an inherited default. We wrote about the 48-hour exploit window before this announcement, and the Astra results point the same way.

⚠️Capability demonstrated is not capability distributed
OpenAI restricted Astra's most advanced cyber capabilities at launch to a small vetted group working on critical-infrastructure defence. A result produced under evaluation conditions, by the lab that built the model, against targets it chose, is not a general-availability capability in the hands of the people attacking you. Plan for the distribution curve to move, because it will. Do not model today's adversary as though it already has.

What does not change. Your unpatched edge device was already the problem. It was the problem last year, when the exploit took a human a fortnight to write. Astra did not create that exposure, it shortened the fuse on one you already had. The initial access vector is also still overwhelmingly boring: stolen or phished credentials, an unpatched perimeter appliance, an exposed management interface, a forgotten staging host. Zero-day capability raises the ceiling of what is possible against hardened targets. It does not change the floor, and most organisations are still breached at the floor.

The delta splits cleanly. On one side, what genuinely changes. On the other, what does not:

Pros
  • ✅Changes: exploit development is compressing, so turning a disclosed advisory into a working exploit is ceasing to be a days-to-weeks skill bottleneck
  • ✅Changes: the population able to weaponise a public CVE widens as the capability reaches cheaper and less restricted models
  • ✅Changes: patch SLAs for internet-facing assets premised on two weeks of exploit-development lag have lost their safety margin and need a deliberate decision
  • ✅Changes: asset inventory discipline matters more, because compressed timelines punish unknown assets hardest
Cons
  • ❌Unchanged: the unpatched edge device was already the problem; the fuse got shorter, the exposure was not created
  • ❌Unchanged: initial access is still overwhelmingly stolen credentials, unpatched perimeter appliances and exposed management interfaces
  • ❌Unchanged: zero-day capability raises the ceiling against hardened targets, not the floor where most breaches actually happen
  • ❌Unchanged: no new category of testing appears that you suddenly have to buy

So this news should move your patch SLA and your perimeter inventory discipline. It should not move attention away from credential hygiene, and it does not create a new category of testing you need to buy. The calculus on where automated testing genuinely suffices is unchanged too, and we covered that in when automated pentesting is enough. The operational impact is real but bounded. The market impact is the more interesting story, and the one almost every take got backwards.

See what your external surface exposes, mapped to the controls it touches.

Run a free External Security Check →

The Paradox: Stronger AI Discovery Raises the Value of Human Attestation

The intuitive reading is that Astra compresses the value of security testing services. If a model can find zero-days on its own, surely findings are being commoditised and anyone selling findings is in trouble.

That reading is half right in a way that inverts its own conclusion. Findings are being commoditised, and that is precisely why attestation becomes more valuable.

It is worth separating two things that are moving at different speeds, because the section above argued that the gating matters and it still does. The zero-day discovery capability that earned the Critical rating is restricted today. The ability to produce a large volume of plausible, evidenced findings against an ordinary web estate is already commodity, available in every scanning product on the market, and Astra is the clearest signal yet that the ceiling on that volume keeps rising. The attestation argument rests on the second, which is already true, not on the first, which is coming.

When machine-generated findings are rare, the finding carries the value, because producing it required scarce expertise. When they are abundant, the finding carries almost none on its own, because anyone can produce a thousand by lunchtime. What stays scarce is the named, qualified, independent party who reviewed the output and put a signature under a conclusion about it. This is not security-specific: it is the same reason financial statements became more valuable to audit, not less, as accounting software made producing them trivial. The bottleneck moves from production to assurance.

The market was already pricing this in before Astra. Cobalt's AI and Pentesting Pulse Report 2026, based on 455 security professionals at organisations with more than 500 employees, found willingness to rely entirely on automation for security testing fell from 29% to 9% in a single year, while AI use inside testing workflows rose over the same period, which we unpacked in trust in AI pentesting collapsing from 29% to 9%. Buyers are not rejecting AI doing the work. They are rejecting nobody being answerable for the result, and a more capable model does nothing to answer that objection.

We sell independently attested testing, so this conclusion happens to suit us and you should weigh it accordingly. A frontier lab has published the strongest available evidence that the volume of machine-generated findings keeps rising, and the scarce complement to abundant findings is a signature. The argument does not rest on our saying so, though. It rests on what the standards already require, and those clauses are reproduced verbatim further down so you can check them against this yourself.

🎯Key Takeaway
When AI findings become abundant and cheap, the scarce and valuable thing is not the finding, it is the named party who stands behind it.

Evidence Versus Attestation: Two Different Artefacts, Two Different Jobs

Here is the distinction most coverage of this story collapsed, and it is the whole argument.

An AI finding is evidence. Its job is to establish that a specific condition exists on a specific system at a specific time. A good one contains the HTTP request sent, the response received, reproduction steps someone else can follow, a timestamp, and a proof hash confirming the artefact was not edited after capture. Evidence is verifiable on its own terms: you do not need to trust the producer if you can rerun the reproduction.

An attestation is a signature: an identified, qualified, independent party asserting what scope was tested, what methodology was applied, and that they stand behind the conclusion. It is not verifiable by rerunning anything. Its value comes from accountability.

Evidence Attestation
Produced by Scanner, agent, model, or tester An identified, qualified, independent party
Answers Does this condition exist on this system? Was this scope competently and independently tested?
Verified by Rerunning the reproduction steps The identity, qualifications and independence of the signer
Fails when The capture is incomplete or unreproducible The signer is not independent, not qualified, or not named
Made cheaper by better AI Yes, substantially No

A model cannot occupy the second column, and not because it is insufficiently capable. It holds no professional credential. It carries no professional accountability, so nothing is at stake in the assertion. And it cannot be questioned by an audit committee, which is the practical test: when the board asks "what did you not test, and why", somebody has to be in the room to answer.

Which is why the pipeline matters more than the model. Getting from a raw AI finding to an artefact an auditor will accept takes five steps, and only the first is the model's:

1
The AI scanner captures evidence. The actual HTTP request sent, the actual response received, response timing, and a proof hash over both so the capture cannot be quietly edited later.
2
The finding is validated against the target scope. Confirmed reproducible, confirmed in scope, confirmed neither a duplicate nor a false positive.
3
A certified security professional reviews and signs the report. Methodology, coverage and conclusion become attributable to a named, qualified party independent of the tested organisation.
4
The signed report is delivered with a fixed scope and date. The recency and scope questions on a questionnaire now have answers you can point at.
5
The auditor accepts an attributable, independent artefact. Evidence they can reproduce, attestation they can hold someone to.

Both jobs exist, and both get paid for. What changes as models improve is the ratio of effort between them, and we went deeper on the artefact question in what auditors accept in an AI-assisted report. None of that is an opinion about how compliance ought to work. It is close to a paraphrase of what the clauses already say.

What the Standards Actually Say (Clause by Clause)

Compliance folklore in a week like this gets loud and imprecise. Here is the requirement text instead.

Standard Clause What it actually says
SOC 2 CC4.1 (and CC7.1) Ongoing and/or separate evaluations are performed to ascertain whether the components of internal control are present and functioning. The AICPA points of focus behind the criterion name knowledgeable personnel and objective evaluation. Note what is not there: neither CC4.1 nor any other criterion names penetration testing. It is the evidence auditors conventionally accept, not a named requirement.
PCI DSS v4.0.1 11.4.1 to 11.4.4 11.4.1 requires a defined, documented and implemented penetration testing methodology. 11.4.3 requires external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, by a qualified tester with organisational independence; 11.4.2 sets the same bar for internal testing. 11.4.4 requires exploitable findings to be corrected and the testing repeated to verify the corrections.
ISO 27001:2022 A.8.29 (and A.8.8) A.8.29 is "security testing in development and acceptance": testing processes defined and implemented in the development lifecycle. A test against a live production system usually speaks at least as directly to A.8.8, management of technical vulnerabilities. Neither control names independence or tester qualification.

Notice what is absent. None of these clauses forbids AI from doing the testing, and none specifies a tool, a technique, or a degree of automation.

Notice also that they do not say the same thing, and vendors who flatten them into one requirement are the ones to distrust. PCI DSS is the only one of the three that states qualification and organisational independence in terms. SOC 2 reaches similar ground indirectly, through points of focus on evaluator knowledge and objectivity, and through the service auditor's own obligation to assess the competence and objectivity of anyone whose work they rely on. ISO is silent on independence at the control level and leaves it to your testing programme, which is why your certification auditor asks who performed it and how you assured yourself of their competence.

Where all three converge is attributability: somebody has to be identifiable as the author of the conclusion. That lands on a person or a firm, because it is a property of a party rather than of a process. A tool can be qualified in the loose sense of being good at its job. It cannot be organisationally independent of you, because it has no organisation, and it cannot be the attributable author of a conclusion, because attribution requires someone who can be held to it. That is why a more capable model does not move these clauses: it makes the testing step cheaper and better, and these requirements sit outside the testing step. For the clause-level walkthroughs, see SOC 2 pentest requirements and PCI DSS 4.0 pentest requirements.

The questionnaire test

For the shortest version, skip the frameworks and look at the enterprise security questionnaire in your inbox. It asks for a third-party penetration test conducted in the last twelve months. Third party is an independence requirement. Penetration test is a methodology requirement. Last twelve months is a recency requirement. A model finding a zero-day satisfies none of the three, however good the finding is. That is not a criticism of the model, it is a description of what the question asks for.

What Security Leaders Should Do This Quarter

Concrete actions to review this quarter, in rough priority order.

⬜Re-examine your patch SLA for internet-facing assets. If it assumes two weeks between disclosure and a viable exploit, rewrite it. Set the external target in days. Our free CVE lookup shows severity and exploit status for the advisories affecting the software you run.
⬜Rebuild your internet-facing asset inventory. Compressed timelines punish unknown assets hardest, because you cannot patch what you have not enumerated. Our free subdomain finder enumerates what is publicly resolvable under your domain in a few seconds. Do this before you buy anything.
⬜Check whether your last pentest report names a signer. Open the PDF. Is an identified individual or firm attesting to the scope and conclusion, with stated qualifications? If not, you hold a scan output, and you will find that out during an audit rather than before one.
⬜Confirm your evidence artefacts contain reproducible proof. Pick three findings from your most recent report and try to reproduce them from what is written. A severity rating and a CVE number with no captured request and response cannot be independently verified.
⬜Specify the autonomy level you will accept in your next testing RFP. Do not ask vendors whether they use AI; everyone says yes and it tells you nothing. Ask what runs autonomously, what a human reviews, and who signs. The vocabulary is in our agentic pentesting guide.
⬜Move retest into the original scope. PCI DSS 11.4.4 already requires retest after remediation, so make sure yours does not require a second statement of work.
⬜Brief your board on the bounded version. Exploit development got faster, so patch windows shrink. That is accurate. "AI is breaking into hardened enterprises at will" is not, and overstating it costs you credibility on the next ask.

Where CyberOrbit Fits

You configure the targets you want tested. The CyberOrbit platform scopes, schedules and runs the assessment across 25+ specialist scanners and AI-driven exploit chains. A certified security professional then reviews the completed assessment and signs the report you select.

Every finding carries evidence captured from real traffic: the actual HTTP request sent, the actual response received, reproduction steps, a timestamp and a proof hash over the capture. Not model-generated descriptions of what a vulnerability might look like, but captures from requests genuinely made against your systems. That is the reproducible proof the checklist above asks you to go and look for in your own last report.

Be plain about the boundary, because this post has spent several thousand words arguing against overclaiming and we do not get an exemption from that. We handle the systematic 80%: the injection, access control, configuration, exposed surface and known-CVE classes that reward breadth and repetition across every in-scope host. Novel business-logic abuse, the multi-step authorisation flaw that depends on knowing what your application is for, still needs a specialist who has lived in it for a fortnight. If your application moves money or manages multi-tenant permissions, budget for that separately. We would tell you so at scoping rather than sell around it.

One more boundary, and it is the one that matters for the clause table above. The assessment tests your external, internet-facing perimeter. Private and internal IP ranges are blocked at assessment creation, so the report evidences PCI DSS 11.4.3 (external penetration testing) and not 11.4.2 (internal), 11.4.5 or 11.4.6 (segmentation). Those need separate testing and the report says so on its face rather than leaving you to discover it in front of your QSA.

Pricing is fixed at AUD $7,999 ex GST for an on-demand Standard assessment of up to 50 endpoints, delivered within 48 hours of scope sign-off, with one free retest included. Findings are cross-referenced to ISO 27001:2022, SOC 2, PCI DSS v4.0.1, CIS Controls v8 and the ACSC Essential Eight, so one assessment feeds several compliance programmes. It is a technical evidence artefact for those programmes, not a certification against any of them. Full tiers are on the pricing page.

To start smaller, our free external security check runs against your own domain and shows what an attacker sees from the outside. It reads exposure rather than attesting to it, so it serves the inventory and patch-SLA items on the checklist, not the signature question.

Every tier is published, including what is in scope and who signs. Fixed price, no scoping call required.
See what a signed, audit-ready report costs

Frequently Asked Questions

What is OpenAI Astra's Critical cybersecurity threshold?
Critical is the highest cybersecurity capability tier in OpenAI's Preparedness Framework, reached when a model can, without human intervention, identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems, or devise and execute end-to-end novel strategies for cyberattacks against hardened targets given only a high-level desired goal. OpenAI announced on 1 September 2026 that Astra is the first of its models to reach it. The classification is OpenAI's own internal assessment against its own framework, not an external certification, and no published methodology allows a third party to rerun it.
Can OpenAI Astra find zero-day vulnerabilities on its own?
According to OpenAI's published evaluations, yes, under evaluation conditions and in one specialist domain. Astra scored 100% on ExploitBench, which measures turning known vulnerabilities into working exploits, up from 78.5% for GPT-5.6 Sol. Separately, while working an internal port of that benchmark built from 20 high-severity V8 flaws, it found and used two previously unknown vulnerabilities as part of an exploit chain, which OpenAI says it is disclosing to the maintainers. V8 is Chrome's JavaScript engine, so the demonstrated skill is memory-safety exploit development against a C++ codebase, not application-logic bug hunting across arbitrary estates. OpenAI did not claim routine autonomous compromise of production environments, and the most advanced cyber capabilities are restricted at launch to a small group of vetted alpha testers.
Does an AI finding zero-days change SOC 2 or PCI DSS penetration testing requirements?
No. SOC 2 CC4.1 calls for ongoing and separate evaluations to ascertain whether controls are present and functioning, with the supporting points of focus naming knowledgeable personnel and objective evaluation; SOC 2 never names penetration testing as such. PCI DSS v4.0.1 is the most explicit: 11.4.3 requires external penetration testing at least every 12 months and after significant change by a qualified, organisationally independent tester, 11.4.1 requires a documented methodology, and 11.4.4 requires correction and repeat testing. ISO 27001:2022 A.8.29 requires security testing in development and acceptance to be defined and implemented, and says nothing about independence. None of them restricts what tooling performs the testing, and what they do turn on, attributability of the conclusion to an identifiable party, is unaffected by model capability.
Do auditors accept a penetration test performed by an AI?
The relevant question is not whether AI performed the testing but whether the result is attributable to a qualified, independent party. Auditors assess the competence and objectivity of the evaluator and the adequacy of the evidence. A report containing reproducible evidence and signed by an identified, qualified professional independent of the tested organisation meets that bar regardless of how much was automated. Unsigned raw tool output, produced by the organisation against itself, generally does not, because it is self-assessment.
What should security teams do after the Astra announcement?
Revisit patch SLAs for internet-facing assets, since the assumption that a working exploit takes weeks to appear after disclosure has lost its safety margin. Rebuild the internet-facing asset inventory. Check whether your most recent pentest report names a signer and contains reproducible evidence. Specify the acceptable autonomy level and the named signer in your next testing RFP. Resist reallocating attention away from credential hygiene and perimeter patching, which remain the dominant initial access vectors.
Is a signed pentest report still necessary if AI can find vulnerabilities?
Yes, and arguably more so. A finding establishes that a condition exists and is verified by reproducing it. An attestation establishes that a defined scope was competently and independently tested, backed by the identity, qualifications and accountability of the signer. As machine-generated findings become abundant, the finding stops being the scarce input and the signature becomes it. A model cannot supply attestation because it holds no credential, carries no professional accountability, and cannot be questioned by an audit committee.
You configure the targets. CyberOrbit's platform scopes and runs the assessment, and a certified security professional independently reviews and signs the report you select. Fixed AUD $7,999 ex GST on demand, delivered within 48 hours of scope sign-off, retest included.
Get an independent pentest report your auditor will accept, in 48 hours

Sources

#OpenAI Astra#AI zero-day discovery#autonomous AI security testing#Preparedness Framework#AI pentesting#audit evidence#threat analysis

The security writing, weekly

New posts as they land: findings from real assessments, what the regulatory changes actually mean, and the occasional teardown.

Privacy

More from CyberOrbit

View all posts
Comparisons

CyberCX Alternative: AU Pentest Options Compared 2026

CyberCX and CyberOrbit compared on what you can check before you buy: published price, self-estimable scope, and evidence standards.

CyberOrbit TeamSep 15, 2026 · 29 min read
Security Research

Verifying AI-Generated Code: Why Green Tests Prove Nothing

AI-generated code passes tests. Five real cases where it was inert: present, plausible, green on every gate, and doing nothing. How to verify by removal.

CyberOrbit TeamSep 7, 2026 · 19 min read
Security Testing

Only 9% Trust AI Pentesting Alone. Here's What the 91% Want

Trust in fully autonomous AI pentesting fell from 29% to 9% in a year. What the data measured, why it collapsed, and how to specify autonomy levels in an RFP.

CyberOrbit TeamSep 2, 2026 · 30 min read