Rethinking future anti-intrusion systems and products

Article title: Reflections on a Future Anti-Intrusion System and Product

Body:

0. The Essence of Security

Security here refers to anti-intrusion in the narrow sense, such as foundational security and application security, which I consider to be:

Executing expected logic within an expected environment

What we have done in the past—baselines, hardening, vulnerability response, and so on—serves the "expected environment," while intrusion detection and the like are performing partial detection of "unexpected execution logic."

1. How to Redefine "Expected Logic"

In the past, the main detection of "unexpected behavior" fell into a few categories:

• Blacklists and behavior detection based on known attack techniques and signatures, along with some other approaches to improve accuracy, such as behavior sequence detection;

• So-called "self-learning, adaptive" detection or anomaly detection via traditional machine learning and statistical methods.

In the AI era, perhaps we can solve this problem from a more fundamental source. When we want to know, for a given Artifact as seen from the Linux Kernel layer, which paths it needs to access under normal business logic, what permissions it needs, which internal services it needs to access; from the perspective of traditional API security, how permissions are defined and how sensitive data is passed; from the DB Proxy perspective, which tables it should access, which fields, and what the corresponding permissions are—

In the past, these answers might have required a long window of "learning" plus manual confirmation, or reliance on certain internal processes, but now they can be confirmed through AI-augmented code scanning plus reading CI/CD stage configuration files.

In the AI era, when an Agent can already answer, at the configuration-file level, what the "expected logic" of a given version of an Artifact is, perhaps "intrusion detection" itself will no longer be work centered on signatures and anomalies.

2. There Is Always the "Expected Within the Unexpected"

Of course, the above can only target Artifact-type things. When the permissions of the server, cloud, or application itself are lost, how do we identify the operations brought by attackers and Living-Off-The-Land attacks?

My answer is: real-time intent detection. Ultimately we still need the detection system to truly understand a Telemetry Log or Audit Log, because intrusion detection itself is about truly understanding what a command is doing, and achieving high-performance, stably reproducible detection (I remember when I was an intern writing NIDS policies and really had no idea how to handle policy construction for some intrusion scenarios, I would helplessly joke that we should just stuff Gaba into a box and have him look at it).

And this obviously cannot be hoped for from Regex, statistics, or LLMs, nor from literally stuffing a security engineer into a box. Look at the following examples:

• grep 'password' and grep 'P4sswd'

• grep 'password' and grep 'password incorrect'

• grep 'password' and grep -v 'password'

Neither Regex nor statistics can accurately distinguish the subtle differences among them, and LLMs find it very hard to achieve real-time or near-real-time detection.

So half a year ago I implemented an experimental project: https://github.com/EBWi11/SecEBL, a small fine-tuned Embedding model that can achieve 5.3k/s accurate labeling of Linux Cmdline or K8s Auditing on a single consumer GPU, producing labels such as read_system_config and search_credentials, thereby interpreting the intent of operations. Of course, all three cases above can be easily and accurately identified.

We have also seen the power of the later JEV model. I believe real-time intent detection will become a very promising direction, with enormous value in intrusion detection, Agent intent detection and fencing, and many other areas.

3. How to Ensure "Within the Expected Environment"

The above two parts answer, in my view, the definition of "expected behavior" and the detection of "unexpected behavior." I believe that at the Artifact level, if their permission configuration manifests can be automatically generated and automatically tested, the current runtime environment already has fine-grained control capabilities, for example using Linux LSM (with some optimization needed under certain high-frequency IO); and fine-grained access control at the API level is already a fairly basic WAF feature.

When an application can only run business logic, a considerable portion of the attack surface and traditional security problems will be eliminated. And if AI can help us achieve this zero-friction, high-accuracy Artifact configuration, that would be the ideal state—most application security vulnerabilities and 0day responses for dependency libraries would no longer be so passive.

4. What Will the Intermediate State Look Like?

I believe achieving all three points is very difficult and will be constrained by a host of real-world conditions, such as incomplete standardization, no unified CI process at all, chaotic dependencies that make it impossible to read the complete code, running production business whose source code location is completely unknown, and no mature Sandbox ecosystem to implement modern MAC (Mandatory Access Control), and so on. Therefore, for a long time we will probably still need to enhance our traditional intrusion detection and response systems—improving detection accuracy, increasing response efficiency, and so on.

In this direction I think everyone's thinking is aligned. Let me give some scenarios:

• After vulnerability intelligence confirms the impact, the Agent identifies affected assets based on scanners, host security assets, and so on, then logs into the servers to confirm processes, ports, and specific configurations, confirms whether they are affected, confirms the log paths, and then performs temporary log collection based on those log paths, building a temporary, real-time, high-accuracy detection system for whether that vulnerability has been exploited, which is automatically shut down once remediation is complete;

• Automated penetration testing + automated Patch generation + automated intrusion detection policy generation;

• Writing intrusion detection policies based on business context (rather than cookie-cutter generic policies) as well as alert response, achieving adaptivity (this word has been over-marketed for so long that people may no longer understand its original meaning);

This part will be very important for some time to come, because issues such as standardization and security fundamentals will cause most companies to rely more on post-event capabilities for quite a while (scenarios like risk control can only continue to rely on them even more). Therefore, for the past six months or so I have been researching the following directions:

• Data Agent: How to let an Agent process complex, large volumes of data to extract valuable business data? My current answer here is that at this stage it no longer needs separate consideration—CLI+Python is enough; instead, it is the traditional streaming and offline data architectures that need to be considered and balanced;

• RL: How to continuously learn from the real world to improve itself? My current practice here is to continuously train an FSM (Finite State Machine) + domain-specific Handbook through large numbers of simulated environments (for example, the internal dependency relationships of certain libraries, details of some RFCs, etc.), and then continuously optimize this FSM and Handbook through real environments. My weekend side project in July this year: https://github.com/EBWi11/Gusion is an experiment along these lines, ultimately achieving an ultra-low cost of about 0.5 RMB per Poc on average on Cybergym with an 87% score;

• Agent Communication & Organization Protocol & Dynamic Group Scheduling: this part is what I have practiced the least, though I have read a large number of papers. My conclusion at this stage is: Multi-Agent may not qualitatively improve task results, but parallelism will certainly improve task efficiency. I now probably lean more toward the current model of something like Claude Agent Teams + Reviewer Agent, with more focus on the design of structured Memory, FSM, FSM-RL, Evidence-Gated, and automated Tools optimization;

• Once again I sigh that engineering is indeed no longer the problem. How to design the architecture, how to build effective "loops," and how to have continuous opportunities to validate against real environments are now the most core parts.

I can't resist interjecting here: I believe the host side remains the most important battleground, bar none. In security scenarios, a large amount of context, business understanding (with authorization you can even pull things down and reverse them, can't you), execution of response actions, vulnerability emergency response, and so on all have to land on the host side. This is actually the same as back then, when it could cover the vast majority of container security scenarios. Even in the future AI era, the host side will remain the most important source of context extraction and response. The strategy of some teams of giving up host-side security products in order to focus on AI security is indeed hard to understand.

5. Final Thoughts

In the AI era, every day it's

"AI is about to replace me!"

"AI really can help us create value faster"

But now I've figured it out. There is no doubt that in the future AI will of course be omnipotent, but at least the future we envision has not yet arrived, so at this stage it is still up to us to work hard to drive that future into reality.