Release notes 0.1.128 to 0.1.144

Archived release notes, newest first: 0.1.144 (23 October 2026) back to 0.1.128 (14 October 2026).

Release notes · Updated 2026-10-28 · Describes release 0.1.164

0.1.144 — 23 October 2026

• Step runbooks: a remediation route can now hold an ordered runbook: check, back up, change, validate and roll back steps, with its targets as parameters that code binds from the alert that opened the incident. In the route editor, Add runbook steps starts one and Check runbook shows the bound steps, a quality check and Permissions the write role needs, with a least-privilege IAM policy (AWS) or custom role (Azure). Check the write connection's permissions asks the cloud whether the write connection holds them; it is read-only and audited (route.permissions_checked). An approver can certify a step runbook only when its quality check passes and its write connection does not lack a permission it needs. A step uses the typed operations a prepared plan uses: there is no patch, EBS modify or script step yet. Routes without runbook steps behave as before.
• A certified runbook carries its own operations (on by default): a step runbook certified at its current revision pre-approves its own backup and change operations. Guardrails → Pre-approved operations now applies to single-call routes only, and certifying a runbook no longer adds to it. Pre-approving a validated fix from its incident now builds a step runbook, and waits until that incident is resolved. The switch is A certified runbook carries its own operations (runbook_owns_operations, AIOPS_RUNBOOK_OWNS_OPERATIONS); off, every route needs its operations ticked on Pre-approved operations again.
• Standard means an exact runbook match: a change request is standard only when a certified runbook matches the fix exactly: the same operations, in the same order, on the targets the runbook binds, with nothing manual beside them. A fetched runbook skill alone no longer makes a change standard. A runbook demoted, disabled, uncertified or edited before the request is released turns it normal (emergency at P1), shown as runbook withdrawn and audited change.class_dropped. Covering one change with several certified runbooks in order needs Let several runbooks cover one change request (runbook_multi_cover, off).
• A P1 with a certified runbook is standard: such a change is released under the standard rules (one approver, or an operator at L1/L2), not the emergency rules. Until this release it was recorded as standard but kept the emergency release rules; a request recorded before the upgrade keeps the rules it was stamped with.
• A person may only raise a change class: Reclassify offers normal to emergency, or a standard that no runbook backs to normal or emergency. Lowering a class is refused with a 409 that says why. A certified runbook's standard class cannot be reclassified: demote or disable the runbook instead. Until this release a class could also be lowered.
• Certified runbooks may run on their own: with Allow pre-approved routes to auto-fire and the switch on the Automatic API fixes for proven runbooks card both on, a standard change that certified step runbooks made is released with no click through its change request, when every guard holds: still certified at the stamped revision, a class no person set, targets bound from the alert, L1 or L2, the runbooks' own write connections, and their permissions present. An incident about an unauthorized change never runs this way.
• Runbook steps on the incident and the change: the incident's L5 row and the change page's Runbook steps card list every step in order with its status: not started, running, done, failed, skipped after a failed step, or not needed.
• Back up before a reboot (on by default): before a reboot of an EC2 instance or a restart of an Azure VM, the platform takes an AMI (without rebooting) or a snapshot of the OS disk through the same write connection, and waits up to 30 minutes for it. Without a usable backup the change does not run and nothing is written. Over a CLI write connection the review refuses such a plan. The backup is tagged aiops:retain-until (Keep pre-change backups for (days), 7) and aiops:change; the platform never deletes it. An AWS image backup makes a root-volume restore the rollback a person releases, never automatic. The switch is Back up a stateful target before a reboot-type change (Guardrails → Change safety, backup_before_change).
• Validation runs the change request's plan: each change request an analysis drafts now carries the list L6 checks, fixed at the draft and approved with it: each changed resource with the read that observes it, the plan's criterion, and every service one hop away on the dependency map, upstream and downstream, at most 10 items. After the fix the platform reads the changed resources itself first; the verify agent gets only the listed items and no web research. A failing neighbour keeps the verdict at uncertain. The incident's L6 row and the change page list the items with their results. Older change requests are verified as before.
• The change request document: every change request page shows a Change request document card in the customer's template: version control, requesting organization and sections 1 to 9, each filled from the platform's records or marked Not provided yet. Download Markdown and Download Word export it, and the ticket write-back at close carries it. The workspace setting cr_template sets the organization name and one line above the title.
• Change management agent (off by default): Guardrails → Change management agent holds two switches. Let the change management agent draft change requests (change_agent_cr) starts one short change-agent run per change request, at most 8 steps over what the analysis recorded, to write the narrative sections; operations, class, tier, approvals, validation, rollback and cost stay the platform's. Let the change management agent draft the fix too (change_agent_owns_plan) moves the plan from the analysis to that run. Each run is paid. Draft with the change agent asks for a new draft. With both off, the analysis drafts the fix as before.
• Unauthorized-change incidents (off by default): with Open an incident for every change with no reference on (Guardrails → Unmanaged changes, unauthorized_change_incidents), a write captured from CloudTrail, the Azure activity log or a Kubernetes audit log needs a reference: a platform receipt, a principal on change_authorized_principals, an approved ServiceNow or Jira change ticket naming its resource or service inside its planned window (itsm_change_match), or a signed change request naming the resource. Without one it opens a change incident per action (one principal and account within 10 minutes), with no analysis, a ticket through the on-open ticket route to the group named in unauthorized_change_ticket, and a revert drafted per change. On the incident's Unauthorized change card an approver chooses Approve rollback or Keep this change (legitimate) with a note. No automatic fix or rollback ever acts on it. Fill the allowlist with your CI/CD roles before turning it on.
• Denied access goes to SecOps (on by default): while the SecOps agent is enabled, denied access attempts open one SecOps incident per principal, account and clock hour, at P3, with no analysis; its Denied access attempts card lists the refused calls. The switch is Report denied access attempts to SecOps (Guardrails → Unmanaged changes, denied_access_to_secops); off keeps them on the Changes page only.
• Automated triage (on by default): every incident triage takes seven steps, shown on the incident's Automated triage card at L4. Three are code, at no model cost. Before the first agent turn the platform reads the cloud provider's health (AWS Health, else the public AWS Health Dashboard; Azure Resource Health and Service Health) and the known issues: incidents on services one hop away, open or resolved within 24 hours (aiops_triage_related_window_h), and open ServiceNow, Jira or Azure DevOps tickets naming the service. What it finds goes to the analysis. After the wrap-up, code names the fault domain, written as ## Fault domain in the report. The switch is Check cloud health and known issues before each analysis (Guardrails → Automated triage, triage_checklist); the fault domain stays when it is off. AWS Health needs health:DescribeEvents: the guided AWS setup's read role gains it in this release (re-run the setup), and a role on ReadOnlyAccess already holds it. Without a Business or Enterprise support plan the step reads the public AWS Health Dashboard instead, which is not account-specific.
• Scanner HIGH is P2: a Security Hub or Defender finding of severity HIGH now maps to error, which is P2; CRITICAL stays critical, P1. Until this release HIGH was also critical, so both were P1. The usual raises still apply: a blast radius of two or more services or a mission-critical resource lifts the priority one level each, and a CVSS 9 or higher finding on an internet-facing resource is raised to critical. A register row takes the new severity the next time the scanner sends the finding; an incident already open keeps its priority.
• A P3/P4 finding with a prepared fix waits: a P3/P4 compliance finding no longer starts a paid analysis because a prepared fix exists, pulled or pushed. The incident reads A prepared fix is available — waiting for a person to start it, and Analyse starts it. At P1/P2 a prepared fix still runs.
• Scores per standard, patching and backup: Security posture → Audit & coverage → Scores shows the score of every enabled Security Hub standard, every AWS Config conformance pack and SOC 2 / ISO 27001 (while framework scoring is on), the total with each check counted once, and the mean of the standards beside it, with a daily trend. Patch compliance reads Patch Manager and lists EC2 instances Systems Manager does not manage; Backup reads AWS Backup jobs over 24 hours and 7 days. The reports are read once a day (AIOPS_COMPLIANCE_REPORT_INTERVAL_S, 86400) and on Refresh reports (incidents.act). An optional "patched within N days" rule (aiops_patch_within_days) has no default. Azure is not read yet.
• The agreed comparison table: the Frameworks page's Agreed comparison table card downloads every SOC 2 / ISO 27001 row with what judges it and the Security Hub controls, AWS Config rules and Azure Policy groups public mappings put behind it, as CSV or Markdown. Record acceptance (pillars.manage) records who accepted which version; a changed table needs a new acceptance. Your own requirements adds the workspace's own rows, judged by platform rules or scanner controls. The page says which version the frameworks are scored against, and the Scores tab marks SOC 2 / ISO 27001 not agreed until an acceptance is recorded.
• Service group view: under the Estate map, Service group walks one service out of the estate model, from a name, a resource id or tag:<key>=<value>: its endpoints, compute, data stores, subnets, security groups open to the internet, firewalls on the path, the network path and its calls, each row with its source and when it was last seen (GET /estate/service-group, report.view; MCP get_service_group).
• The AWS network path: the harvest now reads route tables, VPC endpoints, transit gateways, their attachments and route tables with their routes. A transit gateway shared from a network account keeps that account's ARN, so hub and spokes join once both accounts are connected. A Gateway Load Balancer endpoint now counts as firewall evidence, on the no-firewall banner and among a service group's firewalls on the path.
• FortiGate and Palo Alto Networks connectors: FortiGate (FortiOS REST API) and Palo Alto Networks (PAN-OS API) are read connections. Their read gate allows reads only: a FortiGate configuration backup, revision or credential table, and a PAN-OS XML request that is not a bounded read, are refused. The estate harvest draws the firewall, its interfaces and its enabled allow policies; two skills check a flow across it; an Estate x-ray finding that names one offers the connection. A FortiGate policy carries its hit count, bytes and first / last use from the policy monitor (never for a policy no traffic has hit), and these moving counters never show as a change made outside the platform. The API key travels in a header only: a FortiGate access_token or a PAN-OS key / password in the URL is refused, and PAN-OS type=keygen is never offered to an agent. The setup pages describe a read-only API admin (FortiGate REST API admin with a read-only profile and a trusted host; PAN-OS admin role with read-only REST resources and XML operational and log requests, and the API key lifetime). Both are drafted from the vendors' public documentation and were not yet validated against a device when released; since validated against FortiOS 8.0.2 and PAN-OS 11.2.15 lab firewalls (23 and 26 October 2026).
• Re-run the cloud setup: the AWS read role gains the conformance pack, Patch Manager and backup:ListBackupJobs reads, six transit gateway and VPC endpoint reads, and health:DescribeEvents (automated triage); the AWS write role gains the image and snapshot creates, their describes and the root-volume restore, on instances and volumes tagged aiops-managed=true, and nothing that deletes; the Azure write role gains disk and snapshot reads and snapshot writes. Until the setup is re-run, those reads show as denied and a reboot stops at its backup step. Upgrade and release verification lists every action.

0.1.143 — 22 October 2026

• SOC 2 / ISO 27001 scoring is a workspace switch: a Framework scoring card on the Frameworks page (owners, members.manage) switches the framework score on or off (compliance.enabled). A new workspace starts with it off and is switched on at onboarding, once the mapping is agreed; an existing workspace keeps scoring. With scoring off, no control runs and no control finding opens; Security Hub and Defender findings keep flowing. Both switches are also on GET / PATCH /guardrails (compliance_enabled, compliance_platform_controls).
• The platform's own checks leave the score: the 13 deterministic checks of the platform's own settings (ACC-02 to ACC-04, LOG-01, DAT-01, DAT-02, CRY-01, CHG-01 to CHG-03, SEG-01, MON-01, MON-02) no longer count toward SOC 2 / ISO 27001 unless compliance.platform_controls is on; their requirements fall back to attestation. They still run on every scan, so a failure still opens its control incident and a pass still closes it. ACC-01 (the connections' own principals) stays in the score.
• EST-06 says what it reads: AWS console users without MFA and active access keys older than 90 days (the first 50 IAM users), and Azure Owner assignments made directly at subscription scope (more than 3). Its benchmark is Security Hub IAM.5 / IAM.3. DRIFT-01 (GitOps drift) still runs but scores no requirement: its verdict comes from a model.
• P1/P2 automatic, P3/P4 wait for a person, for every compliance source: a compliance finding pushed by webhook and a failing platform check now follow the pulled-finding priority rule. P1/P2 (or a finding with a prepared fix) is analysed when it opens; P3/P4 opens with the receipt "its priority is below P2" and waits for Analyse. SecOps threat findings are unchanged.
• Fix or Suppress: the risk decision dialog offers Fix (a change request the Change agent drafts) and Suppress (the risk is owned until its expiry and left out of every fix). The API values stay avoid and accept; mitigate is no longer offered in the portal, and decisions made with it keep it. Audit rows, the risk register, the service-delivery report and the posture trend use the same words.
• Fixed — awaiting CSPM: an incident whose scanner finding has a fix recorded but is not yet cleared by the scanner shows Fixed — awaiting CSPM; the Incidents list filters on it under Fix state (awaiting_cspm=true).
• Why a captured change raised a control: a control finding opened from a captured cloud change shows the rule's sentence and the request values (for example destinationportrange=22), on the incident and on the change.
• Reopened, repeated or new: code tags each incident when it opens: reopened (the same alert came back on this correlation key, or the incident came back after its close), repeated (seen on <service>) (the same issue on another resource), else new. The finished RCA carries a ## Occurrence line naming the previous incident and its date.
• Denied calls are unauthorized access: a write the cloud refused is recorded as a denied attempt (audit change.denied_attempt, the Denied attempts chip, denied=true), never as an unauthorized change, and the change statistics no longer count it as a change.
• Firewalls on the estate map: an AWS Network Firewall, an Azure Firewall, an instance a Gateway Load Balancer (or a GENEVE target group) sends traffic to, and a machine whose image names a known firewall vendor draw as Firewalls. When the model holds none, a banner says so, and an approver can record This environment has no firewall with a note (POST /{workspace}/estate/no-firewall, 365 days, audited). The Estate x-ray report states which applies.
• Security posture: the "From estate discovery" card is gone; an x-ray's compliance notes stay in the x-ray report (and the API).

0.1.142 — 21 October 2026

• Untagged AWS resources on the estate map: the harvest now also lists every resource AWS Resource Explorer supports, tagged or not, in a region whose Resource Explorer index is active with a default view. The platform never turns Resource Explorer on; a region without it gets a Coverage note saying so.
• AWS Config inventory: the harvest reads AWS Config's recorded inventory, one SelectResourceConfig query per region, on by default (config_inventory: false on the connection switches it off). It adds only what nothing else listed and reads no Config relationships. Config's 7-type list is now only the fallback where the query is denied. config_history no longer affects the inventory: it is the before-state of outside writes only.
• AWS service map: an AWS read connection reads CloudWatch Application Signals' service dependencies hourly (the X-Ray service graph where Application Signals lists nothing in a region) into traced service dependencies. It is the new Service map (Application Signals / X-Ray) job, on by default, key service_map. Traced edges widen an incident's blast radius and count toward a fix's risk tier, as declared ones do; they fold alerts only where the workspace opted traced edges in. A pair that Tempo or Jaeger also reports, under a different scope name, is dropped as ambiguous: switch service_map off where the same traces reach both. POST /{workspace}/topology/sync-traces and the hourly topology.traced audit row now carry an errors list, and every workspace with an AWS read connection whose service map is on and whose pillar allowlist includes Incident (or is empty) writes that row. The read runs in the background, never inside the scheduler tick, and stops on time with what it read; X-Ray API Gateway stages are kept and named after the API.
• Re-run the AWS setup: the CloudShell read role now grants Resource Explorer's index, default view and listing reads, config:SelectResourceConfig, Application Signals' ListServices and ListServiceDependencies, and xray:GetServiceGraph, and nothing that sets Resource Explorer up. Until the setup is re-run, Coverage lists those reads as denied and the service map sync records AccessDenied.
• API Gateway on the map: REST and HTTP APIs are endpoints named by the API's name, so a service-map edge such as orders-api to orders-fn attaches to the API instead of a stand-in service node.
• Estate map bands: load balancers and ingress; security groups and policies; subnets, interfaces and ports; and networks (VPC) each have their own band.
• Harvest notes and stale flags: an Estate x-ray scan keeps the notes of the harvest it ran first (they were overwritten when the mission started), and a resource is no longer flagged stale when the listing that found it came back short in a harvest (a limit, throttling or a denial) or was not asked (a region with no active Resource Explorer index).

0.1.141 — 19 October 2026

• Remediation plan card: a target or limitation list shows as a list instead of raw JSON, and the verification is numbered once: a last step that only repeats the verification folds into the numbered Verify step, and any extra words it carries stay on that line. The vulnerable-package plan rules ask for three steps with the check kept in the verification.
• Analysis sees the scanner's own words: each alert in the analysis prompt now has a structured budget — labels first, then the summary, description, recommended action, CVE ids, CVSS, vulnerable packages and the vendor's remediation — so a scanner finding's annotations reach the analysis instead of being cut after the labels. The prompt stays bounded per alert and per incident.
• Images: both images apply Debian security updates at build time and no longer ship pip; the control-plane image bundles helm v3.22.1, and kubectl is pinned to v1.37.1 in both instead of following the moving stable channel. The control-plane image's scanner findings drop from 1 critical / 58 high / 110 medium to 1 / 54 / 90, and the agent image's medium findings from 95 to 90. Every remaining critical or high finding is waiting on an upstream fix (Debian 13 packages, and kubectl v1.37.1 built with Go 1.26.8).

0.1.140 — 19 October 2026

• Knowledge used names its runbooks: each row on an incident shows the runbook's name, opens the exact version the analysis read (read-only for readers who cannot edit it; a learned runbook opens expanded in Review queue), and says in one line what its evidence level means.
• Vulnerable-package findings carry their fix: the analysis now receives each vulnerable package's installed and fixed version (vulnerable_packages, refreshed whenever the scanner re-sends the finding; a scanner's "not available" is never read as a version). For a finding with a fixed version the plan follows upgrade in the image build, rebuild and push a new digest, move the consumers, verify the finding clears, and it names the read permission or connection needed when the repository, owner or consumers are unknown. Findings under an accept or mitigate decision get no upgrade order. Incidents analysed earlier keep their old plan until someone runs Re-analyse.
• Numbered plan steps: the remediation plan numbers its steps in execution order with the verification last, and a plan made only of typed steps now shows them.

0.1.139 — 19 October 2026

• Archive page: Insights → Archive lists archived incidents and changes (search, kind, close month), opens each read-only and downloads it as JSON. Workspace owners also see the month batches with Download training export and Create back-test cases. An archived change now opens from its link like an archived incident, and the Data retention card links to the page.
• Back-test from the archive: a month's archived records become a golden dataset (from archive, with the batch id and manifest SHA-256 on every case) by the same rules as a back-test on live history — POST /{workspace}/archive/batches/{batch}/cases (members.manage and benchmark.manage). Nothing runs until you start a run, and a month with nothing gradeable creates no dataset.
• Back-test per agent: Back-test on history and Export golden set take an Agent (incident, change or compliance). Change cases come from completed changes a validation cleared and from changes rolled back or failed with a recorded reason; the plan must carry a rollback and, for a validated change, use the channel the fix ran through; a human correction wins. Compliance findings already arrive as compliance-agent incidents and are back-tested by the incident rules. Change-agent Test Lab runs now ask the agent for its planning wrap-up, so the one built-in change scenario may score differently than in 0.1.138.

0.1.138 — 19 October 2026

• Record archive instead of deletion: when the platform operator configures an archive bucket (AIOPS_ARCHIVE_BUCKET), closed records past a workspace's retention window are archived before they are removed: one compressed file per closed month of a workspace, with credentials masked, checked by SHA-256 after the upload, and only then removed in one step that writes a Records archived and removed (retention.archived) audit row. The bucket keeps each file for the operator's retention period (5 years by default) under S3 Object Lock and a customer-managed KMS key; the control plane reaches it only through its own Pod Identity role and refuses to run with any other credentials. A record that changed between archiving and removal is held for the next batch. Chat sessions and estate x-ray attachments are still removed, never archived. Without a bucket, retention removes records as before; if the archive was in use and the bucket setting goes away, retention pauses instead of deleting.
• Archived incidents stay readable: an archived incident's link opens Archived incident with View archived record (read-only, credentials masked as on a live record). GET /{workspace}/archive lists archived incidents and changes and GET /{workspace}/archive/{incident|change}/{id} returns one, with the live record's permission. A per-month fine-tuning export (members.manage) runs the full PII scrub first.
• Retention cards: the ops console's retention defaults and the workspace Data retention card show what happens after the window (archived then removed, or removed), the archive storage status, the last batch and any error. New metric aiops_archive_last_success_timestamp_seconds{tenant}.
• Infrastructure: a new archive Terragrunt unit (bucket, Object Lock, KMS key, policies) for the sandbox and the customer template, the control plane role's archive permissions, deployer policy additions and a customer destroy that keeps the bucket. The install guide covers turning it on.

0.1.137 — 19 October 2026

• Find anything with Ctrl+K: press Ctrl+K (⌘K on a Mac), or select Search in the top bar, to jump to a page, a settings section (aliases such as "retention", "kill switch" or "SSO" work), an incident, a change, a connection, a knowledge item or a section of the user guide. Before you type, it suggests what is waiting for you, such as items in Needs you or the next setup step. It only navigates — approving, running and deleting stay on their pages — and it lists only what your role can open. The getting-started guide has a Find anything: Ctrl+K section.
• Incident search by id: the incidents list search also matches the start of an incident id, so the 8-character id an incident page shows finds that incident.

0.1.136 — 19 October 2026

• Incidents on phones and tablets: below 1280 px the incident and compliance lists show one card per incident instead of a table that scrolls sideways: the select box sits beside the title, status, severity, alerts and opened time are labelled lines, and the resolved time is under More details. A Select all open shown button in the list toolbar selects the open incidents on the page at every width, next to the table's header box.
• Cards keep their state: a card's open More details stays open when the window widens to the table and narrows again.
• Audit log: the page opens on the search box, the group chips and the log. The per-action chips sit under a folded Specific actions line, listed group by group, which says how many actions are selected while it is closed. Filtering, the export and the chain check are unchanged.
• Keyless cloud access: changing the cloud provider keeps keyboard focus on the provider select while the setup form starts again for the new provider.

0.1.135 — 19 October 2026

• Tables fit the screen: Data sources, built-in detection rules, Changes, Test Lab runs, a rule's Resources and the risk register keep each row's identity, state and primary action in view on a laptop without sideways scrolling. Below laptop width (1280 px) each row becomes a card with the same data, order and actions, and a Sort by control replaces the column headers. A table that is still wider than its card becomes a named, keyboard-scrollable region with edge cues. A search that matches nothing says "No matches" and offers Clear search instead of describing the list as empty.
• Data sources and detection rules: row actions wrap, with Test and Edit first and Delete last (on a card the actions span the card). The harvest line sits under the connection's name. The Rules table shows Rule, Condition, Severity, Evaluation and On; the rule ID, resource type, source link, skipped reasons and counters stay inside the row.
• Resizing keeps your place: crossing the card/table width keeps keyboard focus on the same control, or on its row or sort control when that control exists in only one layout. An open dialog such as Edit or Reject, and any text typed in it, survives the resize; the layout switches when the dialog closes and focus returns to the control that opened it. A risk-register Approve or Reject still in flight stays pending across the switch and its result is reported.
• Incidents: selecting rows no longer moves the list. A refused bulk resolve or noise close stays in its dialog with the error, the selection and a retry; a confirmation dialog no longer closes on Escape or a backdrop click while its request runs.
• X-ray: every scan in the list has a real link, so it opens from the keyboard.
• Navigation and titles: on a phone the navigation opens as a dialog that takes focus, closes with Escape, the backdrop or Close, returns focus to its button and closes itself when the window widens. A Skip to main content link leads each page, and browser tabs name the page or record in the Portal and the Ops console.
• Settings: Guardrails, Agents and Tokens open with a section index whose links move focus to the section and keep the page's query (the keyless provider); long explanations fold into disclosures that a link opens. Create stays disabled for a blank API token name, and revoking an agent token asks for confirmation and shows a failure in the dialog.

0.1.134 — 17 October 2026

• Service aliases: map an alert-derived service name to its dependency-map name before grouping, while retaining service_original. The Intake rules page includes an editor and shows whether a candidate service meets the map. Aliases are workspace settings and survive later scans, harvests and trace syncs; scanner and ticket intake use the same final alias step.
• Maintenance windows per service: ordered service-glob rules use the workspace window as a fallback. The Maintenance windows card edits both, and incident/change pages show the window that applies. A one-time window can be requested and separately approved for one change and reviewed action; it expires, is invalidated by action/window changes, and is never a release vote. Emergency quorum, bypass audit and post-implementation review remain in force. Locked metadata updates preserve concurrent reclassification, and four-eyes checks include inherited lab-box approvers.
• Pre-approve a validated fix from the incident: an operator can request certification and an approver can certify the runbook and operation list. Only a successfully executed, cleared, single-operation API/CLI fix from the current occurrence is eligible; manual or multi-operation plans return 409 rather than producing a partial runbook. Deferred certification repeats the occurrence check, and concurrent requests cannot create duplicate route names.
• Operator release for eligible standard changes: a currently approved runbook-backed standard change at a one-approver L1/L2 tier can be released by an operator. Current route certification, revision, operation approval and workspace policy are rechecked and bound to the execution review. Normal, P1/critical, emergency and L3 controls are unchanged. No unattended standard execution or automatic package-patching lane is added.

0.1.133 — 17 October 2026

The documentation release. The guides were rebuilt so that a new team can onboard from the documentation alone, and so that an AI agent can read them without a browser session. One behaviour change ships with it: the switches the acceptance stories were demonstrated with are now the platform default.

• Seven workspace switches are now on by default (a workspace keeps its own setting; null means "follow the platform default"; every row on Guardrails says which applies): alerts that name no service are held in the triage queue until someone maps the source or clicks Analyse; a fix that fails its post-change validation reopens its incident one severity level higher; an emergency change's post-implementation review is scheduled when the request is submitted; when an incident is pinned to a suspected change that can be rolled back, rolling it back is the first recommendation; a fix whose every step a matching pre-approved runbook route declares is recorded as a standard change (P1 and critical fixes keep the emergency release rules); a cloud write made with one of the workspace's own credentials is flagged unauthorized when no platform change accounts for it within 10 minutes; an unmanaged cloud write re-checks every compliance control its resource kind maps to — a control re-checked only because the resource maps to it is skipped while it has a result under an hour old (controls a change rule names re-run every time; AIOPS_RECHECK_MAPPED_MIN_AGE_S, 0 = always), and ServiceNow, Jira and Azure DevOps tickets are analysed even when they name no service (the triage queue holds machine alerts only). The automatic cloud rollback after a failed validation stays a per-workspace opt-in. GET /guardrails returns switch_state with the effective value, the workspace override and the platform default for each switch; PATCH accepts true, false or null. For a whole installation, AIOPS_<KEY>=false restores the old default.
• Public documentation site at /help: every chapter of both guides is served as HTML and as Markdown (/help/<page>.md, or Accept: text/markdown on the HTML path), with /help/llms.txt as the index for AI agents (one fetch; each section has its own nested index and full-text file), /llms.txt and /robots.txt at the root, a sitemap and a 404 page. AIOPS_PUBLIC_DOCS=false keeps the site behind a login. The login page links to it. The site is built from the chapter sources in the image; nothing workspace-specific is ever on it, and the pipeline's leak scan runs over the published set.
• One tree, eight sections: Get started · Install and operate the platform · Connect your environment · Work with the agents · Administer a workspace · Reference · Troubleshooting · What's new. Big chapters became task pages (incidents into seven, knowledge and insights into nine, agents and guardrails into three, access and audit into four plus a permissions reference, integrations into five reference pages plus the change webhook, data sources into manage-connections, read-and-write roles and ticket systems); the old slug of each is a short hub, so old bookmarks and citations still land. Headings carry stable ids and a moved chapter redirects with its anchor.
• New pages: What the platform does; Choose your connection; Rehearse your first approved fix; Changes, Compliance, Webhook, Settings, Status-and-error and Approval-policy references; 36 integration pages (10 written for Prometheus, Loki, Grafana, Datadog, Dynatrace, ServiceNow, Jira, GitHub, kubectl and SSH; 26 generated from the connector catalog), each with the setup procedure; What's new; the Day-2 operations chapters (install, upgrade and verify, roll back, backup and restore, monitor the platform, security operations, platform incident response, patching, the recurring checklist, availability, audit retention, licence, expected cost, support) generated into the platform guide from their sources at build time; architecture and release notes by version in the workspace guide.
• Every page carries a type and an audience (how-to, concept, reference, troubleshooting, walkthrough, release notes; workspace or platform), shown under the title with the chapter's last change and the release it describes. Docs home shows three Quick start cards (first investigation, first alert, first approved fix). The glossary names the pillar of each term and links its owner page. The film pages are merged into Workspace tours and Platform tours.
• The same docs for people, chat and agents: the insights chat's documentation search covers both guides (platform pages only for owners and superadmins), splits long sections and no longer lets a transcript outrank the how-to it narrates; the MCP server's instructions and get_workspace_context point an agent at /help/llms.txt and the three Quick start pages; /openapi.json reports the running version, declares one security scheme per surface (bearerAuth for the workspace API, runnerToken for the private-agent endpoints, webhookToken for the webhooks, none for /healthz) with the token scopes, and tags every operation by domain.
• Corrections made with code evidence: no SSH or generic CLI command runs inside an agent run, whatever the credential allows; widening read_post_paths is ignored by agent runs; the RDS parameter-group before-value is derived from the ledger whether or not the rollback-first switch is on; the connector catalog steps describe the current page; the consent checkbox is named by its real label everywhere.
• Documentation gates in CI: every bold label in a how-to must exist in the product; pages over the size ceiling and how-to pages without the procedure skeleton are pinned and may only shrink; the leak scan covers both guides and the public site (DOCS_LEAK_PATTERNS pipeline secret); the /help build and its indexes are probed in the test stage; the image pipeline runs the leak scan too and rebuilds on every edit to the published repository chapters; a 12-digit account id other than the AWS documentation examples fails the scan on its own.
• Security Hub pulls can include Inspector findings (0.1.132, restated for operators who upgrade from 0.1.131): the AWS connection option Pull Inspector vulnerability findings (CVEs) adds a second read for ProductName = Inspector; off by default because every HIGH/CRITICAL CVE opens a P1/P2 incident and the P1/P2 auto-investigation switch starts a paid analysis.

0.1.132 — 17 October 2026

Bug fixes found by reading the documentation against the code: every place where a chapter described a product defect or a workaround was checked, and the defects were fixed instead. The guides gained the onboarding steps a new team was missing, current screenshots, and an index for AI agents. No new setting.

• Guardrails no longer removes the cost cap when you save another field: the Cost cap & PII patterns card pre-filled an inherited cap as 0, so saving a PII pattern or the SSRF switch wrote 0, which means no cap, over the platform's default. The field is now empty while the workspace follows the platform default (the placeholder shows the value in effect), it is sent only when you change it, an emptied field returns to the platform default, and 0 still means no cap. A 21st PII pattern is refused instead of being dropped silently.
• Copy that described the wrong behaviour: the cost-cap help says the run stops at the cap and skips the wrap-up; the egress floor and the extra approval gates say a caught call is refused during diagnosis on the default posture; the execution hint names the real checkbox, Allow use for approved plans; a harvest that found nothing says why; a stale approval gate says to stop the run before re-analysing; the ops console names the workspace's AI models page.
• Safer destructive actions: revoking an API token and deleting a chat conversation ask for confirmation; revoked and expired tokens are labelled.
• Inputs the server now checks: an invalid schedule cron is refused (422) instead of being saved and never firing; a connector type's key and name are validated; a built-in benchmark for a pillar with no scenarios is refused instead of starting an empty run; a golden-set or dataset upload names the rows it skipped.
• Screens that hid what was true: a connection whose connector type the platform disabled says so; the route editor offers the network mode; the notifications editor offers the golden and rollback events; Agent behaviour, the Test Lab and the x-ray launch dialog list gateway models only for pillars.manage and explain the manual entry otherwise; an incident lists all of its RCA exports, not only those among the workspace's 100 newest artifacts; expired support grants leave member lists and counts; the ops console shows why a webhook token was not minted and why no support grant was made; Save on a built-in connector type works (only a changed synced field is refused); the ops audit log shows each row's target and filters by action family on the server; the retry-exhausted job counter counts the jobs it was meant to count; aiopsctl approvals reads the pending approvals in one call.
• Model routing: clearing every tier of the platform default map now falls back to AIOPS_MODEL_TIERS_DEFAULT on the control plane, as api-mode runners already did; before, the control plane kept an empty map and the two routed differently.
• Security Hub pull reads Amazon Inspector vulnerability findings (CVEs) on request: the scheduled pull and Sync now asked Security Hub only for findings with a compliance status, and an Inspector finding has none, so no vulnerability ever arrived through the pull (the EventBridge push carried them). Set Pull Inspector vulnerability findings (CVEs) to true under Advanced connection settings on the AWS read connection (off by default): every sync then adds a bounded read of the Inspector product findings over the same window, sharing the 500-finding cap and deduped against the control findings; the Scanner sync card shows the count per region. Every HIGH or CRITICAL CVE arrives as a P1/P2 finding and, while Analyse P1/P2 findings automatically is on, starts one paid analysis per CVE. GuardDuty findings are not pulled.
• Found by the review of this release: GET /pending-approvals (read by aiopsctl approvals and the MCP tool) masks a credential inside a gated command the way the incident page does; an open investigation event stream ends when the viewer's access is revoked or a support grant expires, instead of delivering the run's events until it finishes; adding an account whose support grant has expired seats it for real (the add returned 201 and granted nothing); a well-formed schedule cron that never fires (0 0 31 2 *) is refused like an unreadable one.
• Documentation: who runs each installation step, adopting the workspace the install smoke test created, licence states as the platform computes them, the harvest as a required free step and the x-ray scan as optional, one region per guided AWS setup, the P1 → emergency → two-approver chain and the ways around it, a rehearsal of one approved fix, ticket route bodies per system, compliance first steps, an expected monthly infrastructure cost at AWS list price, the starter CloudFormation alarms sending severity=warning, docs/llms.txt and an onboarding skill for AI agents, and the guide screenshots captured again on this release, except the application-approval picture in the Azure guide, which is still the 16 September capture.

Upgrade notes

• No schema change.
• A pillar whose saved schedule cron is invalid cannot be saved on Agent behaviour until the cron is corrected (the scheduler never ran it).
• An install whose platform tier map was cleared to empty now routes on AIOPS_MODEL_TIERS_DEFAULT when that variable is set.
• API callers: PATCH /guardrails with more than 20 PII patterns answers 400 instead of keeping the first 20; a new connector type's key must match ^[a-z0-9][a-z0-9_-]{0,63}$ and its name must not be empty (422); a pillar schedule_cron that is not a valid cron expression answers 422.

0.1.131 — 16 October 2026

Bug fixes found by a live test of 0.1.130, plus the recorded walkthrough films in the documentation. No new setting.

• A ticket that arrived without a link is written back (ServiceNow, Jira): an inbound ticket whose rule posted no url adopted its incident but the analysis never reached it: the row said no enabled ticket route writes back to this ticket while one was enabled, and offered no Retry. The platform now writes through the workspace's only enabled connection of that system; with two connections, or a link on another host, the row names the real reason and offers Retry. A route of another ticket system is never the reason. Send test ticket on a disabled route answers 409 instead of filing. A ServiceNow route saved before 0.1.130 closes a merged incident with Duplicate when the instance has that code.
• Changes → statistics count the whole window: the totals and per-actor rows were computed over the newest 2,000 records, so a busy account's "last 30 days" covered its newest two and reported 0 unauthorized while denied attempts sat older in the window. They are now aggregated in the database over the whole window.
• EKS Auto Mode housekeeping is not a change: a service's own reconcile loop signed as an assumed role (invokedBy = eks.amazonaws.com: PutRule, PutTargets, CreateLaunchTemplate, DeleteLaunchTemplate) is dropped like the 0.1.130 noise and counted under dropped; CreateFleet and RunInstances stay. The datasources a pull truncated are shown on the harvest report. An AWS Config before-state records configurationStateId as its version.
• The Estate map shows stale nodes again (grey): since 0.1.111 the map silently dropped every stale or inconsistent node (268 of 2,104 on one estate) although the legend says they stay visible; blast radius still reasons over the trusted cut only. A scan's Estate card, counts and Turtle download keep the estate the scan produced after the next harvest of the same connection (the counts are frozen when the scan finishes; a Turtle download reads the harvest artifacts). An outside authorize on a group the harvest already read adopts the harvested rule instead of minting a second. AWS error text in harvest notes is cut at a word boundary, so the denied action stays readable.
• Documentation: the recorded walkthrough films (15 portal, 11 ops) are embedded in the documentation with their transcripts, each captioned with the build it was recorded on; italics and level-4 headings render; one clear button on the docs search; the seven set-up guides are self-contained and no longer stamped with a version; three ops chapters added (licence, default email relay, built-in detection freeze, regulated workspace, first-customer prerequisites); the flagged-resources card names the real not-applicable path.

Upgrade notes

• One additive column (xray_scan.estate_counts); automigrate adds it.
• The image is about 390 MB larger because of the embedded films.
• Outside AWS writes harvested before 0.1.130 keep the before-state note they were stored with and are not re-read.
• Upgrade the control plane and private-network agents together.

0.1.130 — 15 October 2026

• AWS Config before-states for outside changes (no switch): up to 0.1.129 every AWS write harvested from CloudTrail was listed with AWS Config holds no configuration item for this resource around this write, even with config_history: true and the recorder on: the platform could not read the capture times Config's API returns (numbers, not text), so no outside AWS change ever had a before-state, a diff or Draft revert. It now reads them. It asks for the state after the write first; when that is Config discovering the resource (a create), nothing older exists and one read is enough. Otherwise it reads back up to four times (one Config read spans 7 days, so 28 days); a resource Config last captured longer before the write says AWS Config holds no configuration item in the 28 days before this write. Every read still counts against the 50 Config reads per connection per pull. A Lambda function's attachments are read back the same way.
• EKS Auto Mode nodes in the estate map (no switch): EC2's managed resource visibility can hide EKS Auto Mode instances and their network interfaces from plain DescribeInstances / DescribeNetworkInterfaces. The estate harvest, the touched-scope read of a security-group change and the probable-cause attachment read now ask for them (IncludeManagedResources), and retry once without it where a region rejects the parameter. The backup check still counts plain instances only. After the first harvest on 0.1.130 these nodes appear typed, with their subnet and security-group relations. A change request reviewed before that harvest whose removed relations change needs a fresh review.
• Security-group rules in the map follow a complete read (no switch): an authorize event from CloudTrail wrote the real rule plus one empty placeholder rule for each empty list in the event, and no harvest removed them, so the map could keep a rule (for example RDP open to 0.0.0.0/0) after it was revoked. One authorize now writes one rule. A complete, uncapped read of a group makes its rule edges exactly what AWS returned: placeholder rule nodes no harvest owns are removed, and a harvested rule no longer returned keeps its stale flag. A short, refused or failed read changes nothing, and neither does a read that overlaps a change applied to the map while it ran.
• Fewer change-driven re-reads (no switch): SSM agent heartbeats and reports (UpdateInstanceInformation, UpdateInstanceAssociationStatus, PutInventory, PutComplianceItems) and AWS Config rule verdicts (PutEvaluations) are no longer recorded as estate changes; SendCommand, StartSession and PutParameter still are. Each kept write marked a node stale and queued a full re-read of its connection, so busy accounts were re-read dozens of times a day. The 500-event limit per connection per pull now counts kept events, read from at most 1,500 rows; reaching that ceiling marks the pull truncated.
• The daily harvest runs daily (no switch): the due check looked for the last scheduled harvest among the newest 50 harvest records of any kind, so a workspace with many change-driven re-reads ran the scheduled harvest on every tick. It now finds the last scheduled one directly.
• ServiceNow and Jira tickets (no switch):
  • Check reads ServiceNow's resolution codes from the incident form when sys_choice is refused, as it is for an itil user on Zurich, so the Duplicate code is found for merged incidents.
  • Send test ticket gives the create 20 seconds and, when ServiceNow's answer is lost, searches for the test ticket's mark and closes what landed. A test ticket still not found is named so a person can close it.
  • An escalated incident whose own adopted ticket is resolved or closed in ServiceNow or Jira resolves when nothing else is firing, noted auto-resolved: its ticket … was resolved in …. With Keep an incident open while its fix waits for a decision on and a fix waiting, it stays escalated and its timeline says the close was held.
  • The note written to a customer's own ticket reads AIOps analysis — incident resolved in AIOps at … instead of Resolved by AIOps.
  • Close notes no longer end the root cause with a double period.
  • A ticket reopened soon after the platform's note is a new signal, not an echo of that note.
  • Ticket systems has a copy-paste asynchronous ServiceNow Business Rule for tickets as signals.
• Docs: seven set-up guides in the portal docs (change windows and rollback, security posture, alert sources and intake rules, compliance, AI models and prices, notifications and tickets, write connections), a "How far to trust the map" section in the knowledge chapter, and corrected statements across the portal and repository docs.

Upgrade notes

• No schema change, no new setting and no new permission: the EC2 and AWS Config reads use the actions the bundled roles already grant.
• The first harvest after the upgrade can list EKS Auto Mode nodes as added and report a security group's relations as changed once.
• Outside AWS writes harvested before the upgrade keep the before-state note they were stored with (AWS Config holds no configuration item for this resource around this write) and are not re-read; such a write has no Draft revert and is reverted where it was made.
• Upgrade the control plane and private-network agents together.

0.1.129 — 15 October 2026

• Every row of an incident's lifecycle carries its correlation id (no switch beyond the existing one): with Audit correlation on, five kinds of audit row named the incident only as their target and kept no correlation_id, so /audit?correlation=<incident> and the incident's correlated view left them out: the last-known-good anchor read at incident open (lkg.anchor), an alert the analysis suppressed as cascading (alert.suppressed), a problem opened by recurrence (problem.opened), a root-cause report routed to a ticket (rca.routed) and a pre-approved route that matched but did not run (route.match_skipped). They are now stamped at insert like the rest of the lifecycle. Rows written before the upgrade keep their payloads: the audit trail is append-only.

Upgrade notes

• No schema change and no new setting. The process that writes a row stamps it: upgrade the control plane, and private-network agents that run in database mode.

0.1.128 — 14 October 2026

• Client tokens are masked again (no switch, security): 0.1.127 read the name ClientToken as EC2's harmless idempotency token, but HashiCorp Vault and Akamai use client_token for a credential. In 0.1.127 such a value (CLIENT_TOKEN=…, client_token: …, auth.client_token) could appear in clear in tool output, analysis transcripts and previews. 0.1.128 masks it again, as 0.1.126 did. Do not install 0.1.127.
• A value that starts like a mask stays masked (no switch, security): 0.1.127 stopped masking, in previews and plans, any value that began like an existing mask, so a credential stored next to an earlier mask (for example an email pseudonym followed by a password or an API token) could show in clear. Only a whole mask, or the exact piece of one a value pattern cuts off, is left alone now.
• Header and key credentials written with a space are masked again (no switch, security): 0.1.127's fix for hyphenated words also stopped masking the value after an HTTP header or a hyphenated key written with a space, as in nginx proxy_set_header X-Api-Key …, X-Authorization "Bearer …", PRIVATE-TOKEN …, haproxy set-header X-Vault-Token … or db-password …. Header names are read as options again, exactly as in 0.1.126. For a hyphenated word that is not a header name, the next word is masked when it looks like a credential (it has a digit, an auth scheme, or 16 characters or more), so prose such as no-token calls or http-tokens optional and names such as external-secrets stay readable.
• Azure storage keys are masked by name (no switch, security): AccountKey, SharedAccessKey and SharedAccessSignature — for example in a storage connection string a tool reads — are now masked even though their names carry no secret word, also when they are one part of a dotted name.
• A CloudWatch validation window sees its last period (no switch): a post-change validation rule on a CloudWatch metric asked for the window's exact end, and CloudWatch never returns the period that end cuts, while the check expects a reading in every period the window touches. So every CloudWatch window ended as uncertain — a fix that kept the metric above its threshold was not failed or rolled back, and the free check then cleared it. The platform now asks for whole periods and reads the window once its last period has closed and can have been published (up to one period plus three minutes after the window ends). A CloudWatch window shorter than two periods never fails a fix, because its periods would mostly hold readings from outside it. Prometheus rules are unchanged.
• "platform verdict", not "platform check": the change page's label for a verdict reached without an agent run (0.1.127) now reads platform verdict, so it is not confused with the posture Platform checks (EST-01 to EST-06).

Upgrade notes

• No schema change and no new setting. Replace any 0.1.127 install with 0.1.128; private-network agents need it too, since they mask on their own.
• The doubled mask 0.1.127 set out to fix ([credential hidden] hidden] on a re-shown signed link) can still appear in a few places; it is cosmetic and hides nothing.

Next steps

• Next: Release notes 0.1.120 to 0.1.127
• All What's new pages
• Documentation home