AIR AI is an automated cyber incident response capability for the defense industrial base and federal agencies. It detects, decides, and proposes containment in seconds. It holds no credential on your systems: execution happens in a separate layer, only inside a scope an incident commander pre-authorized, and every action is reversible and recorded.
Built for Department of War, Defense Industrial Base, and Federal, State, Local, Tribal and Territorial programs. In development: the authority gate, ledger, correlation engine and REL command contract are built and unit-tested in memory. PIV/CAC signing is not implemented and there is no persistence. Nothing is deployed in a customer environment.
See how the authority model worksLooking for an incident response plan rather than automated response? That is a different product, at ai4ciso.ai/incident-response.
An intrusion moves faster than a signature block. The usual answers are both wrong: make a human approve every step and containment arrives after the damage, or let the detector act on its own and you have handed an automated system unsupervised authority over production. AIR takes neither. A commander grants a bounded scope ahead of time, and a separate execution layer checks every proposed action against that scope at the moment it would run.
Correlates signals into an incident and proposes the containment it believes is warranted. It holds no credential on any customer system, so it cannot act on its own conclusion.
A separate layer holds the credentials, verifies the proposed action falls inside the granted scope, performs it, confirms it held, and reverses it automatically if it did not. REL AI™.
CMMC scope, CUI boundary and control posture come from Enclave AI™, so AIR knows which assets carry CUI and which can never be touched automatically. Incidents return as control evidence.
Every decision, authorization, action and reversal is written ahead to a tamper-evident log. What was done, under whose authority, and how to undo it are answerable after the fact.
What that buys a program. Compliance enforcement stops being a document and becomes a change that was actually made, at every tier of the supply chain, without loosening the authorization baseline that made it defensible. The smaller the supplier, the more this matters, because there is no security staff on shift at 2am.
Status, stated plainly. Built and unit-tested, in memory: the authority gate, the hash-chained ledger, the correlation engine, the step that turns a correlated incident into proposed containment, the containment bounds, and the REL command contract, whose signed-grant digest is proven byte-identical to REL's own. Not built: PIV/CAC signing and the verifier that would check a signature against real trust anchors, so the shipped verifier covers no grant and every action routes to a human; persistence, so state is in memory only; the network transport into REL; detection connectors; investigation and compliance reporting. Nothing is deployed in any customer environment, and no part of it has processed real data. Engagements are provisioned individually, under your authorization.
"Automated" does the wrong work if it suggests nobody is in charge. A commander grants a bounded scope in advance: which actions, against which classes of asset, at what confidence floor, up to what reversibility ceiling, expiring on a date and revocable instantly. That is a deliberate act by a named person, recorded before anything runs, and the machine then works inside that scope and nowhere else. Binding the grant to the commander's PIV/CAC signature is the design. It is not yet implemented: the shipped verifier validates no signature, so no grant covers anything today and every proposed action routes to a human. The gate was built to fail in that direction deliberately.
No covering grant means a human decides. An irreversible action means a human decides. A protected asset means a human decides.
An asset whose protection status cannot be established is not treated as unprotected. Missing information reduces what the system may do on its own, never widens it.
There is no flag, environment variable or configuration that lets an action execute without either a covering signed grant or a person. A test asserts this against the source itself.
If one system detects an intrusion, concludes what to do, holds the credentials and executes, then its authority is exactly as good as its worst false positive and nothing outside it can refuse. So the responsibilities are split, and the split is enforced by credentials rather than by policy.
Holds asset scope, the CUI boundary and control posture, so the response layer knows which systems carry CUI and which may never be touched automatically. Authorizes nothing. Incidents return to it as control evidence.
Correlates separate weak signals into one incident with a confidence level and a written rationale, then proposes the containment it believes is warranted. Holds no credential on any customer system, so it cannot act on its own conclusion.
Holds every execution credential and the rollback. Verifies the grant covers this action against this target right now, performs it, confirms it held, and reverses it if it did not. Originates no action of its own.
And the ledger records. Every decision, authorization, action and reversal is written to an append-only hash-chained log before it takes effect. What was done, under whose authority, and how to undo it stay answerable afterwards, to a commander, a regulator or a court.
Enclave AI determines which systems are in scope, which handle CUI, which can never be touched automatically, and where the control posture stands today.
Ordinary bounded authority: isolate a workstation, revoke a session, disable an account. Not the domain controller. Nothing irreversible.
Separate weak signals become one incident, with a confidence level and a rationale a person can read.
REL verifies the grant covers this action against this target at this moment, executes, confirms it held, and reverses it if it did not.
What happened, who authorized it, what was done, whether it worked, and how to undo it.
The response becomes control evidence. Compliance stops being a document about what you would do and becomes a record of what was actually done.
All three components install together inside your own accreditation boundary: on-premises, your government cloud tenancy, or air-gapped. Your ATO covers the capability as one system. Nothing operational transits any commercial service.
No telemetry, no license check, no update poll. Not disabled by default: absent. The enclave runs correctly having never contacted us, and you can verify that in a network-isolated harness rather than taking it on faith.
The three components ship, upgrade and roll back as one. A mixed-version install is refused at startup, because a decision layer and an execution layer that disagree about how authority is encoded would quietly stop authorizing anything.
Systemic supply-chain vulnerability is not primarily a prime-contractor problem. It is thousands of small suppliers with no security staff on shift at 2am. A capability that only works where there is already a security operations center does not reduce systemic risk, it concentrates protection where protection already exists. The small supplier gets the same authority model and the same reversibility as the prime, because the pre-signed scope is what substitutes for staffed night coverage.
Rapid automated execution and an uncompromised baseline are usually traded against each other. They are reconciled by moving the human decision earlier rather than deleting it: the baseline is enforced at execution time, against authority a person signed at leisure. No control is relaxed to reach the small supplier. A tier of the ecosystem that could only be served by lowering the bar is a tier that is not yet served.
Every autonomous security product on the market today is software your analysts operate. That is a fine model if you have analysts. A forty-person supplier carrying a CUI obligation does not have a security operations center, will never hire one, and cannot run a console at two in the morning. This is the reason enterprise security tooling has never reached the bottom of the supply chain, and it is not a pricing problem.
Not a dashboard that shows you what to do. Correlation, judgment, the proposal, the execution, the rollback, and the record are the agent's job. Nobody has to be watching for it to run.
The commander signs the scope in advance and rules on anything outside it. Executive decisions stay with your people. What they stop doing is operating the machinery underneath those decisions.
Every incident arrives as a written record: what was seen, what was decided, under whose authority, what was done, and how to undo it. That record is also the control evidence your assessor asks for.
This is operational leverage, not a smaller team. It gives an organization with no night shift the coverage a night shift would have provided, and gives a commander control they cannot exercise by hand at machine speed.
Available today. Scope, CUI boundary and control posture, in production at ai4cmmc.ai.
Available per engagement. The execution and rollback engine is built and running. See ai4rel.ai.
In development, provisioned per engagement. The authority gate, the hash-chained ledger, the correlation engine, containment proposal and the REL command contract are built and unit-tested in memory. PIV/CAC signing and signature verification are not implemented, so every action routes to a human. There is no persistence, no network transport into REL, no detection connectors, and no investigation or compliance reporting. Nothing is deployed in any customer environment.
No customer or agency is named anywhere on this site, and no adoption or performance figures are published, because there are none to report yet. When there are, they will be stated with the same precision as the limitations above.
Every proposed action passes a single authority gate before it can reach any system. The gate evaluates the kill switch first, so no grant can outvote it, then refuses anything it cannot reason about: an unknown action type, a clock that has jumped, revocation data too stale to trust, a protected asset, or an asset whose protection status is unknown. Only then does it look for a covering grant. Any error, ambiguity or unavailable input produces a denial, and the decision is written to the ledger before the caller can act on it.
No. There is no auto-approve mode and no configuration creates one. Actions execute either inside a scope a person signed in advance, or after a person approves them individually. A test asserts the absence of any such path at source level, because a behavioural test only proves that a given path was not taken this time.
Not AIR. The deciding layer holds no execution credential for any customer system, which is why it cannot act on its own conclusion. Credentials live with the execution layer alone, in a store the decision layer cannot read. That separation is enforced by process and credential boundaries and asserted by test.
Reversibility is a precondition, not a remedy. A grant carries a reversibility ceiling, and an action that exceeds it stops for a person regardless of confidence. The execution layer confirms an action held and reverses it automatically if it did not, and the ledger records what to undo and how.
That is the design target rather than a later option, and the honest answer today is that it is not yet demonstrable. The enclave is designed to install with no network access, to verify commander signatures against trust anchors provisioned at install, and to run the full response loop with the coordination plane unreachable. Signature verification is not implemented, and without detection connectors there is no live response loop to run offline. Federation is additive by design and never a dependency. What is verifiable today is the absence of any callback: nothing here phones home, emits telemetry or checks a licence at run time, and absent is stronger than disabled.
No. The DHS/US-CERT Project AIR executive summary is the requirements baseline this capability is modelled on. AIR AI™ is a separate commercial capability built to that concept of operations. We do not claim the program name as a product name.
Different product, different buyer. The readiness assessment, plan, playbooks, notification matrix and tabletop kits are at ai4ciso.ai/incident-response, priced from $1,495 by organization size. AIR AI is not a document generator.
Engagements are scoped individually against your accreditation boundary, your authorization posture and the systems you need covered. Tell us the program and the environment, and we will tell you plainly what is ready today and what is not.
Start the conversation