Most enterprise AI security programmes are built around one threat and are surprised by the other.
The programme that starts with "our AI systems could be manipulated" builds model safeguards and misses the infrastructure. The programme that starts with "AI accelerates attackers" builds detection and misses the encryption deadline. Both are half a strategy, and half a strategy tends to be discovered at the worst possible moment.
This is a framework for holding both at once.
First: name the two attackers precisely
Vague threat language produces vague architecture. Be specific.
Attacker one is autonomous AI, and it is operating now. The cost of a competent attack has collapsed. What once required a skilled team, months of reconnaissance and real funding now requires an open-weight model and an afternoon. Frontier-capable models are downloadable. Variants ship without the restrictions their originals carried.
The decisive property is not sophistication: it is speed and cheapness. It is fast enough to finish before a human responds, and cheap enough to be pointed at organisations that would previously not have justified the effort.
Attacker two is harvesting your encrypted traffic and waiting. Nation-state actors are collecting encrypted enterprise data today. They cannot read it. They are storing it against the maturity of quantum computing, at which point a decade of traffic becomes readable in one event. Harvest now. Decrypt later. Exploit forever.
This one comes with a date. CNSA 2.0 mandates post-quantum cryptography from 2027, and Canada, the EU, the UK and the UAE follow.
Buy AI security today and you replace it in 2027. Buy quantum security today and you are undefended tonight. The only escape from that trade is not making it.
Second: accept what this does to your response model
Every security tool an enterprise owns was designed to alert a person. That is not a flaw in any specific product; it is the shared assumption underneath the entire category.
Against attacker one, that assumption fails arithmetically. Enterprise response time is measured in hours. Autonomous attack time is measured in seconds. Adding analysts changes the number without changing the outcome: arriving in twenty minutes instead of forty is the same as arriving in forty when the attack took ninety seconds.
The framework implication: anything that requires a human decision in the response path is not a control against attacker one. It is valuable for investigation, reporting and improvement. It is not a control. Classify your tooling honestly on this basis and the gaps become obvious quickly.
Third: identify your real exposure order
Two sentences determine where you are most at risk.
The organisations running AI are exposed first. More AI systems means more machine-to-machine traffic, more credential-dense infrastructure, and more surface that human-centric controls do not govern.
The organisations holding long-lived data are exposed longest. If your data stops mattering in six months, harvest-now-decrypt-later is a modest concern. If you hold health records, financial histories, legal matters, government material or intellectual property, the data you transmit today is still valuable when it becomes readable.
Most enterprises worth attacking are in both categories. Governments, critical infrastructure, telecommunications, financial services, healthcare and large enterprises generally qualify on both counts.
Fourth: choose an enforcement point, not a product set
Here is where most programmes go wrong, and it is a structural error rather than a judgement error.
The natural instinct is to buy per problem. An AI security tool for attacker one. A cryptographic migration programme for attacker two. An identity product for machine identity. A compliance platform for the evidence.
Four purchases, four integrations, four sets of coverage gaps between them, and the AI tool bought in 2026 will not be what satisfies the 2027 encryption requirement, so one of the four gets replaced almost immediately.
The alternative is to choose the position first. Both attackers converge on the same thing: the connection. Attacker one moves through connections. Attacker two harvests connections. A control point every connection passes through addresses both by construction.
That is what a cybersecurity gateway is. Nothing enters, nothing leaves, nothing moves between systems without passing through it. There it stops autonomous attacks in seconds, applies quantum-safe encryption to every connection, governs machine identities, enforces policy automatically, and generates audit evidence for every mandate.
At Conux, five AI agents run that loop: detect, block and write the rule, harden, log the evidence, orchestrate. Detect. Block. Adapt. Prove. No queue. No analyst. No delay.
Fifth: weight deployability as heavily as capability
The most common cause of an unimplemented security strategy is not that it was wrong. It is that it required too much disturbance to start.
A programme that demands re-platforming gets scoped, costed, deferred, and quietly replaced by something smaller. Evaluate accordingly: what does this require me to rip out?
The answer should be nothing. Existing cloud. Existing identity. Existing applications. Existing AI models. A gateway sits in the middle of what is already there, deploys in weeks, and is invisible to users. One deployment, not two migrations.
The framework in five lines
- Name both attackers explicitly: autonomous AI now, harvest-now-decrypt-later by 2027.
- Reclassify any control that requires a human in the response path; it is not a control against attacker one.
- Rank your exposure: running AI means exposed first, long-lived data means exposed longest.
- Choose the enforcement position before the product list: both attackers converge on the connection.
- Weight deployability equally with capability, because undeployed security protects nothing.
Applying the framework: a sequenced first quarter
A framework that cannot be started on Monday is a position paper. This is the sequence that follows from the five points above.
Establish the connection map before the tool list. Point four says choose the enforcement position first, which requires knowing what connects to what. Prioritise machine-to-machine paths and anything touching AI infrastructure: those are the least documented and the most exposed. Expect this to surface forgotten endpoints and over-scoped service accounts; that is the exercise working.
Run the honest classification. Take the existing security stack and mark each control: does it act, or does it alert? Report the result to leadership plainly. This is usually the moment the timing arithmetic becomes real, and it does more to unlock a decision than any threat briefing.
Pick the first enforcement scope by exposure, not by ease. Point three gives the rule: organisations running AI are exposed first. For most enterprises that means AI infrastructure is the correct starting scope: newest, busiest with machine traffic, least governed. Place the gateway there, verify machine identity per connection, and enforce a deliberately narrow policy.
Turn on quantum-safe encryption in the same scope immediately. Not as a later phase. Once traffic passes through a single point, this is configuration rather than a migration, and it starts closing the harvest-now-decrypt-later window on your most sensitive traffic while the 2027 deadline is still comfortably ahead.
Then widen by the same pattern. East-west traffic, then edge, then remaining application groups. Each extension reuses the same policy model and the same evidence pipeline.
What to report upward. Two numbers tell the story to a board: the proportion of connections now passing through enforcement, and the proportion carrying quantum-safe encryption. Both are unambiguous, both move monotonically, and both map directly to the two attackers. Coverage percentages are far more useful to a non-technical audience than incident counts, which measure luck as much as posture.
The bottom line
The failure mode in enterprise AI security is not choosing the wrong product. It is building a programme around one attacker and being surprised by the other.
Name both explicitly. Classify your controls by whether they act or alert. Rank exposure by whether you run AI and how long your data stays sensitive. Choose the enforcement position before the shopping list. Weight deployability as heavily as capability.
Do that and the architecture follows almost automatically, because both attackers converge on the connection, and a control point that sees every connection answers both in one deployment.
