What if Claude Mythos-level AI lived inside the machine?

Maicon Ribeiro Esteves — Tue, 19 May 2026 11:02:05 +0000

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.

Inner Warden: A Lightweight Open Source eBPF EDR for Linux that Actually Blocks Attacks

Maicon Ribeiro Esteves — Sun, 10 May 2026 09:54:20 +0000

Inner Warden: an autonomous eBPF security agent that fights back

Most security tools only send alerts. Then someone has to wake up, read logs, and react.

Inner Warden does it differently. It detects, decides, and blocks threats in real time, locally on your server, with a tiny footprint of around 29MB.

What it does

40+ eBPF kernel hooks (tracepoints, kprobes, LSM, XDP)
Behavioral DNA tracking for processes and attackers
On device anomaly detection with a small autoencoder
Cross layer correlation between kernel, userspace, and network
Wire speed blocking through XDP
Automatic honeypot, JA3/JA4 fingerprinting, Sigma and YARA rules
Mesh network between nodes, so when one detects, all the others block
Dry run mode is the default, so it is safe to test

Who is it for

Self hosters and homelab people
Anyone running a Linux server exposed to the internet
Developers running AI agents (LangChain, CrewAI, OpenAI tools, and similar)
SREs and sysadmins who want autonomous response instead of 3am alerts

Live demo

You can watch a real server getting attacked right now here:

https://www.innerwarden.com/live

There are scripts on the page if you want to try the attacks yourself.

One command install

curl -fsSL https://innerwarden.com/install | sudo bash

It starts in dry run mode, so nothing is blocked until you decide.

DEV Community: Maicon Ribeiro Esteves