Every time a new AI model reaches the market, the security industry braces for impact. Slack conversations spike, budget requests are drafted, and teams scramble to assess their exposure. Yet according to Alan LeFort, CEO of StrongestLayer, this reactive posture is fundamentally misguided. The problem is not that AI capabilities leap forward unpredictably; it is that security teams treat each event as a surprise when the trajectory has been clear for years. The real challenge lies in the decay of security defenses, which erode at different speeds as model capabilities advance.
The Predictable Curve of AI Capabilities
LeFort argues that AI model releases are not step changes but points on a steady curve. GPT-4 made scalable phishing a reality. DeepSeek-R1 delivered strong reasoning at far lower cost and appeared in attacker tooling within days. Now Anthropic's Mythos has triggered the same cycle. Each model feels groundbreaking, but the pattern is consistent: every nine to fourteen months, attackers receive a meaningful upgrade. Defenses lag because they are built on slower cycles of procurement, validation, and deployment that stretch over months or years. By the time security systems go live, their assumptions are already outdated. This is not a tooling gap; it is a mismatch in timelines that compounds with each release.
Attackers Without Constraints
When a better model becomes available, attackers adopt it immediately. There is no approval chain, no stability requirement, no compliance check. Defenders operate under entirely different conditions. Vendors select a single model, train it on known threats, validate extensively, and ship a product that customers expect to last for quarters or years. The result is structural lag. Detection systems end up reasoning with outdated assumptions against threats that evolve in real time. Not all layers fail at the same rate. Content-based detection breaks first because the attacker's output improves fastest. Behavioral signals hold up longer because people do not change how they work as quickly as models change how they write. Most teams do not know which parts of their stack fall into which category, and that ignorance is itself a vulnerability.
Better models make attacks more fluent but not more grounded in reality. Attackers still infer how an organization operates from public data and guesswork. They do not know approval flows, vendor relationships, or executive behavior. A phishing email can read perfectly and still request something an organization would never do. A fake invoice can look legitimate and still break every real payment pattern. The signal that exposes the attack does not live in the content; it lives in the systems, the identity records, the communication history, the calendars, the workflows. Attackers approximate those patterns. If a detection stack ignores that advantage, it is choosing to compete on the attacker's terms.
What Breaks at the Next Threshold?
Most teams ask whether their current tools can detect the latest class of attack. That question is short-sighted. The next model will arrive within a year. The critical question is what breaks then. Some parts of the stack will hold up; others will reset. Content matching will continue to reset because it always has. Retraining helps, but it keeps the organization reactive. Behavioral signals last longer because underlying patterns persist. Organizational context lasts the longest because it operates on facts the attacker cannot access. That durability comes with cost. Deep context requires integration into identity systems, workflows, and records, introducing governance and maintenance overhead. There is no clean solution, only tradeoffs that decay at different rates. Security teams tend to chase better models because that is what vendors sell, but models decay quickly. Signal access compounds. If detection logic is mostly content-based, the organization is relying on the same surface the attacker controls. If it pulls from identity, behavior, and workflow context, it gains an advantage that improves over time as those signals grow richer with organizational operations.
Developers: What Can You Maintain?
Custom models trained on last year's data will not hold up unless retrained constantly, which most teams cannot support. Deep integrations require ongoing updates as organizations change. Every approach carries a maintenance cost. The question is not which approach is ideal but which one fails more slowly under real constraints. Most teams never ask that question and end up overinvesting in layers that degrade quickly. LeFort emphasizes that transparency is essential: security teams need to know why something was flagged, not just a score or label. They need actual reasoning about which signals triggered the alert, what context the system used, and what inconsistency it identified. If a vendor cannot explain that clearly, there is no way to evaluate whether the system will survive the next capability jump. Transparency is not optional; it is the only way to separate real architecture from marketing. Mythos feels like a step change, but it is another point on a curve that still has years left. Teams that keep reacting to each release will stay behind. Teams that adapt will change how they build, designing systems that hold up as models improve and investing in signals attackers cannot access.
CEO Deep Dive: Key Insights
In an extended discussion, LeFort provided further depth on how organizations should address the decay problem. When asked about the growing lag between attacker capability and defender tooling, he explained that once finding a vulnerability drops from months to days, annual pen-tests and compliance checkboxes stop providing safety. Three moves follow: match the clockspeed by moving code review and testing from once-a-year events to continuous habits; prioritize by risk because not everything can be tested at once; and put AI to work defensively to stay in sync with accelerating attackers. Internal software is exposed through dependencies, libraries, and packages that are attacked constantly, so testing must be as frequent as the threats.
On the topic of redesigning application security around behavioral signals, LeFort clarified that it is not an either-or decision. Both pattern matching and behavioral signals have their place. Pattern matching is fast, precise, and cheap for known vulnerabilities tied to specific coding patterns. But it cannot tell whether software is being used as intended. That is the job of intent signals, which catch exploitation in progress and changes that quietly shift a program's purpose, including those arriving through a dependency. Defining normal behavior sounds open-ended, but the scope can be limited: start with the two or three most sensitive services, baseline from existing logs, and treat a deviation that can be explained as proof before expanding. Pattern matching closes the gaps that can be named; intent catches the misuse that could not be anticipated.
LeFort also addressed governance and traceability in software pipelines when AI models are constantly changing. He emphasized that the model inside a vendor's black box cannot be pinned, so everything around it must be pinned by contract and on the organization's own side. Contracts should require model and version pinning, advance notice of changes, and the right to test before a swap reaches production. The organization must log every decision with the model and version the vendor asserts, keeping that record in a place that survives the model being replaced. This rides on existing change-control processes rather than standing up a parallel system. If a swap silently changes behavior and the organization cannot trace it, that is hope, not governance.
Finally, LeFort discussed how buyers should evaluate vendor transparency. A score is not an explanation, and a scripted walkthrough is easy to rehearse. The test is to bring an example the vendor has never seen and make them explain it live. Hand them a known false positive and ask why the system was wrong. A real architecture shows which signal misfired; a rehearsed one deflects. Then ask what signal the system would have missed and what it retrains on when it does. Vendors who understand their own system answer all three questions. If the explanation only holds on the examples they chose, the architecture will not survive the next capability jump. Transparency is a durability indicator. The curve does not slow down for anybody's roadmap, so developers must build accordingly, investing in systems that age gracefully rather than decay each time a new model appears.
Source: Computerweekly News