Guardian Cloud
AI that administers & protects your cloud 24/7
6 followers
AI that administers & protects your cloud 24/7
6 followers
Guardian Cloud is an autonomous AI operations and security team for your servers: audit, monitoring, remediation, intrusion response and malware defense — human in the loop. All models self-hosted, your data never leaves your perimeter. Built with Claude Opus 4.7/4.8.
Hey Product Hunt! 👋
I'm Taras, Chairman of AlfaCan Defence Group. Today we're launching Guardian Cloud — and I want to share the story behind it.
This platform was built in an unconventional way: I developed the entire architecture and codebase collaboratively with Claude Opus 4.7/4.8. What would normally take a team of 10 engineers took one
person and an AI. That alone felt worth sharing.
But what we built is what I'm most proud of: Guardian Cloud isn't a monitoring tool.
It's an autonomous AI operations team — a network of specialised AI officers that administers and defends your servers 24/7.
When something breaks, it fixes it. When an intrusion happens, it contains it.
Works on any Linux server — GCP, AWS, Azure, Hetzner, DigitalOcean, Kubernetes, on-premise, air-gapped datacenters.
All models run self-hosted on your GPU.
Your code and telemetry never leave your perimeter — not to Google, not to Microsoft, not
to OpenAI. This isn't a setting — it's written into our contract as MSA §3.3, air-gap by default.
Real numbers from live GPU validation:
⚡ Threat detection in 726–952 ms
🎯 ITDR Officer: 100/100 ROE scenarios
🔧 Command generation: 97% accuracy across GCP, Azure, AWS
The hardest part wasn't the code — it was figuring out how to make AI trustworthy enough to touch production servers.
The answer: strict Rules of Engagement and human approval for every high-risk
action.
🎁 For Product Hunt community: code PRODUCTHUNT3 = 1 month free.
Pre-registration open at guardian.alfa-can.com.
Happy to answer any questions about the architecture, the AI-assisted development process, or anything else.
This community's feedback means a lot at this stage! 🙏
— Taras
Hey Product Hunt 👋
I'm Vlada Safonova, Chief Developer at AlfaCan Defence Group.
Guardian Cloud is live today. Instead of a feature list, let me
walk you through what actually happens when you connect it —
three moments from real workflows.
──────────
📖 Moment 1: Onboarding
You install the agent — a Go binary — on any Linux server.
GCP, AWS, Azure, Hetzner, DigitalOcean, Kubernetes, on-premise,
air-gapped datacenters. The agent is platform-independent, so
your infrastructure choice doesn't matter.
The agent collects your system state (~18 command outputs:
processes, ports, services, disk, logs) and your service code.
Our AI sysadmin analyzes both. Code and dependencies go through
the s-coding module with ITDR shields on top: root, credential,
privilege checks.
You get an AuditReport: vulnerabilities found, risk levels,
remediation plan.
Risk tiering matters here: SAFE/LOW auto-applies. MEDIUM auto-applies
with validation. HIGH waits for your explicit approval. CRITICAL
never auto-runs — no exceptions.
You choose autonomy per server: observe, assisted, guarded, or
full. We built it this way because we don't believe in "trust us"
architectures.
──────────
📖 Moment 2: 3 AM on a Tuesday
Anomaly patterns start showing up in logs. Unusual outbound
traffic. The agent checks in every ~15 seconds, so latency
between event and detection is short.
Threat detection: 726-952 ms from anomaly to identified threat
on our validation suite.
ITDR scenario handling: 100/100 on our Rules of Engagement suite.
Guardian doesn't just alert. It executes: blocks source IPs,
updates firewall rules, isolates the affected service, runs
forensics, deploys honeypots when doctrine calls for it.
Every action is logged with reasoning. You wake up to a full
debrief — what happened, what was done, what artifacts are
preserved. The audit trail is complete because we designed it
that way from day one.
──────────
📖 Moment 3: Monday, 10 AM
You open the chat orchestrator in your dashboard and write:
"I need a new API endpoint for our mobile app that syncs user
preferences."
Our coding model — GLM-5.2, self-hosted — drafts the code. The
validator (also GLM-5.2, separate instance) checks it line by
line for correctness and vulnerabilities. Command generation
accuracy on our validation suite: 97% across GCP, Azure, AWS.
Feature requests always land in pending_approval. Never
auto-deploy. You review the diff, approve, agent applies.
One architectural invariant we won't compromise: no service in
the system modifies code on its own. Only s-coding does. This
matters because when things break at 4 AM, you know exactly which
module was responsible.
──────────
🔒 What actually stays private
The hardest part of building this wasn't the AI. It was making
sure your code and telemetry never leave your perimeter.
All models run self-hosted on your GPU in your region. Orchestrator:
Gemma-4. Coder and validator: GLM-5.2. Threat detection shields:
our own trained models. Zero external AI calls in production.
The ITDR contour is fully air-gapped. External validation (Claude
from Anthropic, for high-risk edge cases) is dormant by default —
enabled only with your explicit consent, and only on de-personalized
code with credentials/keys/names stripped.
This is written into our contract as MSA §3.3 — air-gap by default.
If we violate it, you terminate and recover damages without limits.
──────────
🎁 Product Hunt community offer
Code PRODUCTHUNT3 = 1 month free trial.
Pre-registration open at guardian.alfa-can.com.
Would love your feedback — especially from anyone running
production infrastructure. What would break your trust in
autonomous AI ops?
— Vlada
Chief Developer, AlfaCan Defence Group