A lot of the AI cybersecurity conversation is focused on offence.
Models are getting better at reading code, finding vulnerabilities, and chaining exploitation steps with more autonomy. Claude Mythos was the latest public signal that made me stop and think. Not because I have access to it, but because it shows where this is probably going.
If offensive AI gets faster, does defence just keep waiting for alerts in dashboards?
It is not only about models finding bugs. It is about what happens when that capability becomes cheap, automated, and available to more attackers. When reconnaissance, exploitation, and persistence can be scaled with AI, smaller operators get exposed first.
This idea kept me awake:
What if Claude Mythos could "live" inside the machine, but as a defender?
Not in a chat window. Not only in a dashboard. Not only do you have to wait for a vendor cloud.
Inside the server, with sensors, memory, context, and a small set of controlled actions.
That is the idea behind InnerWarden, an open-source autonomous defence agent for Linux servers, written in Rust under the Apache-2.0 license.
The easiest way to explain it is from the perspective of an AI layer running on a host.
It needs eyes.
InnerWarden watches signals from the machine: authentication events, Docker, process trees, network activity, file integrity, web logs, and kernel-level activity.
It needs memory.
It keeps local state about incidents, attacker profiles, process lineage, login patterns, kill-chain progress, previous decisions, and correlated events. Decisions are stored locally, with an audit chain that makes tampering and gaps visible instead of hiding them.
It needs reasoning.
The AI layer should not just receive random alerts. It should be able to ask: is this just a failed login, or part of a brute-force campaign? Does this process look like a reverse shell?
And it needs hands.
That is the scary part.
I do not want to give an AI loop unrestricted root on a production server. InnerWarden is built around controlled defensive actions: block an IP, kill a process, suspend a user, isolate a container, raise monitoring, or notify the operator.
Those actions are policy-gated.
Dry-run is the default. Autonomous blocking has to be explicitly enabled. Operators choose which skills are allowed. Trusted IPs can be protected. Circuit breakers help reduce false positives. Every decision is written to an audit trail, so the operator can inspect what happened and why.
This is the part I think is not discussed enough.
Big companies can buy another EDR, MDR, SIEM, or managed SOC contract.
But what about the person running a few servers? The small business with no security team? The public agency without enterprise security budgets? The open-source maintainer running infrastructure on a VPS?
Those machines are attacked too. They become entry points. They become botnet nodes. They are used to attack other people.
Often, the real choice is rough: logs nobody has time to read, scripts glued together over the years, or black-box SaaS the operator cannot inspect.
I do not think that should be normal.
Maybe the shape is close to Autonomous Endpoint Defence and Response: observe, correlate, decide, and act inside strict policy limits.
The goal is not to replace human security teams. It is to give people who do not have one a serious defensive layer they can run locally, inspect, understand, and shut down.
Autonomous defence should not mean handing the keys to the house to a black box.
It should mean the opposite.
More control for the operator. More transparency. More auditability. More local capability for the people who are usually left unprotected.
An AI with eyes, memory, and controlled hands inside the server, without handing over the keys to the house.
Repo: https://github.com/InnerWarden/innerwarden
I would be interested in feedback on the response-skill defaults, dry-run model, and audit-chain design.
Top comments (0)