Release notes 0.1.120 to 0.1.127

Archived release notes, newest first: 0.1.127 (14 October 2026) back to 0.1.120 (13 October 2026).

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

0.1.127 — 14 October 2026

• A runbook named by the analysis keeps its before-state (no switch): when an analysis that plans typed steps chose a runbook route instead of writing steps, the platform read the plan as private every time. The automatic API fix then stopped with Execution stopped: its before-state could not be captured, and a GitOps runbook's pull request showed Pre-change state withheld with a manual rollback instead of a restore pull request, so the platform could not restore a failed fix by itself. The plan's own fields now decide, and the before-state, the restore and the post-change check are kept.
• A private plan withholds only repository files (no switch): when a plan really carries private values, the platform still withholds a file's pre-change copy from a pull request, because the file can repeat a rotated secret. A cloud provider's read of the target is now kept as its before-state with its own masking; before, one masked word anywhere in the plan removed it, together with Roll back and the free compiled check.
• Fewer false credential masks (no switch): a hyphenated word is no longer read as a command-line option, so a resource named, for example, external-secrets or app-secrets-vm, or a sentence such as no-token calls, no longer hides the word after it or refuses the fix as private credential material; real options such as --password stay masked. A dotted name is judged without its known parts, so MetadataNoTokenRejected.Sum stays readable while db.password stays masked. The IMDS enforcement flag, the metadata token TTL header, EC2's ClientToken, the IAM password-policy API names, PaginationToken and Azure's SAS expiration policy are read as the settings they are. A text that already carries a mask no longer grows it ([credential hidden] hidden]) each time it is shown.
• The change page says who checked the fix: a verdict the platform reached without an agent run (the compiled check of a typed fix, and the other free validation steps) is labelled platform check instead of agent verified.

Upgrade notes

• No schema change and no new setting. Private-network agents need this release so that their own masking follows the new rules. Changes recorded before the upgrade keep the text and the before-state they were stored with.

0.1.126 — 14 October 2026

• An EC2.8 fix verified on the IMDS metrics is no longer refused (no switch): the platform read the EC2 CloudWatch metric names MetadataNoToken and MetadataNoTokenRejected as credential fields because they contain the word token. A plan whose verification said, for example, MetadataNoToken=0 and MetadataNoTokenRejected=0 had those counts masked, so its execution review said The proposed execution contains private credential material. Generate a clean plan. and the fix could not be approved. Both names are now read as the counts they are, in plans, previews, analysis transcripts and audit text, the same way HttpTokens has been since 0.1.121. Any other key containing token is still masked.

Upgrade notes

• No schema change and no new setting. Private-network agents need this release so that their own scrubbing keeps the counts.

0.1.125 — 14 October 2026

• A route is pre-approved only when an approver certifies it (no switch): pre-approving a remediation route — the Pre-approved (L1 auto-fix) box, preapproved on POST or PATCH /routes, MCP create_route and patch_route — now needs approvals.decide (builtin approver, executive, owner). From anyone else, the builtin operator included, the tick records a certification request that an approver decides on Needs you (chip Certify); the save says Saved. Certification requested — an approver decides on Needs you. and the route keeps waiting for a person. The approver certifies one exact revision of the route — a fingerprint of its name, selector, mode, connection, parameters, tier and lifecycle flags — from the new Certify route '…' dialog, which shows the call they sign, the runs of that revision and who last changed it, and asks why it is safe (POST /routes/{id}/certification, MCP certify_route). Nobody who changed the route since it was last certified may certify it while another approver exists, so a colleague renaming it and back does not hand the authorship over; a workspace's only approver may certify their own revision, and the route says self-certified — no other approver. An approver's own Pre-approved tick asks why and certifies only the revision the dialog shows. A route whose parameters repeat a credential field's value under another key — which would hide that value from its reviewers — is refused when saved. When a certifier can no longer approve, another approver confirms or withdraws the route. Before, anyone who could edit routes could pre-approve one.

• A change to what a route does drops its pre-approval (no switch): changing a pre-approved route's name, selector, mode, connection, parameters, tier or lifecycle flags — in the portal, through the API or MCP — takes the pre-approval away at once: the route reads Pre-approval dropped on <date>: <who> changed <fields>, the audit log records Route pre-approval dropped by a change, and approvers are asked to certify the new revision. Turning a route on or off, or changing its priority, keeps it. A route changed outside the route form stops counting as pre-approved at its next automatic run. Before, a pre-approval survived every edit.

• Route changes are audited with their values (no switch): route.create, route.update and route.delete now carry the route's revision and its values before and after — credentials masked, long values shortened, each with a sha256 fingerprint — and every changed value inside the parameters by its path (params.snapshot.region "ap-southeast-1" → "us-east-1"), not only the field names. Certifying, requesting, dropping and withdrawing have their own rows: Route certified, Route certification requested, Route pre-approval dropped by a change and Route certification withdrawn.

• The incident says why a pre-approved route did not run (no switch): when a pre-approved route matched an escalated incident and did not run, its Timeline shows Pre-approved route matched — not run with the route and the reason — automatic fixes off, the analysis proposed typed steps, the route changed after it was certified, tier L3, an API route while automatic API fixes are off, and the others the setup guide lists — once per reason. Route editors (datasources.manage) see the ones a route edit or a setting would fix on Needs you → Not run and under the route on the routes page, with Acknowledge. When nothing pre-approved matched, nothing is written. A release refused before any change record was written no longer uses up the incident's one automatic try, and a route whose mode never runs on its own no longer records Automatic fix blocked.

• Every route run names the revision it ran (no switch): the change record of a route run, from an incident or from a change request, carries the route's revision, who certified it and how it was released — Route '…' revision … · certified by … · released automatically (pull request), released by … or certifier unknown — and GET /changes/{id} returns route_certifier. Runs record this from this release on; an automatic API fix (below) reads these records as its precedent.

• An analysis's file change never reaches an API call (no switch): a file change the analysis proposed was merged into the call of any route: a generic HTTP API route took the proposed file's path as its own, and an AWS route could pick up a path it never declared. It now reaches a pull request only; API, command-line, MCP and network-device routes run their own configured call.

• Ticket routes are bookkeeping only (no switch): a route that runs when an incident opens or resolves (Run when the incident opens, Run when the incident resolves) now runs only in api mode and only against a ticket, paging or webhook connection: Jira, ServiceNow, Azure DevOps, PagerDuty, Opsgenie or a generic HTTP API. A hand-written one — any such route that is not a ticket system preset — never uses a write connection (Approved changes only or Investigate and approved changes) and sends nothing until an approver certifies its revision; an operator's new or changed one is a certification request. The rules are checked when the route is saved, which is refused with the reason, and again before every request; while one stops a route, the incident's ticket line says why (ticket route …: Not certified: …) and the next ticket route that covers the incident is tried. Before, anyone who could edit routes could make such a route call any connection — a cloud account, a cluster — on every new incident with no click. Ticket system presets (Tickets on the connection) are unchanged. See the upgrade notes for routes that stop sending.

• Automatic API fixes for proven runbooks (switch, off by default): a runbook route that calls a cloud API (mode api, named remediate-…, with a selector) and that a named approver certified may now make its own call with no per-incident click — only when it repeats a fix the platform already verified for the same alert on the same service. Both Allow pre-approved routes to auto-fire and the new Allow certified API runbooks with a verified precedent to run on their own (Guardrails & cost → Automatic API fixes for proven runbooks, aiops_auto_remediation_direct) must be on. The precedent is the previous occurrence of the same alert: fixed by this route at this exact revision, verified by the platform (never a verdict a person recorded by hand), every alert of it cleared at its source after the fix, its last-known-good record held, less than 30 days old, and with the same call through the same write connection. The call must be exactly what the route's one declared operation does on one target, with fixed values; its operations must all be on Pre-approved operations (never an undo), with a snapshot read and a rollback declared; its selector must match the alert that opened the incident, and no other certified API runbook may match. A P1 or critical incident, an analysis that asked for a person, a reopen — the alert back inside the reopen window, or a check that found the condition still present after a close or after a fix — a run of the route already on the same incident (a person's release that failed is never retried on its own), a time outside the route's or the workspace's change window or inside a freeze, a migrated or lapsed certification, and an automatic run of the route still in flight or failed since the route's newest platform-verified run each leave the fix to a person — on top of every rule of automatic fixes: tier L2 or below, not flapping or unmapped, never a compliance control or scanner finding, within the cost limits, once per incident. Each run takes the path of a person's release: a change record before the write, the before-state read first (a run whose snapshot cannot be read writes nothing), the declared rollback prepared, and verification at once; the master switch, the new switch, Pause all agents and the cost limits are read again right before the write, and a release they stop there writes nothing and leaves the same action releasable, by a person or the next automatic try. The change record is a standard change — Standard — certified runbook, released automatically — whose reason names the runbook revision, its certifier and the verified change it repeats, and it cannot be reclassified; the Timeline reads Fix applied automatically (pre-approved) · <route> · API call · repeating CHG-…. A released rollback of an automatic API run takes the route's certification away whatever Demote a pre-approved route after one rollback says, and one failed automatic run — or one still waiting for its verdict, such as a run whose incident was closed with verification muted — stops the route until a person's release of it succeeds and is verified. With both switches on, CHG-01's evidence adds that certified runbooks may repeat a verified fix without a per-run approval, with the number of certified API runbooks and of automatic API runs in 30 days. The Pre-approved auto-fix (L1) card reads as before while the new switch is off. Off, API routes wait for a person, and the Timeline says so.

• Validation checks (L6) — code answers first, the agent last (three switches, two on by default): a check after a close or a fix used to be a full read-only agent run every time — after every close, beside every reopen or Analyse, and after every fix until it had a verdict. The new Validation checks (L6) card on Guardrails & cost (members.manage) holds three switches; each follows the platform default until the workspace sets its own, and Verify (or Recheck) always runs the agent:

  • Check a typed cloud fix with its own read first (on, aiops_verify_typed_check): after a security-group rule revoke, NSG rule delete, S3 Block Public Access, IAM password policy, blob public access or IMDSv2 fix, the platform reads the resource again — the read the plan compiled at review, on the fix's own connection — 30 seconds after the write; a Post-change validation rule (Change safety) that matches the fix decides first, through its window. The opened port or setting gone on every target, with no alert or finding about anything else, verifies the fix at no agent cost: the incident resolves, the change completes and its scanner findings are marked verified on the resource. The exposure back fails it: the incident is escalated and the change failed. Anything less clear goes to the agent as before — an incomplete listing, a failed read, a connection edited since the fix, another world-open rule that overlaps the removed one without covering it (a web server's own 443 beside a removed all-traffic rule), or, after an account-wide setting, an alert or finding about a control that setting does not close. The same check runs on a closed incident whose newest change is such a fix, and on a change with no incident; the review card of such a plan says the platform runs the reads itself, unless a validation rule matches it.
  • Skip agent checks that cannot learn anything new (on, aiops_verify_frugal): no paid check while the incident's own analysis is running or started less than one recheck interval ago (an analysis waiting on an approval holds it for that first interval only); one $0 Uncertain row cannot verify: no read connection reaches AWS account … when no connection could observe any alert of the incident — a Dynatrace, Datadog, Prometheus or kubectl connection counts as one, as do an AWS connection that names no account or that account, and any Azure connection; and no paid repeat of an Uncertain answer until something changes — an alert fires, clears or arrives, a fix runs or merges, a read connection is added, edited or deleted, a new analysis starts, the incident changes status: none after a close, while an open incident backs off 30 minutes, then 1, 2 and 4 hours. Checks after a fix are never held. A skipped check is a $0 Not verified row that says why.
  • Treat an alarm still firing at its source as still present (off, aiops_verify_alert_rung): a CloudWatch alarm that reports its own recovery (OK actions set, no insufficient-data actions, missing data treated as missing or notBreaching) and still reads ALARM through a read connection to its account, at least 30 minutes after the close, fix or merge, answers Still present with no agent run — which reopens a close or fails a fix. Off by default because it changes results.

  Replayed on the 57 paid checks the demo platform recorded from 1 to 13 October ($17.39), the defaults skip or answer 35 of them, 56% of the cost, with no verdict changed.

• Costliest incidents — one row per occurrence (no switch): an incident whose alert comes back inside the reopen window keeps its id, so Usage & billing → Costliest incidents summed every episode on one row and hid the one that cost the money. It now ranks occurrences: an occurrence starts when the incident opens, when its alert fires again, or when an accepted risk lapses; a reopen by validation (still present after a close or a fix) continues the occurrence it found. A row whose incident came back reads occurrence 3 of 3 · incident $9.33 over 3 occurrences · avg $3.11, and every row splits the money: triage $0.51 × 1 automatic + $2.93 × 2 re-run · validation $3.98 × 7 AI + 0 free checks, where a re-run is one a person started. Under the ten, Recurring: names an incident none of whose occurrences made the list though its month beats the tenth row, and Validation not tied to an incident gives the validation of changes verified on their own. A validation that never ran — a skip, a refusal before the run started, a claim still in flight — makes no row. The service delivery report's cost appendix lists the same rows, Operate → Problems shows each class's AI spend over every occurrence under its incident count, and an incident's Spend card and validation line read the same split — AI runs at what they cost, failed runs, free checks apart — with one line per occurrence when its alert came back.

• Validation billed at what its run cost (no switch): a validation's cost is now read from the run it names. A run that failed after spending, and one whose verdict landed on an incident escalated meanwhile (its row kept $0), were left out of the incident figures: on the demo's primary workspace the October validation spend in the incident view goes from $14.50 to $14.94, the figure the statement's Validation class always billed. A verdict that lands on an escalated incident now keeps its run, model and cost on the row, a validation belongs to the month its run started, and an incident's AI budget (Incident cost limit) reads the same figure.

• Free checks are not runs (no switch): a validation that ran no agent — a check code answered at $0 — counted as a run of the Validation class, so a month could read "$0.00 × 929". The class now counts agent runs in runs and the free checks in a new free_checks field; Agent runs and the Validation row change accordingly, the row showing the free checks beside its runs. A month sealed before this release keeps its sealed figures.

• Guides: two new chapters, Runbooks and automatic fixes — set it up like the demo (/portal/docs/runbooks-and-automatic-fixes) and Automatic API fixes for proven runbooks (/portal/docs/automatic-api-fixes), linked from Guardrails, the routes page, the connection dialog and the related chapters. The Guardrails chapter explains Validation checks (L6), the incidents chapter what is answered before any agent run, and the Usage & billing section the occurrence rows and free checks. The sentences that said no write reaches your estate without a named person now name the one exception above.

Upgrade notes

• Ticket routes that stop sending: after the upgrade, an existing route that runs when an incident opens or resolves sends nothing when it is not in api mode or its connection is not a ticket, paging or webhook system, and a hand-written one also when its connection is a write connection (Approved changes only or Investigate and approved changes). The incident's ticket line says why and the next ticket route that covers the incident is tried. Move such a route to the ticket system's preset (Tickets on the connection) or to a read connection. A hand-written ticket route that passes these rules keeps sending as certifier unknown until an approver confirms or withdraws it; a later change to it stops it until an approver certifies the new revision.
• Pre-approved routes are migrated as "certifier unknown": at the first start, every route pre-approved before this release becomes certified, certifier unknown at its current revision, and each route's last editor is read from its audit trail; no audit rows are written. Such a route keeps everything it did before — the automatic pull request, the standard-change class, demotion — but never makes an automatic API call. Approvers (owner, approver, executive) find each enabled one, and each enabled hand-written ticket route, on Needs you → Certify, where they confirm it (which names them as its certifier) or withdraw it, so the Needs you count grows by that number. The approver who last changed a route — its audit trail says who — cannot confirm it while the workspace has another approver (409 another approver must certify it): that other approver confirms it, and until then the route keeps working as before. A later edit drops its pre-approval like any other.
• Who may pre-approve has changed: the builtin operator, and any role without approvals.decide, now records a request when it ticks Pre-approved, creates a route with preapproved: true or saves a hand-written ticket route. Automation that pre-approved routes through the API needs an approver who did not change the route: GET /routes for its revision, then POST /routes/{route_id}/certification with {"action": "certify", "revision": "…", "note": "…"}. An approver's PATCH /routes/{route_id} with preapproved: true on an unchanged revision certifies only with revision and certification_note (409 when the route changed since), else it records a request. A save that changes a revision field drops the certification; enabled and priority keep it. The same holds for ticking Pre-approved again on a route a rollback demoted: it reads Demoted after rollback <date> — automatic runs stay off until an approver certifies it again, and Needs you → Demoted says the same, until an approver who did not change it certifies it.
• Validation defaults change at the upgrade: Check a typed cloud fix with its own read first and Skip agent checks that cannot learn anything new are on by default, so from the first start fewer paid checks run: a typed fix can be verified, and its incident resolved, without an agent run; a check beside the incident's own analysis waits one interval; a target no connection can reach gets one $0 cannot verify row; and an unchanged Uncertain is not paid for again. An incident's validation history shows each of these as a $0 row that says why. Treat an alarm still firing at its source as still present stays off. To keep 0.1.122's checks in a workspace, set verify_typed_check and verify_frugal to false on the card or with PATCH /api/aiops/{tid}/guardrails; null follows the platform default again. Staff set the platform defaults with AIOPS_VERIFY_TYPED_CHECK (on), AIOPS_VERIFY_FRUGAL (on) and AIOPS_VERIFY_ALERT_RUNG (off).
• Automatic API fixes stay off until an owner turns them on: a workspace owner (members.manage) ticks Allow certified API runbooks with a verified precedent to run on their own, or sends PATCH /api/aiops/{tid}/guardrails with auto_remediation_direct: true, beside auto_remediation: true; null follows the platform default (AIOPS_AUTO_REMEDIATION_DIRECT, off), and computer-assist mode refuses it (409). Nothing runs on its own on the first occurrence of an alert, and no migrated route ever does: a named approver certifies the runbook, a person releases the first fix, and only its verified repeat runs on its own. Automatic API fixes for proven runbooks walks through the alarm and the route: a CloudWatch alarm arrives critical unless its description declares severity=…, and needs its OK action on the intake topic too.
• Usage & billing reads differently from the first start, the money does not: the current month is not sealed, so it is read under the new rules at once. Agent runs and the Validation row stop counting checks that ran no agent — on the demo's primary workspace, October's Agent runs fall from about 40,000 to under 200 and its Validation row reads 45 runs beside about 40,000 free checks — with every dollar unchanged. Costliest incidents ranks occurrences, so a recurring incident's row shows its costliest occurrence rather than its sum (on the same workspace the top row goes from $9.33 to $7.42) and an incident none of whose occurrences makes the ten moves to the Recurring line. An incident's Spend card and validation line show the same split, so their counts differ from earlier screenshots. Nothing is lost: a month sealed before this release keeps its sealed figures.
• Billing figures change shape: the incidents rows of GET /api/aiops/{tid}/spend and GET /api/aiops/{tid}/billing are occurrences, so one incident can appear more than once; validation_runs counts agent runs with a verdict, and the Validation class's runs no longer include free checks. An incident with an Incident cost limit may reach it slightly earlier: the limit now counts validation runs that failed after spending and verdicts that landed on an escalated incident — money it really spent. Both CSV exports — the workspace statement, and the organization and platform exports — end with a new free_checks column, so every earlier column keeps its place. For a month sealed before this release, free_checks is empty (unknown) and runs still includes the free checks; in the organization and platform CSV, the TOTAL line's estimated_usd, unpriced_tokens and free_checks are empty when any workspace's month was sealed before that figure was recorded.
• Private-network agents: nothing to update for these changes — certification, the not-run rows, the ticket-route rules, automatic API fixes, validation checks and billing run on the control plane. An agent older than 0.1.122 now gets that release's runbook fix too: with Let the analysis pick a matching route instead of typed steps on, a runbook its analysis names inside the plan binds when the agent posts its result.
• API clients: GET /routes rows add revision, certification (status certified, requested, dropped, withdrawn or demoted; by, by_label, at, source, note, self_certified, current, lapsed), last_edit, runs and, for an approver, certify_check; POST and PATCH /routes take certification_note, PATCH also revision and skips_acknowledged: true, and both answer with a notice when a pre-approval became a request or was dropped. New: POST /api/aiops/{tid}/routes/{route_id}/certification (approvals.decide; MCP certify_route). Needs you adds the types route_certification and route_skipped. GET /changes/{id} adds route_certifier; POST /changes/{id}/class refuses a record whose change_class_source is runbook_route_auto (409). GET /guardrails adds auto_remediation_direct and verification (per switch verify_typed_check, verify_frugal, verify_alert_rung: effective, override, default), and PATCH /guardrails takes all four as true, false or null; PATCH /api/aiops/{tid} takes only JSON true, false or null for aiops_auto_remediation_direct, aiops_verify_typed_check, aiops_verify_frugal and aiops_verify_alert_rung (400 otherwise). A plan review's summary adds auto_verified when the platform reads every step after the fix. The billing incidents rows add occurrence, occurrences, occurrence_started_at, window_occurrences, incident_total_usd, avg_per_occurrence_usd, triage_auto_*, triage_human_*, validation_ai_*, validation_failed_* and validation_free_checks; both answers add recurring_incidents, the statement adds validation_outside_incidents (null on a lab box) and its classes free_checks. GET /problems and GET /problems/{id} add spend (total_usd, triage_usd, validation_usd, incidents, occurrences) and GET /incidents/{id} adds spend (total, occurrences). New audit actions: route.certified, route.certification_requested, route.certification_dropped, route.certification_withdrawn, route.match_skipped and route.skips_acknowledged; incident.auto_remediate adds route_id, revision, release, certified_by and precedent_change_id, and incident.auto_remediate_blocked adds route_id.
• Schema: additive — columns remediationroute.certification and remediationroute.last_edit, filled once at the first start as above, and incidentrecheck.evidence, empty on older rows (which never count as a repeat). A rollback to 0.1.122 leaves them in place, unread — and lets any route editor pre-approve again.

0.1.124 — 14 October 2026

• The analysis no longer repeats a typed step as a command for a person (no switch): when an analysis proposed a typed fix, it often wrote the same change again under the human-run commands, sometimes with an extra option. The extra line added nothing a person needed — the platform already shows each typed step's own command — and it took a runbook's fix out of the runbook's scope, so its change request was recorded as an emergency instead of Standard — runbook route. The analysis is now told to keep human-run commands for a change no supported typed operation covers.

Upgrade notes

• No schema change and no new setting. Private-network agents need this release for their analyses to follow the new instruction.

0.1.123 — 14 October 2026

• A human-run copy of a typed step no longer loses the runbook's standard class (switch: Standard change for a runbook route's operations): a plan that carried its typed step and also wrote the same change out as a command for a person was taken out of the runbook's scope, so its change request was recorded as an emergency instead of Standard — runbook route. A human-run line that is exactly the command form of one of the plan's typed steps (same tool, action and values; the order of its options and print-only options such as --no-cli-pager aside) now counts as the same change. Any other human-run line, an extra option on that command included, still keeps the plan out of the runbook's scope.

Upgrade notes

• No schema change and no new setting.

0.1.122 — 14 October 2026

• A runbook named inside the plan now binds (switch, off by default): with Let the analysis pick a matching route instead of typed steps on, an analysis that named the offered runbook route inside its remediation plan, rather than in the field the platform reads, left the route unbound: the incident waited for a person with no route attached, and an automatic fix could not fire. A model gateway that does not enforce the answer's schema lets this happen. When the route choice was offered and the top-level field is empty, the route the plan names is now taken, before the rule that keeps a rewritten answer to the route its first complete answer named. With the switch off nothing changes.

Upgrade notes

• No schema change and no new setting. Private-network agents need this release for the fix to apply to their runs.

0.1.121 — 14 October 2026

• A runbook route that makes its own edit is offered with that edit (switch, off by default): with Let the analysis pick a matching route instead of typed steps on (Guardrails & cost → Pre-approved auto-fix (L1), aiops_runbook_routes_with_typed_plans), each matching pull-request route the analysis is shown now also lists the branch it targets (base_branch) and, when the route makes its own edit, that edit: the exact text it replaces and the text it writes, or the line count and opening lines of a whole file it writes — masked like the rest of the action, never a connection's configuration or credentials. When one route matches and it makes its own edit, the analysis is told that the route's pull request applies exactly that edit (refused unless the text it replaces is in the file exactly once), that it does not need to read or copy the file to choose it, and that it must not propose a file change of its own for that route; it names the route when that edit is the fix the evidence supports. Before, the analysis was asked to copy the file's text word for word, looked for the file on the repository's default branch instead of the route's branch, and declined the route when it could not read the file. A route that makes no edit of its own keeps the word-for-word instruction, with its branch now listed. A route that carries both a whole file and an edit is described as the whole file, which is what its pull request commits. With the switch off, or without a write-capable connection, the analysis is shown what 0.1.120 showed (apart from the password masking below); with the switch off, a private-network agent is also sent no route edit or branch.

• A pre-approved runbook route opens its pull request with its own edit (same switch): with the switch on, a pre-approved pull-request route that carries its own edit, or the whole content of the file it writes, commits exactly that — whether a person releases it from the incident or from a change request, or it opens on its own (Allow pre-approved routes to auto-fire). A file change proposed by the analysis or by the change plan is left out; before, it replaced the route's edit, so a pre-approved runbook could open a pull request with text its pre-approval never covered. A change plan with several file changes is no longer refused for such a route, since none of them is used. The release preview shows the route's own edit; when a different edit was proposed, the release records Runbook's own edit kept — proposed edit left out (change.proposed_edit_ignored) in the audit log, and a proposal identical to the route's edit records nothing. Routes without their own edit, and routes that are not pre-approved (a demoted one included), still take the analysis's file change. With the switch off, the analysis's file change still goes through the route, as in 0.1.120.

• An automatic release never writes a file the route does not name (no switch): a pre-approved pull-request route that names its file — its path, or its path_template filled in for the incident — no longer opens its pull request on its own when the analysis's file change would point it at another file or create one. The incident stays escalated for a person, and the audit log records Automatic fix blocked with the file the change would have written and the file the route names. A person's release from the incident is unchanged; its preview shows which file the pull request writes. A route that names no file still leaves the file to the analysis.

• An edit that matches more than one place is refused (no switch): a pull request whose find-and-replace edit — the analysis's, a route's own, or the reversed edit a restore pull request falls back to when no pre-change copy of the file was kept — replaces text that appears more than once in the current file is now refused, as a pinned or prepared edit already was, with the file named in the refusal. Before, only the first occurrence was replaced and the pull request opened, so the change could land in the wrong block while the right one stayed broken. Re-run the analysis for an edit that matches one place.

• Connection-string passwords stay out of action descriptions (no switch): a password in a URL of any scheme in a route's or a connection's settings — postgres://user:password@host, redis://:password@host, amqp://, mongodb+srv:// — is now masked wherever that action is described: the routes shown to the analysis and sent to a private-network agent, release previews and saved reviews, and an analysis that repeats it. Before, only http(s) URLs had their password masked, so a runbook edit carrying a database password reached the model provider in clear. The bytes a pull request commits are unchanged.

• An IMDSv2 fix is no longer refused as credential material (no switch): a plan for Security Hub EC2.8 that names the setting as MetadataOptions.HttpTokens=required read as a secret key, so the prepared fix was refused ("The proposed execution contains private credential material") and the setting showed as HttpTokens=[REDACTED:secret]. A dotted name is now judged by its last part as well: the IMDSv2 setting stays readable and the fix can be prepared, while a dotted secret such as db.password is still masked.

Upgrade notes

• The switch still defaults to off: off, the analysis's prompt and the route it may pick are 0.1.120's (passwords aside), and a release commits what 0.1.120 committed unless one of the no-switch fixes above refuses it. Turn it on as before, from the card or with PATCH /api/aiops/{tid}/guardrails and runbook_routes_with_typed_plans: true.
• Roll private-network agents to 0.1.121 before relying on the new offer: a 0.1.120 agent ignores a route's edit and branch and keeps the word-for-word instruction, so its analyses can still decline a runbook route that carries its own edit. Which edit a release commits is decided by the control plane, whatever the agent's version.
• Pre-approved routes that auto-fire: after the upgrade, a pre-approved route whose analysis used to create a file, or a template route whose analysis edited a different file, waits for a person; look for Automatic fix blocked on its incidents, and give the route its own edit or release it from the incident.
• API clients: with the switch on, POST /api/aiops/{tid}/incidents/{id}/remediation-preview and a change's execution review carry proposed_edit_ignored: true when a different proposed file change was left out, and the agent configuration a private-network agent reads (GET /internal/agent/v1/config) lists a pull-request route's base_branch and its own edit ({path, find, replace}, or {path, create?, content_summary}) among the route parameters; off, both answer as in 0.1.120. An Automatic fix blocked audit row (incident.auto_remediate_blocked) for a file outside the route carries outside_file and declared_file.
• Schema: no change.

0.1.120 — 13 October 2026

• Webhook tokens no longer land in recorded changes, alerts or findings (no switch): a sender that cannot set a header — an Amazon SNS subscription, an Azure Monitor action group — carries the workspace's webhook token at the end of the intake URL (/webhook/<source>/<workspace-slug>/<webhook-token>), and the cloud's own record of that subscription handed the token back: a CloudTrail sns:Subscribe keeps the endpoint, an Azure Resource Graph change keeps the action group's webhook address, and a Security Hub finding about the SNS topic that feeds the intake can list its subscription. The token in such a URL — the path segment after the workspace slug, or a token= query value — is now redacted before the change is recorded and before an alert or a scanner finding is stored (whether or not the optional alert privacy filter is on), as it is in a change reported through the change webhook, in tool output, in collected telemetry and in the reports and artifacts the platform writes. The source and the workspace slug stay readable, so a record still says which intake was wired. Only the platform's own intake URLs count: the source must be one the intake serves and the token as long as a minted one, so another system's /webhook/ path — a repository folder, a Kubernetes namespace, your own application's webhook receiver — is left alone, while a mistyped or escaped intake URL (/Webhook/, JSON's \/, a doubled or empty segment) is still caught.
• Tokens recorded before this release are masked when they are read (no switch): stored rows keep their original bytes, but the token reads [REDACTED:secret] on the Changes list and change pages and in every API answer that carries a change, in the alert list and an incident's alerts, on an incident's last-known-good card and in the rollback recommended first (on the change request page and in the report a new analysis writes), in artifact bodies (reports, exports and records), in the change history an analysis reads (change_lookup), and in a benchmark dataset's preview and download, a benchmark run's results, its certification bundle and the closed-incident back-test export. A revert draft still reads the stored before-state.
• Runbook routes beside write connections (switch, off by default): once the incident agent has a write-capable connection, the analysis writes its fix as typed steps and no configured route could be picked for that fix, so a pre-approved runbook route never opened its pull request on its own and a rollback never demoted it. With Let the analysis pick a matching route instead of typed steps on (Guardrails & cost → Pre-approved auto-fix (L1), aiops_runbook_routes_with_typed_plans), the analysis is also shown the enabled routes that match the incident (their action details, never a connection's configuration or credentials) and may name one of them, leaving its typed steps empty. That route then works as it does without write connections: the incident stays escalated until it has run, a person releases it from the incident, a pre-approved pull-request route opens its pull request on its own when Allow pre-approved routes to auto-fire is on — under the same guards: never at L3, never for a flapping or unmapped incident or a fix that did not hold — and Demote a pre-approved route after one rollback applies to its runs. The change request proposed with the analysis becomes the record of the route's run instead of a second request beside it: same number, dated at the release, keeping the scope the analysis listed, with the route's tier and approvals (its Change request opened audit row carries proposed_request). A plan with typed steps never uses a route — nor does one whose typed steps the plan check sent back and the analysis could not evidence — a route is never picked by priority alone, and the control plane checks the named route against the workspace's own switch and routes. A compliance control or a scanner finding is never offered a route: its fix stays the prepared plan with its exclusion checks. While the workspace is paused, a named route is not released, as a prepared plan is not. Off, the analysis writes typed steps only once a write-capable connection exists.
• A model that refuses prompt caching no longer fails the run (no switch): on Amazon Bedrock some Claude models do not accept prompt-cache points — Claude 3.5 Sonnet v2, the in-region APAC alias among them. The platform already sent such a call again without them, but only when the refusal came back as a 400; through an LLM gateway it can come back as a 403 or a 500, and the analysis then failed on its first model call. Bedrock's refusal is now recognised whatever status carries it: the call is sent once more without cache points, and that model gets none for the rest of the process. Results are unchanged; only the caching discount is lost for a model that never offered it.

Upgrade notes

• Retire a webhook token that travelled in a URL: where an Amazon SNS subscription or an Azure Monitor action group posted to the intake with the token in its path before this release, the token can sit in stored changes, alerts, scanner findings, artifacts and benchmark datasets. The reads above mask it, but the stored rows keep it, and some stores written before the upgrade are neither rewritten nor masked when read: estate x-ray scans and their ontology download, knowledge items, chat history, the audit trail and its export, lakehouse rows, an incident's title and root cause, and recheck summaries. Mint a new token on Alert intake & tokens (Mint webhook token, confirmed with Mint token, pillars.manage). The previous token stops working the moment the new one is issued, with no overlap, so update every alert source in the same window. Every other sender can carry the token in a header (Authorization: Bearer <webhook-token> or X-Webhook-Token), which keeps it out of URLs and access logs.
• Collected telemetry that records the intake URL: a webhook token in a collected log or metric is a secret like any other, so an access log that records POST /webhook/<source>/<workspace-slug>/<webhook-token> — the path an SNS subscription must use — now raises the PII detected in collected telemetry compliance incident for that connection on its next collection. Senders that carry the token in a header do not.
• A certification bundle over a dataset that held a webhook token: GET /api/aiops/{tid}/benchmarks/{run_id}/certification.json masks the token in its scenarios and then carries a redacted note. Its seal (bundle_sha, the value audited when the run was certified) is unchanged, so for such a dataset it re-verifies from the stored set only, not from the downloaded bundle or the dataset export.
• The new switch is off by default: off is 0.1.119's behaviour. A workspace owner (members.manage) turns it on from the card or with PATCH /api/aiops/{tid}/guardrails and runbook_routes_with_typed_plans: true; null restores the platform default (AIOPS_RUNBOOK_ROUTES_WITH_TYPED_PLANS, off). PATCH /api/aiops/{tid} takes only JSON true, false or null for aiops_runbook_routes_with_typed_plans (400 otherwise). It changes nothing until the incident agent has a write-capable connection and an enabled route matches the incident, and nothing for a compliance control or a scanner finding.
• Roll private-network agents to 0.1.120 before relying on the switch: the runner configuration now forwards it, but an older agent never offers the routes to its analysis, so the switch has no effect on its runs until the agent is updated.
• API clients: GET /guardrails answers runbook_routes_with_typed_plans; an analysis whose wrap-up was offered the route choice carries typed_route_offer: true in its wrap-up, and only such a wrap-up can bind a named route. Change, alert, artifact, last-known-good and benchmark answers (dataset preview and export, run results, certification bundle) carry a redaction marker ([REDACTED:secret], or the privacy filter's salted [REDACTED:secret:<hash>]) where a webhook token stood.
• Schema: no change.

Next steps

• Next: Release notes 0.1.116 to 0.1.119
• All What's new pages
• Documentation home