Case study / SecAI
From security signal to action that can be undone
The hard part was never detection. It was deciding how much a system may do on its own when the consequence of being wrong lands on somebody else's production server.
What did TechSteps build with SecAI?
A Linux server security product with a lightweight Rust agent on the host, cryptographically signed instructions from the backend, automated blocking of hostile addresses, package vulnerability tracking and compliance reporting. The design question that shaped everything was where automation must stop and wait for a person, and the answer we settled on was reversibility.
Snapshot
- Product
- SecAI
- Publisher
- Tech Steps LLC
- Category
- Linux server security
- Agent
- Rust, single binary
- Instruction integrity
- Ed25519 signatures
- Independent record
- StackAttest L4
Context
What existed before.
The organizations we work with are not short of security alerts. They are short of someone to interpret them. A small business with three servers, or a growing SaaS company with a handful of engineers, has no security operations team and no realistic prospect of hiring one.
Existing options split badly. Enterprise platforms assume analysts to run them. Simple tools tell you something happened without telling you whether it matters or doing anything about it. Both leave the same gap: at two in the morning, nobody is reading the alert.
So the product question was not how to detect more. It was how much a system can safely do without a human, and how to make the boundary explicit rather than hopeful.
Constraints
What made it difficult.
Without these, the problem would have been ordinary. They are the reason the design looks the way it does.
- 01
The agent runs on machines we do not control
Someone else's production server, with their workload, their kernel version and their tolerance for resource use. It has to be small, predictable and impossible to blame for an outage. That rules out a lot of otherwise convenient implementation choices.
- 02
An instruction channel into a fleet is an attack surface
Any system that sends commands to agents across many customer servers is, from an attacker's point of view, an extremely attractive target. If the backend can be impersonated, the product becomes the intrusion.
- 03
Automated action is irreversible by default
Anything the system does automatically will eventually fire on a false positive. The design has to assume that, rather than assume detection accuracy will prevent it.
- 04
The operator may be the only person available
There is no analyst to triage. Output has to be prioritized well enough that a non-specialist can act on the top item, because everything below the line will not be read.
- 05
Compliance output has to be defensible
A report aligned to a named framework is worthless if the underlying evidence cannot be traced. That is a data-integrity requirement, not a reporting feature.
System map
The parts that had to trust each other.
- 01
Host agent
Rust binary on the monitored server. Collects state, applies signed policy, executes only the narrow set of actions it is permitted.
- 02
Instruction channel
Ed25519 signatures verified on every agent cycle, so an impersonated or compromised backend cannot direct the fleet.
- 03
Detection
Attack patterns including brute force, floods, connection exhaustion and scanner activity, correlated with host state.
- 04
Response
Enforcement through fail2ban and CrowdSec, restricted to blocking, with trusted addresses exempted so an operator cannot be locked out.
- 05
Vulnerability tracking
Installed packages matched against public CVE data on an ongoing basis.
- 06
Reporting
Compliance output aligned to UAE NESA, PDPL and international cybersecurity frameworks, generated from collected evidence.
A simplified view of the trust boundaries rather than a complete architecture. The interesting property is which direction trust flows: the agent verifies what it receives, rather than the backend being trusted because it is the backend.
Decisions
What we considered and what we chose.
A decision with no rejected alternative was not a decision. These are the forks where a different answer would have produced a different product.
| Decision | Alternatives considered | What we chose and why |
|---|---|---|
| Where to observe from | Network scanning only, log shipping only, or an agent on the host | An agent on the host. Process state, package inventory, localhost listeners and scheduled task changes are simply not visible from outside, and those are the questions that matter after a compromise. |
| Agent implementation language | A scripting language for speed of development, or Go, or Rust | Rust. A single compiled binary with no runtime to install, predictable resource use, and the memory-safety class of vulnerability removed. A vulnerability in a security agent is worse than the problem it was deployed to solve. |
| How agents trust instructions | Trust the transport layer, or sign the instructions themselves | Sign the instructions. Transport security protects the channel; it does not tell the agent that the sender is legitimately authorized. Signature verification on every cycle means the agent is not relying on the network being safe. |
| Scope of automated enforcement | Full automated remediation, or alert-only, or a narrow reversible subset | A narrow reversible subset. Blocking an address can be undone in one action. Restarting services, changing accounts or installing packages cannot be undone without knowledge the system does not have. |
| Protecting the operator from the product | Rely on detection accuracy, or explicitly exempt known-good infrastructure | Explicit exemption. The first serious failure of any auto-blocking system is locking the administrator out during an incident. Accuracy is not a substitute for a safety net. |
| Handling a remediation that breaks something | Wait for a human to notice, or detect and revert automatically | Detect and revert. If the system is permitted to change a production server, it has to be able to recognize that the change was harmful and undo it without waiting. |
Implementation
How it was actually built.
- 01
Agent and collection
The host agent first, because everything else depends on what can actually be observed. Deliberately narrow: collect well-defined state rather than everything, since an agent that gathers indiscriminately becomes a privacy and performance problem.
- 02
Instruction integrity
Signing and verification built before the command features that would use it. Retrofitting cryptographic verification onto an existing command path means auditing every route, so it went in first.
- 03
Detection and correlation
Attack pattern detection across network and application layers, correlated with host state so a finding carries the context needed to judge it.
- 04
Bounded enforcement
Blocking through fail2ban and CrowdSec, with the trusted-address exemption implemented alongside rather than afterwards. The safety net and the capability shipped together.
- 05
Vulnerability and compliance layer
Package matching against public CVE data, and reporting generated from the evidence already collected rather than from a separate assertion.
- 06
Independent validation
Submitted to StackAttest for external validation, producing a public Passport with the evidence behind each verified capability. We wanted the product judged by something we did not control.
Verification
How we checked it worked.
- Externally validated by StackAttest, reaching Production Validated on its public Passport
- Signature verification exercised on every agent cycle rather than at enrolment only
- Trusted-address exemption tested against the lockout scenario it exists to prevent
- Automatic rollback tested by deliberately applying a change that breaks a service
- Agent behavior measured under sustained load on representative servers
- Compliance output traced back to the collected evidence that produced it
Outcome
What we can and cannot claim.
Every statement below is labelled with where it comes from. Nothing here is an unattributed percentage.
- Third-party verified
Reached L4 Production Validated on its public StackAttest Passport
Published by StackAttest and validated 28 August 2026. Evidence coverage 92%, validation confidence 85%. The Passport is public and linked from this site so the figures can be checked at source rather than taken from us.
- Design property
A compromised backend cannot direct the agent fleet
Instructions carry Ed25519 signatures verified by the agent on every cycle. This is a property of the design rather than a measured outcome, and it is the property we would defend most strongly.
- Design property
No automated action requires knowledge the system does not have to undo
Enforcement is restricted to blocking, which reverses in one action. Everything with a wider blast radius waits for a person. This is a deliberate limit on capability, not an unfinished feature.
- Observed by us
Operating it changed how we scope client automation
We now begin agent and automation engagements by asking what happens the time the system acts wrongly, rather than reaching that question later. That is our own observation from running the product, not a measurement.
What stayed out of scope
- The product does not replace patching, backups or someone who understands the system. It reports and it bounds damage.
- It is not a substitute for a security team where the risk genuinely warrants one.
- This page makes no claim about detection rates or prevented incidents. We have not published a figure we could defend, so we publish none.
- Internal implementation detail beyond what is public on the product site is deliberately not described here.
Lessons that changed how we work
-
Design from the blast radius, not the capability
The useful question is never whether software can perform an action. It is what happens the time it performs it wrongly. That reframing changed the product and now shapes how we scope automation for clients.
-
Verification belongs at the start of a command path
Adding cryptographic verification to an existing command system means auditing every route into it. Building it first cost less and produced a stronger result.
-
A safety net is a feature, not a caveat
Exempting trusted infrastructure from automatic blocking is what makes automatic blocking safe enough to enable at all. The guard rail and the capability are the same design.
-
Prioritization is the product
For a team without an analyst, an unprioritized list of findings is equivalent to no findings. Ranking is not presentation, it is the thing being sold.
Have something with constraints like these?
The interesting work usually arrives as a set of things that cannot all be true at once. Tell us what you are trying to make work.