Post cover image

August 12, 2026

I Let an AI Agent Run Security Checks on My Own Infrastructure Every Morning, and It Found Things I…

The most honest security tool I run is not the one with the biggest dashboard. It is a terminal process that starts at 06:00 every day…

By Joao Silva

9 min read

The most honest security tool I run is not the one with the biggest dashboard. It is a terminal process that starts at 06:00 every day, scans seven VMs I actually own, writes a report, and says nothing at all if everything is fine.

It is called T3MP3ST; it is an LLM-driven security agent, and I use it the way most people use a scheduled MOT: check first, panic later, fix the stuff that fails. The difference is that the checking is autonomous, the evidence is saved to disk, and the thing refuses to touch anything it has not been explicitly told it may touch.

This article covers what the tool does, what a real daily run looks like, why the safety rails matter more than the tool count, and how the same agent pattern applies to your codebase as well as your servers.

None

The Tool, Without the Marketing

T3MP3ST is an open-source autonomous security operations framework, written in TypeScript, built to turn the AI coding agent you already run into a zero-day hunter. The upstream project, on GitHub under an AGPL-3.0 licence, has picked up serious traction in its first weeks: five and a half thousand stars and over a thousand forks since it appeared in July 2026. On my installation, the verified tool count is 102: 67 adapters wrapping external security tooling, plus 35 built-in capabilities. I know that number is right because the framework refuses to trust its own marketing; more on that in a moment.

The architecture has a design bet worth understanding: it is deliberately keyless. The LLM brain is whichever coding agent you already have, Claude Code, Codex, Hermes, or a fully local model through Ollama or LM Studio, so there is no second cloud tenant and no second bill. The framework supplies the arsenal and the mission control; your existing agent supplies the judgement.

What matters is the architecture:

  • A kill chain, not a script. Operations run through a chain of operator roles mapped to MITRE ATT&CK: reconnaissance, scanning, exploitation, infiltration, exfiltration, and ghost (post-exploitation cleanup), coordinated by two further roles, a coordinator and an analyst. Each phase has a status, and each can run independently or as part of a chain.
  • An MCP server. The agent exposes a JSON-RPC interface on localhost, which means it can be dispatched by another AI agent as easily as by a human with a terminal. My fleet's orchestrator hands it tasks directly.
  • A War Room UI. When you want to watch the operation live, there is a web interface at localhost, port 3333.
  • Evidence-led output. Every finding has an ID, a severity rating, a confidence level, an impact description, and a fix recommendation. Nothing is a claim until it has evidence and a retest.

The kill chain has two interesting design choices. The first is that the phases which do the actual breaking are behind human gates: exploitation and infiltration require explicit approval per action. The second is that the last two phases, exfiltration and ghost, are inactive by default in my configuration. The tool collects evidence, but it does not copy secrets, credentials, or recovered passwords into its evidence store, and it does not clean up after itself. Cleanup is a manual, operator-only operation.

That is not a limitation. That is the feature.

What a Real Daily Run Looks Like

I run a fleet of seven hosts across three network zones: a remote hosted VPS that carries most of my services, a Proxmox hypervisor and three Tailscale hosts, and two public and personal web and mail servers. Every morning at 06:00, a cron job runs the fleet assessment.

The assessment script does four things per host:

  1. Ping check with a short timeout, so a sleeping host does not stall the run.
  2. Port and service scan across the top 200 ports with version detection.
  3. Targeted vulnerability scripts on hosts that expose HTTP, SSH, or SSL: the http-vuln* family and ssl-enum-ciphers. I learned the hard way that a full --script vuln pass takes over 90 seconds per host, which pushed the whole run past any sensible time budget, so I narrowed it to the script families that actually cover the highest-risk surface on Plesk and Proxmox boxes.
  4. A local listening check on the VPS itself, so a new daemon that nobody remembers starting shows up in the report.

The output is a markdown report per host: hostname, IP, zone, status, open ports, services. Raw nmap output goes to files next to it, so there is a paper trail for every claim.

Here is what the run on the morning of 12 August 2026 actually produced.

HostZoneStatusOpen portsServices*****localUpnone exposedlocal listeners onlypve01tailscaleUp22, 111, 443, 3128SSH, rpcbind, HTTPS, Proxmox REST APImlds-wptailscaleUpnonefirewalledopenrporttailscaleUnreachablenonepeer sleeping on idlehomeassistanttailscaleUpnonefirewalledblade1publicUp12 portsFTP, SMTP, DNS, HTTP, IMAP/POP3, Plesk panel on 8443blade4publicUp10 portsFTP, SMTP, HTTP, IMAP/POP3, Plesk panel on 8443

The Proxmox host was up with four ports open: SSH, rpcbind, HTTPS, and the Proxmox REST API on 3128. Both blade servers were up, exposing the usual Plesk surface: FTP, SMTP, POP3, and IMAP; DNS on one of them; nginx; and the Plesk control panel on 8443. The VPS itself showed a familiar listening set: the fleet's gateway on 9119, the Joplin API on 41184, Asterisk on 5038 and 5060, the Signal daemon on 8081, and a handful of Docker-internal ports.

And one host was unreachable: openrport, a Tailscale peer that sleeps on idle. The report flagged it, and tomorrow it will probably be back. That is the point of a daily assessment: you learn which blips are weather and which are weather systems.

The tool said nothing to anyone about any of this, because the silent-watchdog pattern only produces output when there is something to flag. Empty stdout means no news is good news.

The tuning is the unglamorous part, and it is where the tool earns its keep or becomes noise. The assessment filters SSH out of the sensitive-services check on management hosts, because SSH on a Tailscale host is the standard way in, not a finding. It knows rpcbind is expected on the Proxmox box. It treats tailscale peers that sleep as a known condition, not an incident. Every one of those filters is a decision I made after a false positive annoyed me, and every one is documented in the script so the next person does not have to rediscover it. A security tool that alerts on its own baseline is a tool you will learn to ignore, which is the one failure mode that makes the whole exercise pointless.

The Rule That Makes It Safe Enough to Run Automatically

The single most important line in the whole framework is this one, and it appears whenever the agent is asked to do something outside its authorised scope:

SCOPE DENIED: <target> is not in the authorized scope

Egress-scope containment is non-negotiable in this design, and it is not a local hardening I added. It is the upstream default: once a mission target is set, the built-in networked tools refuse off-scope public hosts, anything that is not the target or its subdomains, and anything on loopback or private ranges unless explicitly granted. The refusal appears as a hard error, SCOPE DENIED, with no bypass flag. The design docs describe it as a tightened default, not a bare tool runner, and the test suite includes gates named after the behaviour: arsenal-scope-gate, arsenal-approval-gate, no-phantom-tools, stub-honesty.

That matters for two reasons. Legally, unauthorised scanning is an offence in most jurisdictions, so a tool that cannot wander is a tool that cannot get you arrested. Operationally, an autonomous agent that scans at 06:00 while you sleep is only trustworthy if its definition of "in scope" is fixed, immutable, and enforced in code rather than in a prompt.

The same restraint carries into the operation modes. Commands are classified: safe_command for local reads and lab-safe operations, receipt_required for anything active, networked, or credential-adjacent, catalog_only for capabilities that exist but never run through the generic execution surface, and import_only for evidence that is recorded but never actively collected. High-risk actions require named approval. Production writes require named approval. The coordinated-disclosure pipeline generates drafts only; a human sends them. The updater asks for confirmation before any change and never touches your agent's authentication. There is no generic execution surface for broad exploitation or credential tooling, full stop.

I want to be unambiguous about this, because it is the part people get wrong: an autonomous security agent is not dangerous because it is powerful. It is dangerous when power is combined with a weak definition of what it may touch. T3MP3ST inverts that. The power is real, and the boundaries are harder than the power.

The Same Pattern, Applied to a Codebase

The framework is not only about servers. The same agent loop- recon, scan, verify, report- applies to source code, and this is where the LLM-driven design earns its keep.

The verification tooling is built in. verify-claims checks that every finding and benchmark claim in the output is backed by real evidence; on my install it re-derives every headline number from committed data, and all 24 claims pass. verify-finding takes a single finding and independently re-runs the steps that produced it. A benchmark harness (cve:bench, with live and adversarial variants) measures how well the agent hunts CVEs in a controlled setting before you point it at production.

The headline numbers in the upstream project are not marketing copy, and the framework treats them the same way. It runs a held-out benchmark called CVE-Zero against ten real post-cutoff 2026 CVEs across seven languages, where the agent must find the exact file, line, and CWE from a cold start; the verified result is eight out of ten exact hits and all ten found. There is an anti-fitting guard that runs on every push, so the benchmark cannot be gamed by memorising the answers. I care about that because it is the difference between a tool that reports and a tool that can be trusted to report.

The optional extras matter here too. The framework ships with integration points for semgrep, a static analysis and supply-chain scanning tool, and promptfoo, an evaluation runner for AI prompts. Neither is installed in my default environment, because both are heavier than the daily loop needs, but the integration points exist precisely so the codebase checks can be automated alongside the infrastructure checks: same agent, same evidence format, same retest discipline.

That is the part I care about most. A scanner that reports a finding and then disappears is a noise generator. A scanner that can re-verify its own findings, classify them by confidence, and refuse to promote them to "confirmed" without evidence is a colleague. The difference shows up the first time you get a critical-severity alert from a tool that also tells you whether it has independently confirmed the exploit exists.

Why Continuous Beats Periodic

The reason I moved to this pattern, rather than the quarterly pentest I used to pretend I was going to run, is simple arithmetic.

The numbers from the National Vulnerability Database do not support periodic assessment. In 2019, 18,938 CVEs were published. In 2024, that number was 40,704. In 2025, it was 49,972. In the first seven and a half months of 2026 alone, the count has already passed the full-year 2025 total, at 50,941 and climbing. Vulnerabilities are not being disclosed on a schedule that respects quarterly reviews; they are being disclosed faster than humans can patch them.

The exploitation numbers are worse. VulnCheck's own tracking shows the median time from CVE publication to inclusion on CISA's Known Exploited Vulnerabilities list fell from 120 days in 2025 to 80 days in the first half of 2026. Roughly two hundred CVEs were being exploited within 31 days of disclosure in that same period. A point-in-time assessment is a photograph of a moving target, useful for compliance, nearly useless for security.

A daily autonomous sweep inverts the economics. The marginal cost of one more scan is close to zero, because the machine does the work and the output is triaged by severity. The finding that matters, the one that shows up in the report at 06:01, is the one that changes the conversation: not "we should scan at some point" but "this appeared since yesterday, and here is the evidence".

There is a second reason, and it is the one that convinced me. An agent that runs every day learns your baseline. It knows that OpenReport sleeps, that the VPS listens on the same ports it listened on last week, that the blades have not drifted. When something new appears, when a service shows up that should not be there, the report says so with the weight of thirty consecutive mornings of data behind it. That is the difference between monitoring and watching.

The Takeaway

You do not need a red team to secure your own infrastructure. You need a disciplined tool that checks what you own, every day, without being asked, and refuses to look anywhere else.

If you take one thing from this, take the safety design. Whatever tool you choose, whether it is T3MP3ST or something else entirely, the questions to ask are not about tool count or dashboard polish. Ask whether the tool can define its own scope in code, whether exploitation is gated behind a human, whether findings require evidence and retest before they become claims, and whether the thing can run unattended without the ability to wander.

An autonomous security agent that cannot leave the reservation is a gift. One that can is a liability with a login.

The version I run does the checks, saves the evidence, and stays home. That is exactly what I want from something that starts working before I do.

Sources