Operations

Automated, but never autonomous.

A single, auditable pattern powers every action Klyroo can take on your infrastructure: an admin clicks approve, the action is queued to the specific server it applies to, and the agent carries it out on its next check-in. Nothing runs without that click — ever.

Book a demo ← Back to platform overview

2actions live today

1shared queue mechanism

0actions taken without a click

Why human-approved, not autonomous

The fastest response isn't always the safest one.

An agent that can autonomously block an IP or push its own update is powerful — and also a single false-positive away from blocking a real customer, or a single bug away from bricking a fleet of agents at once. Klyroo deliberately doesn't take that trade. Every state-changing action starts with a person looking at the actual evidence and clicking a button. The system automates everything after that click: queuing, delivery, execution, and reporting back — not the decision itself.

How It Works

One queue, two actions today.

Admin approves an action in the dashboard

Block this IP from a security alert, or click Update Agent next to a version badge — the click itself is the approval, made in context.

The action is queued for that specific server

A row is written to a shared commands table, scoped to the exact server the action applies to — not broadcast fleet-wide.

The agent picks it up on its normal check-in

No separate push channel or open inbound port — the agent asks "anything pending for me?" as part of the same poll it already performs, and executes what it finds.

Result is reported back and reflected in the dashboard

Success or failure is written back through a lightweight reporting endpoint, so the admin sees the outcome — not just that a click happened.

Action: Agent Update

A script that can safely replace itself mid-run.

The dashboard shows a "vX.Y available" badge when a server's live agent version is behind. Clicking Update Agent queues the update through the same mechanism above. On the agent side, the download and verification step is kept strictly separate from the actual file swap — and the file swap itself is deliberately the very last statement the script executes, after everything else for that run has already completed and reported back.

That ordering is what makes it safe for a running bash script to overwrite its own file: nothing after the swap depends on the old file contents still being there, because there is nothing after it. A backup of the previous version is kept in case a rollback is ever needed.

manage-linux · agent

current version — 1.6

✦ v1.7 available

A newer agent version has been detected.

Update Agent

Action: IP Blocking

Same queue, applied to a security finding.

Covered in full on the Security Detection page — the "Block this IP" button on an alert uses this exact mechanism. It's the same queue, the same per-server scoping, the same reporting-back — just a different command.

MATCH · rce_scan_phpunitConfidence 95%

Exploit scan detected against your web root.

Block this IP →

Where We Stand

Scope, honestly.

What's covered

A generic, reusable human-approved command queue — not a one-off for a single feature
IP block/unblock, applied per server
Agent version updates, with safe self-replacement
Full audit trail: who approved, when, and the reported outcome

What it isn't

Not an autonomous remediation engine — nothing in this system takes an action without a prior human click
Delivery follows the agent's normal check-in cadence, not an instant push — an action taken now applies on the next check-in, not immediately
Two actions today; more can be added on the same queue without new infrastructure, but each addition still starts with a deliberate decision, not an automatic expansion

Pairs Well With

Related capabilities

See the approval flow, end to end.

Watch a click become an action on a real server, with nothing skipped.

Book a 20-minute demo