Stasys

Your own servers are no longer counted as attackers on the WAF pages.

Fixed

• Your own servers are never counted as attackers.
  • When one of your servers calls another's own endpoints (metrics, logs, the agent API), the web firewall does not inspect or log it, and Stasys does not store it as an attack.
  • The WAF pages and ATT&CK coverage leave your servers out of every attack count, and one line shows how many requests came from them.
  • Anyone else on those endpoints is still inspected, and one of your servers attacking a neighbour anywhere else still shows.

Upgrading

Nothing to do. The new firewall rule reaches every server whose web firewall Stasys manages by itself.

Why

Your servers sending metrics and logs to each other were logged as millions of "attacks" a week and filled the WAF's top-attacker list.

Every security and WAF page opens at once, however big your logs are. And every server now watches its secret files, so stolen password hashes and keys are caught as they are read.

Added

• Slow pages are caught. Any page slower than one second shows under "Slow pages (last hour)" on System status and in your AI staff's morning report.

• Every server watches its secret files. The host agent installs the Linux audit service where it is missing. That turns on the secret-file watch, the full attack story and second-by-second detection.

  • Its logs are capped at four files of 50 MB, and it never stops the server when the disk fills.
  • An audit service you already run keeps your settings.
  • The server page says whether it was installed by Stasys, was already there, or cannot run there.

Fixed

• Security and WAF pages open at once. These pages now show their latest result straight away and say "as of HH:MM": the WAF dashboard and events, threat statistics and campaigns, detection decisions, ATT&CK coverage and System status. Stasys keeps those results fresh in the background, so even the first visit is instant, and a change you make shows on the next load.

Upgrading

Nothing to do. The host agent updates itself to 0.171.0 and installs the Linux audit service where it is missing. To keep it off a server, untick it on that server's Process watch card.

Why

On a busy fleet some pages took from a few seconds to several minutes, because they counted the whole security log on every visit. And the secret-file watch could not run anywhere without the Linux audit service, which no server had.

The ATT&CK coverage page now tells you what is true about your fleet, and Stasys watches for an attacker moving from one of your servers to another.

Added

• Stasys notices an attacker moving between your servers. When one of your servers logs into another over SSH as a pair it has never seen, you get a security event: medium, or high for root. Stasys learns your normal pairs for the first 7 days.
• A program copied in over SSH and then run is flagged. If a file arrives by scp, rsync or sftp and is run, or made executable, within 15 minutes, the agent flags it. It is high when it came from another of your servers or runs as root.
• Your AI staff fill the domain watch with your own domains. They take them from your public address, status page, sending address, monitored sites and hosting platform, and note where each was found. A domain you remove stays removed.

Fixed

• The ATT&CK coverage page tells the truth.
  • It counts secret-file reads and attacks the agent stopped.
  • A watch that is running counts as running, even before it has fired.
  • Successful SSH logins count as Valid Accounts.
  • Your own site lock counts as blocked access to a management service.
  • Request-body parse errors and the platform's own file changes are left out and counted on their own lines.
  • Sudoers and account-file changes are linked to their techniques.
  • Website attacks are no longer shown as host discovery.

Upgrading

The host agent updates itself to 0.170.0. SSH logins between your servers are learned for 7 days before any is reported.

Why

The coverage page said some running watches could see nothing, counted engine noise and the platform's own changes as attacks, and claimed host discovery from ordinary website attacks. A page that flatters you is worse than one that shows the gaps.

Fixed

• The Protection card works on every server page. A server page opened by its name showed "no protection mode yet" and "Couldn't load the reflex log". The card now shows the server's mode, its learning countdown and what the agent stopped, however you opened the page.

Your servers now stop an attack on their own, within seconds, and your AI staff take care of everything after: they find the same attack on your other servers, clean up, work out exactly what leaked, fix what they are allowed to, and draft the incident report for you to approve.

Added

• Your servers stop an attack on their own, in seconds. When a program collects secret files and packs or uploads them, leaves a root shell behind, opens a reverse shell, or downloads and runs code under your web server, Stasys on that server:

  • stops it;
  • blocks where it was sending data, for 24 hours;
  • quarantines the files it dropped;
  • removes the root bit from anything it left behind.

  It does this without waiting for anyone, and a trusted vendor's updater gets no pass. Every step can be undone from Security → Protection.

• Stasys sees secret files being read, and whether the read worked. Stasys watches reads of password hashes, SSH keys, shell history, and cloud, database and panel credentials. It also sees files being staged in a hidden folder, packed, encoded and uploaded, an attacker deleting their traces, and an updater doing something it has never done before.

  On Windows it watches reads of the SAM and SECURITY hives and of LSASS memory.

• The whole story is kept, even after the attacker deletes their files. With every detection, Stasys keeps what that program and its children did in the last 15 minutes: what it started, read, wrote and deleted, and where it connected. You can follow it step by step on the process story page.

• Your AI staff handle the rest of the incident. A stopped attack opens one critical incident, and your AI security engineer:

  • looks for the same attack on every other server and blocks the destination everywhere;
  • cleans up;
  • works out exactly what leaked: read and sent, read only, or only attempted;
  • rotates the credentials Stasys owns;
  • puts the rest on one card with exact steps;
  • watches for 30 minutes that the attack does not come back;
  • closes the incident.

  Locking or expiring a real person's account and revoking keys still wait for you. Cutting a server off the network still needs two people.

• An intrusion report your auditor will accept. The report keeps the system evidence (the recorded story with its fingerprint, the events and every action taken) apart from the AI-drafted narrative. The narrative names who drafted it, with which model and from which sources. It counts only once a named person approves it, and you can export it as Markdown.

Fixed

• Quarantine from a security event now really quarantines the file. It used to ask for a scan instead.

Upgrading

• Each server learns for 7 days, then protects. For the first 7 days after the update, a server only records what it would have stopped. After that it acts on its own. You can change this for all servers, or for one server, in Security → Protection.
• Runaway guard. If one server stops more than 5 attacks in 10 minutes, it switches itself to "Detect only" and opens an incident.
• Host agent. The host agent updates itself to 0.169.0. On Linux, secret-read detection uses auditd where it is installed and Stasys may load audit rules.

Why

On 2 November a trusted security vendor's update channel was hijacked and used to steal password hashes and SSH keys from customer servers. Signed, trusted software did it, so tools that trust the publisher saw nothing. Stasys now judges what a program does, not who published it, and stops the theft on the server itself.

Every night your AI staff update and reboot your servers themselves, with no button and no approval, and tell you in the morning what they did.

Added

• Your servers are updated every night, by the AI staff, on their own. At the start of the night's AI window (02:00–05:00 by default) the on-duty engineer updates every server that has updates waiting. It works in waves, one node of a cluster at a time. Before each change it takes a backup, waits while a server says it is busy, reboots only where needed, checks health afterwards, and rolls back automatically if anything fails. The control server goes last, and only after every other server succeeded. One status-page notice covers the whole night.
• It runs as your standing order, and the morning report says what happened. The 72-hour notice is waived in your name and recorded in the audit log, as when you start the run yourself. The morning report shows, per server, what was updated, rebooted or put back, and anything still waiting with the reason.

Fixed

• An overdue backup runs on its own. It could sit waiting for an approval nobody was asked for.
• Your hosting platform's rolling updates no longer fill the public status page. An update that takes nothing down is listed internally and in the morning report. One that takes a service down is still announced.
• The public status page no longer says "Standby". A name that was still the old built-in "Standby" becomes "Stasys". A name you chose yourself is kept.

Removed

• The platform topology card at the top of Hosts & agents.

Upgrading

• Nightly updating is switched on as the owner's standing order. To stop it, or to limit it to security updates, use Settings → AI staff. To keep a server out of it, put that server on hold on the Maintenance page.

Why

Updates piled up because patching ran only in monthly booked windows or when a person pressed Start.

Your AI staff now run the platform. Updates wait for their maintenance window instead of asking you, routine work runs on its own, and the engineers write runbooks from fixes that worked and follow them the next time. You are asked only for what the law needs a person to sign.

Added

• New work the AI staff take on. Certificates are renewed before they expire. A failed control-server backup is run again, and a refused restore check is retried with the reason. OpenSCAP findings are fixed in the window, and failed jobs are retried once each. An overdue backup is acted on after 24 hours. A server whose agent stopped reporting gets diagnostics and, through its management board where it has one, a restart. That restart is never done to the control server or hosting nodes, and at most once a day.
• Runbooks the AI writes and follows. When a fix has proved itself (the alert cleared and stayed clear for an hour, the checks are green), the engineer writes or updates the runbook for that kind of incident. Runbooks are matched by the kind of alert, the service and the kind of server, never a single server name. The next time the incident happens, the runbook is followed first; the engineer stops and undoes at the first failed step, then investigates and improves it. Runbooks are written from redacted data, keep their earlier versions and count their successes and failures. The incident note and the morning report say which runbook was used or written.

Changed

• A server change asked for outside its window waits for the next window. No card, bell or e-mail. It is recorded as "queued for the window on " and runs then, with a backup first and a rollback if the checks fail.
• Package upgrades for known-exploited CVEs wait for the window, and service restarts run on their own. On the control server, restarts also wait for the window.
• The AI's own fix plans run without you when every step may. A plan runs when each of its steps may run on its own or in the window and every dry run is clean, with the plan's own rollback. A step that needs a person still sends the plan to you.
• Status-page notices and release notices post themselves. They use a fixed template and are refused if they would show an address, a hostname, a path or a secret. At most one public notice goes out per day.
• OpenSCAP and known-exploited CVE fixes run in the window, with a daily limit. Before, they were only suggested.
• Nothing dies quietly, and there is less noise. A failed AI task is retried once with the reason, and an expired approval is filed again into the next window. "WAF blocked" and "OpenSCAP scan complete" become one line each in the morning report. The AI rotates the status server's credentials itself and lists other secrets once a week.

Upgrading

• Review and publish the AI Use Policy draft (Policies). It describes what the AI staff now do.
• Settings you changed yourself on the AI autonomy page are kept. Only defaults you never touched move.

Why

Too much still landed on a person: approval cards for updates outside a window, fix plans waiting for a second person, status notices waiting for approval, failed tasks and expired approvals that quietly died, and notification noise.

Security release. Update promptly.

The Desk and the Dashboard now show the same numbers, and every card and chart opens the list it counted.

Fixed

• The Desk and the Dashboard agree. Both read one summary of the estate: incidents firing, acknowledged, open and resolved, incidents over 30 days, response times, fleet, compliance, CVE and known-exploited, and everything waiting for a person.
• "Waiting for a person" counts everything. The Desk counted only one kind of approval and could read 0 while change plans, AI cards and fleet updates waited elsewhere. It now counts all of them, narrowed to what you may approve.
• Response times are measured on the same incidents. Time to acknowledge and time to resolve are averaged over one set of incidents, so the two no longer contradict each other.
• Every card and chart opens its list already filtered. "Firing" opens the firing incidents, "Open" the open ones, a chart bar its day or severity, and known-exploited CVEs the KEV list. The incident list reads the filter from the link and shows it.
• Upcoming maintenance is in date order. The next window comes first, with its servers. On-call people are listed once, with their schedules.

Security

• Keys and tokens are masked in incident and alert titles. They are masked when an incident or alert is created, and the ones already stored are masked by this update. They no longer show in Recent incidents, on the Desk or in the bell.

Why

The two home pages disagreed: approvals, incident counts and response times all differed between them. Several cards opened an unfiltered list, and some alert titles still showed a key.

Your AI staff now work on your everyday model and consult the strong model only for the decisions that matter. The AI spend page names the AI engineer behind every call.

Added

• The spend log names the AI engineer. Each call shows who did the work, for example "SRE / On-call Engineer (AI)", and under it either the person who asked for it or "on its own". You can filter by engineer, and an AI engineers card shows what each one spends.
• You can see when the advisor is used. Each call shows whether the advisor was consulted, how often and at what cost, and the summary shows the advisor's share of the total.

Changed

• AI staff consult the strong model instead of always running on it. An engineer's plan and the Security Engineer's work run on your provider's everyday model, which consults your advisor (for example Opus 5.5) for the decisions that matter. Where no suitable advisor is set, or you pinned a model for that job, the strong model still does the work.

Why

Work that acts on production ran entirely on the strongest model, so every step cost its price and the advisor you set up was never used. The spend log also showed the person behind a task instead of the AI engineer that did it.

Your AI staff now settle alerts about your own platform themselves, and every e-mail Stasys sends is in your branded template.

Changed

• No more allow-list requests for activity the AI proved is your own platform. When an engineer has shown that an alert comes from your own systems at work, such as a test runner or your hosting platform running commands in its containers, it applies the same narrow exception that "Not a problem — this is …" would, and closes the incident with the evidence. The exception covers only that server and that kind of activity, and it never silences an alert. When the engineer is not sure, it still asks, in the bell and the morning report, without an e-mail.
• Every exception the AI makes expires after 90 days. It is listed as "AI-made by " with its evidence and expiry, in the morning report and in the monthly review of AI actions. You can revoke it in one click from Threats or from the incident. Requests already waiting are checked again by the engineer who filed them.

Fixed

• Every e-mail is in your branded template. Some e-mails, "Needs a person" among them, went out as bare text. Any e-mail written as text is now laid out with your logo and colours. "Needs a person" e-mails say why the AI asks and what it prepared, and have a button that opens the approval.

Upgrading

• The AI Use Policy and the "AI in the ISMS" statement for auditors arrive as new draft versions. Publish them so your policy matches what the AI staff now do.

Why

You were being asked to approve exceptions for activity the AI had already proven was your own systems at work, and some e-mails arrived as bare text.

Maintenance windows now finish an upgrade with a reboot that works, never undo a good upgrade because a reboot failed, and leave a busy server alone. This release includes host agent 0.168.0.

Added

• A busy server is not interrupted. Before upgrading or rebooting a server, the window waits while the server says it is busy, checking every minute until the window ends. It then moves the server to a later window, within your maintenance policy.

Fixed

• The reboot after an upgrade works on Ubuntu and Debian servers. It failed with "no grubby, or no grub-set-default with a known menu entry, on this host". The agent now finds the boot entry itself, and a server that cannot boot a new kernel once with a fallback gets a plain reboot.
• A failed reboot no longer undoes a good upgrade. The packages stay installed. The result says "upgraded, reboot did not run" with the reason, and the reboot is done in a following window.

Upgrading

• Servers receive host agent 0.168.0 through their normal agent update.
• A program that must not be interrupted can mark its server busy by holding a shutdown lock (systemd-inhibit) or by writing /run/stasys/busy. The operations guide describes both.

Why

On Ubuntu and Debian servers the reboot after an upgrade failed, so new kernels were installed but never started, and the window then rolled back upgrades that had worked. Windows could also land on a server in the middle of its own work.

Your AI staff now work every open incident: they investigate it, act on what they find within your autonomy settings, and close it with the evidence when it is proven.

Added

• After investigating, the engineer acts. It applies the fix it found when your autonomy settings allow it, and otherwise files it for approval. It closes the incident with the evidence when the activity is your own platform at work or when the fix has taken. It never allow-lists a detection itself; that is filed for a person to decide.
• Nothing waits unnoticed. Every 30 minutes the AI staff pick up open or acknowledged incidents that nobody has investigated yet, within the daily limit.

Fixed

• Security events on a named server are investigated. The server is now taken from the security event itself, or from the incident title when it names an enrolled server.
• Warnings are investigated too. Warnings run at a lower cost limit per investigation. The daily limit is unchanged.

Security

• Keys and tokens are masked in security alerts. A captured command line could show an enrollment key in an alert's title. It is now masked wherever the incident is shown, including older incidents.

Why

Incidents could stay open for days with nobody looking at them. Security events on a named server were skipped, warnings were never investigated, and an investigation could only read and write a note.

Ask for something in the chat and your AI staff now do it. They no longer stop because your personal AI allowance ran out.

Fixed

• The chat assistant hands your request to the right engineer. A request that changes something (patching, a package upgrade, a reboot, a playbook, a fix) goes to the engineer who can do it, and the chat gives you the task link. The engineer works under your autonomy settings, the same as for work it starts itself.
• An engineer's work no longer runs out on your personal AI allowance. A task you ask an engineer for, from the chat or the Delegate a task panel, now runs on the background allowance and keeps its own cost limit. Your personal allowance is left for your own chat with the assistant.

Why

Asked to patch the servers, the assistant answered that someone on your team would have to do it. Asking the engineer directly stopped with "Your daily AI token budget is exhausted". Both are fixed.

Your compliance e-mails now show only the frameworks you adopted, and their scores match the compliance dashboard.

Changed

• Board reports are approved by a super admin. This corrects the 0.17.4 notes, which said to give the approval permission to another role. Roles are fixed, and that permission cannot be granted to another role.

Fixed

• The weekly compliance digest and the monthly executive summary list only the frameworks you adopted. They used to show a percentage for every framework Stasys supports, more than twenty, even when you had adopted one. Adopt or remove frameworks under Compliance → Frameworks.
• Digest scores match the compliance dashboard. Both e-mails now use the dashboard's own scores, including its rule that a control nobody has assessed yet is not counted as failed. A score that covers only part of its framework says so, for example "30 of 40 assessed".
• Blocking failures and expiring attestations cover your adopted frameworks only. With no framework adopted, the weekly digest says so and points you to Compliance → Frameworks.

Why

A digest listing more than twenty frameworks you never adopted buries the one you care about. It also showed numbers that didn't match the dashboard.

Supplier reviews now run on a schedule without anyone chasing them, and customer security questionnaires are answered from your own evidence. People still accept supplier risk and send the answers.

Added

• Supplier reviews on a schedule. Every supplier is reviewed once a year by default, critical ones every six months and low-risk ones every two years, or on the cadence you set for that supplier. The AI Compliance Officer sends the security questionnaire and reminds the supplier after 7, 14 and 21 days. It then scores the answers together with the supplier's certificates and outside-in score, and proposes a risk rating with its reasons. A person accepts or changes the rating on the supplier page; a changed rating needs a reason. The Suppliers list shows which reviews are due this month.
• Security questionnaires answered from your evidence. Under Compliance → Security questionnaires, upload a customer's questionnaire as Excel, Word or CSV. The AI drafts every answer from your live controls, policies, certificates and evidence, cites what it used and says how sure it is. Answers with no evidence are flagged and never a bare "Yes", and a certification is claimed only when a current certificate is on file. Answers you approve are reused the next time the same question comes up.
• Review the answers, export them and send them. Edit or approve each answer, or approve all the well-supported ones in one go. Export the answers back into the original spreadsheet or as a clean document, with a page saying the answers were AI-assisted and naming the people who reviewed them. Sending them to the customer is always a person's act. PDF questionnaires are not read yet; save them as Excel, Word or CSV.

Upgrading

• Decide whether the AI may e-mail your suppliers (Suppliers page). It is off by default, so a person approves each questionnaire and each reminder before it goes out. Switch it on and they go on their own. Accepting a supplier's risk always stays a person's act.
• Check each supplier's security contact. The review cycle sends the questionnaire only to that recorded address, and does not start a review for a supplier that has none.

Why

Supplier assessments and customer questionnaires are the compliance chores that never end. The AI now does the legwork, and a named person decides on the outcome. Every proposal and answer keeps the record auditors look for.

The AI Compliance Officer now drafts the papers your management signs: the monthly board report, the ISO 27001 management review pack and policy updates. Each stays a draft until a named person approves it.

Added

• A monthly board report, drafted for you. Compliance → Board reports covers risk posture and trend, incidents with time to acknowledge and resolve, patch, backup and restore state, the security grade, compliance per framework and how it moved, the top risks and the decisions waiting for the board. It is drafted on the 1st of each month, or when you ask. The measured figures and the AI's narrative are shown and printed apart. Once a person approves it, it is a PDF you can hand to the board.
• The management review pack written for you (ISO 27001 clause 9.3). The AI drafts a paragraph for every required input from your live data. A review cannot be signed while its pack still waits for a person, and the minutes print the narrative only after a person has approved it.
• Policy updates drafted when something changes. When you adopt a framework, a control mapped to a policy keeps failing, a policy review is overdue or a relevant system change happens, the AI drafts a new version with the changes, the reason and the controls it covers. It never touches a published policy or a version someone is editing. Draft with AI on a policy page does the same on request.

Changed

• Every AI draft carries its full record. Each draft records the engineer, model, prompt version, sources, time and a fingerprint of the approved text. The person who asked for a draft or edited it cannot also approve it, and an approval whose audit entry cannot be written does not count.

Upgrading

• Board reports are approved by a super admin. The person who signs the report for your board approves it from a super admin account, and someone who asked for the draft or edited it cannot approve it.

Why

These are the documents an auditor asks to see first and the ones that take people the longest to write. Your team now reviews and approves them instead of writing them, and every approval keeps the record auditors expect.

Your AI Compliance Officer now does the day-to-day compliance work on every framework you adopted. It reads the live evidence, keeps it fresh, drafts what is missing and prepares you for an audit. Everything it writes is marked, carries its full record and counts only once a named person approves it, so certification auditors can accept it.

Added

• The Compliance Officer reads your live evidence. It reads control state, evidence, attestation history, the Statement of Applicability and CVE findings, for the frameworks you adopted only.
• Compliance work that runs itself. A weekly drafting run across your frameworks; daily re-checks of live evidence links, re-dated only when they still work; and regulator notification drafts (NIS2, DORA, GDPR) as soon as a reporting clock starts, with the time left sent to the owner.
• Audit preparation playbook. Pick a framework and the audit date. The AI re-checks every control, refreshes evidence, lists every gap with an owner, a fix and a due date, hands technical fixes to the other AI engineers and drafts the auditor pack for a person to issue. Readiness is tracked daily.
• Compliance score history, one record per framework per day. See the trend for each framework over time.
• See the work done by your AI staff. Tasks, results, time and cost for each AI engineer.
• A signed AI decision log for auditors, and a statement on AI in your ISMS. The decision log comes as JSON and CSV in the auditor pack and portal. An "AI in the ISMS: Statement for Auditors" document is mapped to ISO 42001, ISO 27001 and SOC 2.

Changed

• Seven steps are always a person's. Attest a control, approve the Statement of Applicability, accept a risk, approve a policy, submit to a regulator, sign a management review and accept supplier risk. The AI can only hand the person its draft.
• Everything the AI touches is marked, in every auditor output. Statement of Applicability entries, nonconformities, evidence, attestations, answers and regulator drafts are marked. The SoA PDF, evidence pack, auditor portal, auditor pack and conformity pack all show what the AI drafted and who approved it.
• Four-eyes on AI drafts. Whoever started a drafting run cannot approve its drafts. This is on by default; switching it off is recorded and disclosed. Statement of Applicability exclusions and attestations cannot be bulk-approved.
• Approvals record the model, the prompt version and a fingerprint of the approved text. An approval is undone if it cannot be written to the audit log.
• Linked web pages are snapshotted and fingerprinted. They are captured when linked and again at every refresh. AI-written narrative is filed as such and never counts as evidence.
• The AI's own compliance actions are approved under their own permission. It is separate from the permission used to attest a control.

Upgrading

• Review the new AI Use Policy draft (Policies). It describes what the AI staff really do: some actions only after your approval, routine ones on their own with a recorded human review afterwards, and the steps that are always a person's. Approve and publish it so your policy matches practice.
• A monthly AI actions review now appears for your compliance manager: a person confirms what the AI staff did on their own. ISO 42001's human-oversight control passes while these reviews are on time.

Why

An auditor may reject AI-produced material that isn't clearly marked and approved by a person. This release keeps the AI doing the work while every artefact stays traceable: who drafted it, with which model and sources, and who approved it.

Your AI staff now run the estate: they patch, reboot only where needed, back up before every change and put a server back if a change fails, keep the status page to one clear notice a day, and report every morning.

Added

• Playbooks: multi-step work the AI staff carry out over hours or days. "Patch in a maintenance window", "Patch the whole estate now" and "Back up every unprotected server", each step checked before the next (AI staff → Playbooks).
• Every server change is backed up first and put back if it fails. A fresh backup and a record of package versions and kernel before the change; a health check after it; if unhealthy: previous kernel, earlier package versions, then the files from the backup. That server stops, the others go on.
• A morning report in the 07:00 brief. Every server updated, rebooted, put back or failed, with packages and CVEs fixed.
• About 25 new AI actions across the estate. Maintenance windows, security updates on apt, dnf, zypper, Alpine, Arch and Windows, reboots, status page, backups, AV, OpenSCAP, compliance checks, disk cleanup, certificate renewal, IP blocks and WAF. Every engineer gets the actions for its job.

Changed

• One status-page notice per day. Same-day maintenance folds into one entry naming only the public services affected; servers without a public service get no public notice.
• Reboots only where needed. A server is restarted only when a kernel or core package changed or it reports a pending restart.
• Better AI agents. Native tool calling with parallel reads, prompt caching through a whole task, the right effort per job, memory of fleet facts, runbooks loaded when relevant, a scorecard of results, and a locked service identity per engineer.
• Background AI work is paid from the background budget. Including tasks you delegate, with a per-task ceiling and a daily delegation quota.
• Host agent 0.167.0. Disk cleanup, certificate renewal, package downgrade, Windows update uninstall and safe kernel switching.

Fixed

• No more false "no backup" bar for your console. The console counts as backed up when the fleet backs it up to another server; a missing dead-man's switch is a recommendation. If it is not covered: one click to back it up to your backup server.

Upgrading

• The AI staff start working after this update, within AI staff → Action autonomy. Routine work runs and is reported; server changes (updates, reboots, restarts, disk cleanup, certificate renewal) run only inside booked maintenance windows; WAF to blocking, isolating a server and arbitrary change plans wait for your approval; deleting data, access and DNS changes are never done. Choices you saved are kept.
• Servers update their agent to 0.167.0 themselves; until a server has it, putting it back after a failed change can only restore files from the pre-change backup.
• Existing same-day maintenance notices are merged into one entry per day.

Why

Stasys is meant to take the routine work off your team. Until now the AI staff could only suggest; now they act within the rules you set, safely and with proof.

Stasys no longer changes a web firewall someone else set up, and the AI staff can do their work without asking you to approve every read or spending your personal AI allowance.

Changed

• Host agent 0.166.0.

Fixed

• Stasys no longer changes a web firewall someone else set up. The baseline policy goes only to WAFs Stasys installed, and never turns a blocking WAF into detect-only. Servers run by Kontrol7, cPanel, Plesk or DirectAdmin, or with a ModSecurity folder shared by nginx and Apache, are reported on and never written to.
• Kontrol7 servers are fenced on every engine, including LiteSpeed and the control node. If Stasys cannot confirm whether a server belongs to Kontrol7, it holds back instead of going ahead.
• WAF status shows what is really on the server. A server whose Stasys WAF file is gone no longer shows "applied and verified". Leftover assignments on Kontrol7 servers are released, and an uninstall a server refused is not retried.
• "Attacks that reached a site" counts only WAFs Stasys runs, across every server. It used to include servers whose WAF someone else runs, and added up only the top ten.
• Switch-to-block proposals only for WAFs Stasys owns. A pending proposal for someone else's WAF is refused when approved.
• WAF exclusions take effect whichever order the rules load in. Only the newest three backups of each edited config file are kept.
• AI staff on duty can read what their job needs without asking you. The security engineer reads CVEs, the compliance officer compliance data, and so on. Anything that changes a server still needs approval.
• AI staff work is paid from the background AI budget. It is no longer charged to the person who approved it, and each engineer drafts at most four tasks an hour, so going on duty cannot drain a budget in minutes.
• A backup restore check that runs out of time stops and says so. It removes its copy and shows "ran out of time" instead of waiting forever.

Upgrading

• Update the agent on your servers to 0.166.0 (it updates itself); servers on older agents keep the previous WAF behaviour until they do.
• Servers run by Kontrol7, cPanel, Plesk or DirectAdmin, or where nginx and Apache share one ModSecurity folder, now show "Stasys reports only" on their WAF tab.

Why

On servers where a hosting panel or an administrator runs its own ModSecurity, two managers of one firewall override each other and can stop the panel from applying its own changes. This release makes the rule simple: whoever installed the WAF owns it; Stasys reports on the rest.

Standby is now Stasys, with a new logo, and the hosting control panel is shown as Kontrol7. This release makes the platform quiet by default: one problem is one incident, your AI staff take care of routine work, and every queue has an owner.

Added

• Your AI staff are on duty and do routine work on their own. Each AI engineer watches its recommended triggers. Per action you choose: act and report, act only in the maintenance window, ask for approval, or never. Defaults: notes, acknowledging and resolving recovered incidents happen on their own; server changes need approval; destructive actions are never allowed. A morning brief lists what they did and at most three things that need you, and the AI layer raises one incident if it stops working.
• Test and staging servers no longer page as critical. Mark a server's environment on its page. Known-exploited vulnerabilities, malware and confirmed intrusions still page at full severity.
• Detections become decisions you can clear in one step. Threats → Decisions groups unacknowledged detections by source, rule, server and attacker network. Acknowledge, dismiss or mark a whole group as benign; benign patterns are filed automatically from then on.
• The backup restore check proves a real recovery. With agent 0.165.0 it restores a database dump and a large file and shows how long it took. Older agents keep the small check and say it is a weak proof.
• A missing off-site backup of this install is a blocker. It can be snoozed for 24 hours at most.
• Hourly self-tests that speak only when something fails. Paging channels, security events, OpenSCAP scores, restores, the AI provider and the vulnerability feed are tested every hour; one incident per failing test.

Changed

• Standby is now Stasys, with a new logo; the hosting panel is shown as Kontrol7. Everything you read and see uses the new names. Your install, its address, its commands and its update channel stay as they are, and your own branding still wins.
• One problem is one incident. A condition that keeps coming back adds to its open incident, or re-opens it within 6 hours, instead of opening a new one each time. You are paged again only if it got worse. A switched-off alert source creates no incidents.
• Approvals expire after 7 days, and scheduled pen tests run in the maintenance window. Whoever asked is told when a request expires. Routine pen tests no longer wait for a click.
• Old notifications fold into a weekly summary. Anything a week old that nobody acted on is summarised once, so the bell counts only what is new.
• Your own platform's actions are no longer raised as attacks. Kontrol7 installing a node and the agent updating itself are recognised; anything outside those narrow patterns still alerts.
• The security overview and queue load at once. They answer from a short cache and show when the figures were computed.
• Host agent 0.165.0. Needed for the new restore check.

Security

• Dependencies updated for security fixes. undici, nodemailer and others. After an update the admin UI's build tools are removed from the server.

Upgrading

• Your AI staff start working after this update. Notes, acknowledging incidents and resolving incidents whose checks are green again happen on their own and are reported; anything that changes a server still waits for your approval; destructive actions are never allowed. Adjust under AI staff → Action autonomy. Without an AI provider you get one incident saying so.
• Approvals now expire after 7 days. Scheduled pen tests run inside each server's maintenance window.
• Servers whose web firewall never received a policy get the baseline policy in detection mode (nothing is blocked). Turn off with waf.default_policy_auto_apply.
• Mark test and staging servers (server page → Settings → Environment) so they stop paging as critical.
• Your install, address, commands and update channel are unchanged by the new name.

Why

A small team should be able to read everything the platform tells them. Repeated alerts, unowned approvals and thousands of unread detections buried the problems that matter; this release turns them into a short list of decisions and lets the AI staff handle the routine.

If your console only lets in your own address, a new server can now install the agent. Before this release the install command was refused.

Fixed

• A new server can install the agent when your console is locked to your own address. The install command used to stop with 403. The agent installer now gets through the lock from any address. It still needs the enrolment token in the install command, and without one it answers 401 and serves nothing.
• A lock set up with your fleet's addresses is corrected when you update. The change appears as a new version of that firewall policy. Your servers get the corrected rules within a few minutes, with no edit by you.

Why

The lock let in servers you had already enrolled, and a new server only becomes one by enrolling, so no server outside your own address could ever be added.

Incidents now name the right server and say what actually happened.

Changed

• Clearer incident list. The list says "not paged", like the incident page. The Tags column only appears when something is tagged, and the server's name is no longer repeated in the title. The runbook link now reads "Choose a runbook for incidents like this".

Fixed

• Incidents are linked to the right server. An uptime check's incident showed the check's number as a server ("on #42") and linked to whichever server had that number. A rule's incident could link to the server whose number matched the rule's. Now only alerts that really name a server link to one.
• An uptime check's incident names the server the check belongs to. It used to take a domain from the check's name and show it as an unenrolled server. It now names the server that owns the check's status page component, or no server at all.
• Hosting platform servers are linked to your fleet. The platform names its servers by full domain name, while your fleet uses short names. Alerts and incidents about those servers now name and link the server in your fleet.
• A site that answers is no longer reported as down at critical. An uptime incident now says what came back, for example "answered 200 instead of the expected 403", at high severity. Only a site that gives no answer, a server error or a timeout is reported as down, at critical.
• "Why it fired" explains an uptime check in plain words. It says what was checked, what came back and which server the check belongs to, with an "Open the check" link. Internal numbers and raw paths no longer appear.
• The timeline no longer lists unconfigured channels as failures. SMS and voice that were never set up used to show as failed at every escalation step. The timeline now says once that they are not set up. A message held back as a duplicate reads as not sent again instead of "deduped:499".
• A rule that keeps coming back reopens its incident instead of opening a new one each time. A rule that fires again within a day of clearing reopens the same incident, which shows it happened several separate times. It does not page again within two hours.

Upgrading

Nothing to do. Incidents opened before this update keep their old titles. Their pages and the list show the new server names and wording.

A paired hosting platform can book maintenance on its own servers again.

Fixed

• A paired hosting platform can book maintenance on its own servers again. The platform names its servers by full domain name (for example node4.example.net), while the servers themselves report a short name (node4). Standby therefore recognised none of them as the platform's own and refused every booking, including Update now and Schedule. A server now counts as the platform's in three cases: the full names match; the address the platform reports for the server is the server's; or the short names match and the server holds the platform server's address. A short name alone is never enough, because two platforms can each have a node4.
• Platform servers are recognised the same way everywhere else. Standby leaves a platform server's web filter to the platform. A platform server that goes quiet now gets the platform's grace period before it pages.

Upgrading

Nothing to do.

Added

• Fleet updates follows Incus. Every Incus package is always tracked, whether it comes from Debian backports or Zabbly, and one release of all its packages is one approval. A tracked-package list you saved earlier gains them without being edited.
• Packages installed from Debian backports are named as not checked for vulnerabilities. The Debian security tracker does not cover backports, so no advisory source can say whether such a package is affected. The CVE page and the host's Updates tab now list them, instead of leaving a quiet page to read as clean.

Fixed

• A backports package no longer reads as fixed because it is newer than the release's own version. Backports builds were compared against the fixes for the release's own version line, so every advisory looked fixed. They are no longer matched that way, and findings already open for them are left as they were.

Upgrading

• None.

Why

Incus runs every hosting server. Its upgrades now show on Fleet updates from any source. Packages installed from Debian backports, which no security tracker covers, are now called out instead of looking checked.

The result of a maintenance window now reads as one sentence, in the result email and for a paired hosting platform.

Added

• A paired hosting platform shows how each server update it asked for went. Once a window ends, the platform shows the result beside it, for example "3 of 3 servers updated, 41 packages, rebooted 1" or which server failed and why, along with each server's own result. For its own platform updates it shows what it reported itself.

Changed

• The maintenance result email leads with the same one-sentence summary. It says how many servers were updated, how many packages were installed and how many servers rebooted, and names any server that failed, with the reason.

Upgrading

Nothing to do.

Why

Whoever pressed Update now sees what happened without opening the maintenance page.