DEV Community: ALSOPS

I built an AI that autonomously bans attackers on Linux — no human in the loop

ALSOPS — Sun, 07 Jun 2026 06:47:09 +0000

Last year I got paged at 2am because someone was brute-forcing SSH on one of my servers. I woke up, fumbled for my phone, opened the dashboard, confirmed it was real, and banned the IP. By the time I did that — maybe 4 minutes — they'd tried 3,800 passwords.

They didn't get in. But that's not the point.

The point is: why did that require a human?

The pattern was unambiguous. High-frequency auth failures from a single IP, no prior connection history, no valid user account targeted. An intern could have made that call. So why was I woken up at 2am to rubber-stamp a decision that was already obvious?

That question is why I built Watch Cortex.

The actual problem with Linux security tooling

Most Linux security tools are good at one thing: generating alerts.

Wazuh fires alerts. Datadog fires alerts. Falco fires alerts. Auditd fires alerts. If you're lucky, your SIEM correlates those alerts into a bigger alert that you also have to manually act on.

The human is always in the loop. And the human is always the bottleneck.

This creates a well-documented failure mode: alert fatigue. You get so many alerts that you stop trusting them. You start dismissing things. And then you miss the one that mattered.

I wanted to build something different. Not "detect and alert." Detect, reason, and respond — in the time it takes the attacker to try their next password.

How Watch Cortex works

The architecture is built around three components:

1. The Watch agent

A single binary (~8MB) that deploys as a systemd service. Install:

curl -fsSL https://watch.alsopss.com/install-agent.sh | sudo bash -s -- --token YOUR_TOKEN

Done in under 60 seconds. The agent connects outbound over WSS on port 443 — no inbound firewall changes, no open ports.

It monitors:

Process creation and termination with full ancestry trees
Network connections and DNS queries
File integrity changes (configs, SSH authorized_keys, crontabs)
SSH authentication events
Systemd unit additions
User/group mutations

2. Cortex AI — the on-agent reasoning engine

This is the part I'm most proud of. Cortex runs locally on the agent — no cloud call, no round-trip latency, no "cloud service is unreachable" failure mode.

It classifies threats in under 8 milliseconds.

Cortex doesn't just match signatures. It correlates signals across process trees, network activity, and file writes to identify behavioral patterns:

Brute force followed by a successful login from a new IP → escalate
Process that opens a network socket and writes to /tmp → suspicious regardless of name
SSH key added to authorized_keys by a process that isn't the user's shell → respond immediately
Cron job added by a process with no history → flag

Every alert comes with a plain-language investigation summary explaining what triggered, what it correlates to, and what action was taken or recommended. Not RULE_5023_TRIGGERED. An actual explanation.

3. Cortex Hive — fleet immune memory

When Watch catches something on one server, it broadcasts that threat signature to every other agent in your fleet immediately.

One server gets hit with a new cryptominer variant → every other server learns to recognize and block it before it arrives. The fleet develops collective immunity.

When you correct a Cortex decision — "that was actually legitimate, don't block that next time" — that correction propagates fleet-wide automatically. The whole fleet gets smarter from one operator's feedback.

The four automation modes

I don't want to force everyone into full autonomous mode on day one. So Watch has a mode ladder:

Mode	What it does
Watch	AI observes and alerts. Every action requires your approval.
Assist	Non-destructive actions (logging, enrichment) run auto. Destructive actions (IP ban, process kill) surface as one-click suggestions.
Autopilot	High-confidence threats acted on immediately. Low-confidence threats queue for your override.
Sovereign	AI acts on everything confirmed. You override rather than approve — system never waits.

Most people start on Assist. They see the one-click suggestions coming in, they confirm a few, they realize Cortex is right 95%+ of the time, and they bump to Autopilot. Some teams — especially infrastructure-heavy ones with no 24/7 security staff — run full Sovereign.

The key insight is: humans should be the override path, not the approval path.

What happens during a real attack sequence

Here's a realistic SSH brute-force → persistence scenario and how Watch handles it in Autopilot mode:

T+0s: Attacker begins SSH brute force from 185.220.101.x

T+0.3s: Watch agent detects high-frequency auth failures

T+0.8s: Cortex classifies: brute force, high confidence

T+1.1s: iptables rule added — IP banned

T+1.2s: Threat broadcast to all fleet agents via Cortex Hive

T+1.5s: Alert + investigation summary sent to dashboard

T+0s: Attacker tries again from a different IP in same /24 subnet

T+0.3s: Cortex correlates new IP to same campaign (same user targets, same timing pattern)

T+0.8s: Subnet banned preemptively

T+0s: Attacker somehow gets in (compromised credential, different vector)

T+2s: New process spawned by sshd with unusual ancestry

T+3s: Process opens outbound connection to known C2 range

T+3.2s: Cortex classifies: reverse shell / lateral movement, high confidence

T+3.5s: Process killed by PID

T+3.6s: File integrity check initiated on affected paths

T+4s: Operator notified with full chain-of-events summary

Total time from first detection to lateral movement blocked: 4 seconds.

Time I need to be awake: 0.

Why I didn't just use Wazuh

Wazuh is genuinely good. It's open-source, extensible, and has a massive rule set. I used it for two years.

But Wazuh is a SIEM. It collects events, matches rules, and fires alerts. That's it. Everything after the alert is on you.

Watch is an autonomous response platform. The detection is table stakes. The response — especially the AI-reasoned, fleet-aware, offline-capable response — is the thing.

The other thing: Wazuh alert noise. Out of the box, you'll tune it for weeks before it's quiet enough to trust. Cortex learns your specific server's baseline. It's not "process X is always suspicious" — it's "process X is suspicious on this server because it's never done this before."

Offline operation

This is a requirement I'm firm about. An agent that stops working when the backend is unreachable isn't actually protecting you — it's just making you feel protected.

Cortex AI, threat signatures, contingency plans, and response policies are all pre-synced to each agent. When the backend is unreachable, detection and response continue at full capability. Actions taken offline are logged locally with cryptographic timestamps and synced when connectivity returns.

If someone is actively attacking your server during a network incident, the last thing you need is your security agent phoning home and getting no answer.

The compliance angle

Most teams I talk to are running on vibes for Linux compliance. "We have auditd enabled" doesn't get you through a SOC 2 audit. Watch automates the parts that actually matter:

CIS Benchmark Level 1 & 2 — continuous posture monitoring
SOC 2 Type II — automated control mapping + evidence collection
PCI-DSS v4 — cardholder data environment monitoring
HIPAA — access events and audit controls
ISO 27001, NIST 800-207 Zero Trust, GDPR

Business plan generates on-demand compliance reports. Enterprise/Empire run a continuous compliance forge — gaps are identified and closed automatically without you pulling a report and manually remediating.

Try it

14-day free trial, no credit card, under 60 seconds to install:

watch.alsopss.com

Developer plan is $39/month for 5 servers. Business is $149/month for 25 servers with Autopilot mode, fleet immune memory, and compliance automation.

If you're running Linux in production with limited security headcount — or you've been paged at 2am one too many times to rubber-stamp an obvious brute-force — it's worth a look.

Happy to answer questions in the comments. I've been building this for two years and I can talk about the architecture all day.

Built by AL'S-OPS LLC. Feedback, issues, and security disclosures: security@alsopss.com.

From Idea to Product: How We Build Modern Web Applications

ALSOPS — Fri, 13 Mar 2026 00:12:43 +0000

Building a modern web application today is very different from even a few years ago. Users expect fast performance, seamless design, AI-powered features, and products that work flawlessly across devices.

At Al’s-Ops LLC, we spend a lot of time thinking about how to build digital products that not only function well but also create meaningful user experiences.

In this article, I want to share some of the principles and development practices we follow when building web applications, from early-stage concepts to production platforms.

⸻

Start With the Problem, Not the Technology

One of the biggest mistakes we see in product development is starting with technology instead of the user problem.

Before writing a single line of code, we ask questions like:
• What real problem does this solve?
• Who is the user?
• How often will they use this product?
• What would make them return?

This approach helps avoid over-engineering and ensures the product is actually valuable.

For example, when building SwiftChef, our recipe discovery and meal planning platform, the focus wasn’t simply on storing recipes. The real challenge was helping users quickly find meals they want to cook and plan their week efficiently.

That focus shaped everything that followed in the product.

⸻

Build an MVP That Can Scale

Many founders hear the phrase “build an MVP” but misunderstand what it actually means.

A good MVP should be:
• Minimal in features
• High quality in execution
• Designed with future scaling in mind

The goal isn’t to launch something temporary. It’s to launch something small but strong.

When designing architectures for new platforms, we typically aim for:
• Modular backend systems
• Clean API design
• Component-based frontend frameworks
• Cloud-native infrastructure

This allows products to grow without requiring a full rewrite later.

⸻

User Experience Is a Competitive Advantage

The difference between successful apps and forgotten apps often comes down to UX.

Great software should feel:
• Fast
• Intuitive
• Effortless

This means developers need to think beyond functionality and consider:
• Load performance
• Visual hierarchy
• Interaction feedback
• Mobile responsiveness

Even small improvements in usability can dramatically increase user retention.

⸻

AI Is Changing Product Development

Artificial intelligence is quickly becoming a core feature in many digital products.

We’re seeing AI used for:
• Personalization
• Smart recommendations
• Natural language search
• Automated workflows

The key is integrating AI in ways that actually improve the user experience, rather than adding it just because it’s trendy.

For consumer platforms like SwiftChef, AI-driven discovery and intelligent filtering can dramatically improve how users find content.

For SaaS tools, AI can automate tasks that previously required manual effort.

⸻

Speed Matters in Modern Development

Startups and early-stage products need to move fast.

This means focusing on development processes that prioritize:
• Rapid iteration
• Continuous deployment
• Feedback loops with real users

Shipping quickly doesn’t mean sacrificing quality. It means building systems that allow you to improve the product continuously.

⸻

Collaboration Is Key to Great Products

Great software rarely comes from one person working alone.

The best products come from collaboration between:
• Developers
• Designers
• Product thinkers
• Founders
• Users

At Al’s-Ops LLC, we work closely with teams to transform ideas into scalable digital products across areas like:
• Web applications
• E-commerce platforms
• AI-powered tools
• Gaming-related services

⸻

Final Thoughts

The web is evolving faster than ever. New technologies appear constantly, but the fundamentals of building great products remain the same:
• Solve real problems
• Focus on the user experience
• Build systems that scale
• Iterate quickly

If you’re building a new digital product or experimenting with a startup idea, these principles can help you move from concept to production more effectively.

⸻

About the Author

Al’s-Ops LLC is a software development company building innovative web applications and digital products across gaming, e-commerce, web development, and artificial intelligence.

Our flagship product, SwiftChef, is a premium recipe discovery and meal planning platform used by home cooks every day.

🌐 https://alsopss.com
📧 b2b@alsopss.com

metaForge: A Multi-Language Build & Automation Compiler

ALSOPS — Mon, 08 Dec 2025 17:07:22 +0000

I’m excited to share metaForge, a multi-language MFG compiler that makes building, running, and managing code files across languages easy.
MetaForge parses .mfg files containing groups, blocks, arguments, and raw commands, expands variables, writes code files, and executes commands automatically. It’s designed for developers who want a flexible, multi-language build system.
📌 Key Features
Parse .mfg files into:
Groups: collections of blocks with variables
Blocks: named code files with optional run commands
Args blocks: conditional blocks triggered by CLI arguments
Raw variables & commands: global scope
Variable Expansion: $var:name, $arg, $block:name, $group:name
Automatic File Creation & Execution
Verbose Logging (-v or --verbose)
⚙️ Supported Languages
C++ (default, compiled, fastest)
JavaScript (Node.js based, easy to modify)
Python (widely accessible)
🚀 Quick Start
Create a .mfg file:
group js {
var greeting = "Hello World!"

block hello.js {
    code {
        console.log("$var:greeting");
    }
    run "node $block:hello.js"
}

}

run "rm -rf $group:js"
Run metaForge:
metaForge example.mfg
MetaForge will create hello.js with expanded variables, run it, and clean up automatically.
Example CLI:
metaForge build.mfg build # Builds and runs everything
metaForge build.mfg clean # Removes generated files
📖 Documentation
Full guides, syntax reference, and advanced examples: metaforge.alsopss.com/docs
🛠 Installation

Build C++ version (default)

make build

Build JS or Python versions

make build LANG=js
make build LANG=py

Install

sudo make install LANG=cpp
Custom installation paths and packaging are supported via PREFIX and DESTDIR.
🤝 Contributing
Contributions are welcome! Submit Pull Requests or open Discussions on GitHub: https://github.com/ALSOPSS/metaForge