Products / SecAI
This page is not a sales page for SecAI. It explains what building and running it forced us to decide, and why that changes the infrastructure and security advice we give clients.
SecAI is an AI-powered Linux server security product published by Tech Steps LLC. It puts a lightweight Rust agent on a server for continuous monitoring, detects attack patterns, automatically blocks hostile addresses, tracks package vulnerabilities and produces compliance reporting. It appears here as proof of capability rather than as a pitch: the decisions behind it are the same ones we make on client infrastructure, and we carry the consequences of ours.
The problem we were solving
Plenty of tools will tell you that something happened on a Linux server. Far fewer will tell you which of those things matters, and almost none will do something about it safely without a security team standing behind them.
That gap is the actual problem for the organizations we work with. A small business or a growing SaaS company does not lack alerts. It lacks someone to interpret them at three in the morning. So the useful engineering question was never how to detect more. It was how much a system can safely do on its own, and where it must stop and wait for a person.
Almost every design decision below follows from that single question.
Decisions and their reasons
These are architectural positions rather than feature descriptions. Each one cost something, which is what makes it a decision.
Because the questions that matter cannot be answered from outside. Whether a process is running from a deleted binary, which packages are installed, what is listening on localhost, whether a scheduled task changed: none of that is visible to a network scan. If you want to know the state of a server you have to be on it.
An agent runs on machines you do not control, continuously, with elevated privileges. It has to be small, predictable under load, and free of the memory-safety class of bug, because a vulnerability in a security agent is worse than the problem it was deployed to solve. Rust gives a compiled single binary with no runtime to install.
An agent that accepts instructions is a command channel into every server running it. Ed25519 signing, verified on every agent cycle, means a compromised or impersonated backend cannot direct the fleet. This is the part of the design we would defend most strongly, because getting it wrong turns a security product into an attack path.
Blocking a hostile IP is reversible and low-consequence, so it can be automatic. Restarting services, changing accounts and installing packages are not, so they are not. The constraint is not technical difficulty. It is that an automated action you cannot undo will eventually fire on a false positive.
Because the first serious failure mode of any auto-blocking system is locking the administrator out of their own server during an incident. A safety net for known-good infrastructure is not a nice-to-have, it is what makes automatic enforcement safe enough to enable.
A remediation that breaks a service has made things worse. If the system is going to change a production server automatically, it has to be able to detect that the change was harmful and undo it without waiting for a human to notice.
The approval boundary
This is the part of the product we think about most, and the part that transfers most directly to client work. The dividing line is reversibility.
The same principle governs how we build AI agents and automation for clients. Capability is not the constraint. The consequence of being wrong is.
The interesting question is never whether software can take an action. It is what happens the time it takes that action wrongly. We now start client automation and agent work from that question rather than arriving at it later.
Any mechanism that puts new code onto a customer server is exactly as trustworthy as its weakest verification step. That thinking carries directly into how we set up deployment pipelines for clients.
Logs held only on the affected host are logs the intruder can edit. Operating a monitoring product makes this concrete rather than theoretical, and it is why remote log collection is in almost every hardening engagement we do.
A system that reports everything gets ignored, which is the same outcome as reporting nothing while feeling more diligent. Prioritization is a feature, not a presentation layer.
A report aligned to a named framework is useful when the underlying evidence is real and traceable. Producing that output honestly is mostly a data-integrity problem, not a document-formatting one.
Independent record
SecAI holds a public StackAttest Passport. The figures below are published by StackAttest, not by us, and the Passport itself shows the evidence behind each verified capability. We link to it rather than reprinting a summary.
StackAttest tests software directly. It complements an organizational audit such as SOC 2 and does not replace one.
Open the SecAI Passport (opens in a new tab)The engineering behind SecAI is the engineering we bring to client infrastructure and security work. Tell us what you are running.