Changelog

v1.0.2-beta, 18 October 2026

Added

• A threat model drafts from Terraform. Import reads the JSON of terraform show -json, for a state or a plan, or a terraform.tfstate file. Storage, compute, databases, clusters, gateways and queues on AWS, Azure and Google Cloud become components, the networks that hold them become trust zones, and the flows the file states outright (Lambda event sources, load balancer targets, CloudFront origins and API Gateway integrations) become data flows. Anything left out is listed before you import.
• A threat model drafts from your ServiceNow CMDB. Draft from ServiceNow reads a CI, by name or sys_id, and the CIs up to two relationships away. Servers, databases, applications and network devices become components and their relationships become data flows, and an operating system or appliance maker becomes a product for threat intel. You check the draft before it is saved.
• Talon Forge's Threat Scenarios import a MITRE Attack Flow. A STIX 2.1 bundle exported from the Attack Flow Builder becomes a draft scenario: its actions become stages in order, each matched to one of your detections by its ATT&CK technique. A stage with no detection is left out, and loops and parallel steps are listed before you create it.
• A threat model exports as an audit report. Export → Audit report writes a Markdown file of the model's scope, each element with its threats and answers, its gaps, accepted risks and design controls, the work planned from it, and how coverage was judged.
• A threat model flags a log that stopped arriving. A log source the SIEM has, but whose newest event is more than three days older than its latest sync, reads Stopped. Restoring it is the model's first next action, and Plan the work sends it to the Data Engineer. A model nobody has changed in 90 days says its review is due.
• Threat Readiness counts your threat models. Each model weighs in the readiness score by how many of its detect threats are covered on their own components' logs, and a Threat models panel lists the five least covered.
• A threat model drafts from AWS CloudFormation. Import reads a CloudFormation or SAM template, in JSON or in YAML with short-form tags such as !Ref and !GetAtt. The same AWS resources as from Terraform become components, the VPCs that hold them become trust zones, and the flows the template states outright (Lambda event sources, load balancer targets, CloudFront origins, API Gateway integrations and SAM events) become data flows. Parameter values never leave the template.
• A threat model drafted from infrastructure says what has changed since. A model drafted from Terraform, CloudFormation or ServiceNow remembers its source and the resource behind each component. Check for changes, under the model's name, reads the source as it is now (a newer state file or template, or the ServiceNow CI again) and lists the resources that are new and those that are gone. The new ones can be added with their data flows; nothing is removed for you.
• A threat model sends an attack path to Talon Replay. Right-click a component, or use its side panel, and choose Simulate an attack path from here. Follow the data flows step by step, pick the threat acted on at each, and Talon creates a draft Threat Scenario whose stages are the workspace detections for those threats' ATT&CK techniques, ready to run in Replay.
• The Reviewer agent reviews threat model changes. On a change request that touches a model's YAML file it sees what the change did, such as a threat removed or weakened, a log source dropped or a STRIDE question reopened, and an accepted risk or a not-applicable answer with no reason is a finding.
• Talon Claw → Usage shows where the AI budget went. For today, 7, 30 or 90 days: spend, model calls, tokens and the prompt-cache share, spend by day, and spend by feature, by agent and by model, beside the budget when one is set. Calls no price covers (self-hosted models and the subscription engines) are counted and labelled unpriced, never shown as free. Admins only.
• Every model call is now counted against the AI budget. Stream classification, SIEM migration, Sigma conversion review, ATT&CK mapping, threat-intel extraction, synthetic events, memory upkeep, automation steps, search intent, commit messages and connection tests used the model without being recorded; they are now in the usage log, each under its feature. Usage recorded before this release reads Other (unlabelled).
• Agents keep a version history. Each save of an agent, and each Studio update that changes one, becomes a new version, and every run is stamped with the version it ran under. The agent editor's Versions tab lists them with what changed, each version's runs, success rate and thumbs, and Restore this prompt brings back an earlier prompt as a new version, leaving tools, skills and model as they are.
• Agents can propose a better prompt from their own record, and you decide. The agent editor's Versions tab lists what an agent's last 14 days keep showing: the same failure in several runs, a tool that keeps erroring, thumbs-down and their reasons, and what reviewed runs were marked down for. Review recent runs has your AI provider grade up to five unreviewed runs, failed and thumbs-down ones first. Propose an improvement drafts a new prompt that answers those findings. It changes only the prompt, may not grow it by more than about a sixth, and does nothing until an admin activates it or discards it. Each version shows its reviewed score once ten of its runs are reviewed. Both actions are admin-only, count toward the AI budget, and run only when someone presses them.
• A Validation Engineer agent proves live detections fire. "Plan the work" on a threat model also sends each live technique whose detection no test has seen fire to the Validation Engineer, and the model panel links to it. It proposes recorded attack data from the Splunk content library as a change request — when a person merges it, Talon replays the data into the Splunk test target and records the result — or asks a person to run the tests a detection already carries. It runs nothing itself.
• A Scenario Engineer agent drafts Threat Scenarios. Give it a threat model or an adversary and it chains the techniques on that path, in kill-chain order, into a scenario built from your own detections, and hands techniques with no detection to the Detection Engineer. Approving its proposal opens a draft change request; new scenarios merge as drafts, and replaying or activating one stays with a person in Forge → Threat Scenarios.
• A Posture Analyst agent briefs security leaders, in a new Governance & Compliance department on the Brain. It reports maturity, threat readiness, detection governance and NIST 800-53 control coverage from dated numbers and is told to hand at most two concrete gaps per run to specialists. It never calls a control met or compliant and proposes nothing itself.
• Claw keeps adopted library rules current. When the upstream rule behind a detection adopted from the content library is updated and its detection logic differs from the detection's, Claw proposes carrying the change into the detection for the Detection Engineer, who can now read a library rule in full. An update after which the detection still matches upstream logic is ignored, removals are not routed, and at most ten such proposals are open per workspace.
• Hunt a threat with the Threat Hunter from the model. An uncovered technique whose component's logs are present gets a "Hunt it with the Threat Hunter" link next to "Draft one with the Detection Engineer".
• Agents are warned before the AI budget runs out. From 80% of the token or cost budget, every agent is told to be economical (fewer and smaller tool calls, no speculative exploration), and Talon Claw → Usage says how much is spent and that new AI requests are refused at 100%.
• Verify a Sigma conversion with AI. Each conversion tab in the Forge library has a Verify with AI button that asks the workspace's AI connection whether the converted query keeps the Sigma logic and runs on the target, and returns a verdict, the issues and a corrected query. It runs only when pressed and saves nothing.
• Brief me on Mission Control. The Detection Maturity panel's Brief me opens Talon Claw on the Posture Analyst for the selected workspace. The agent reads maturity, threat readiness and governance itself and proposes nothing. Every role that can chat sees it, readonly included.
• A Weekly posture brief Flow template. In a new Governance & compliance category, it runs the Posture Analyst every 7 days, waits for it, and sends the brief to the notification destinations that receive System notices at Info, after the run id to open in Talon Claw → Agents → Activity for the full brief. Slack and Teams show it as one paragraph, cut at about 2,800 characters. A run that fails sends a warning with the reason instead. It runs only once a person saves it in a workspace; if the agent run cannot start, the usual Flow-failure notice goes out instead of the brief.
• A Flow's Run agent step can wait for the result. Set Wait for the result and later steps read the agent's reply as summary, with its status and error. It works in a flow run of its own, not inside a subflow, a loop or chat. By default the step still starts the run and carries on.
• Build a scenario with the Scenario Engineer from a threat model. Once two of a model's threats are mapped to ATT&CK, a button beside Ask the Threat Modeler opens the Scenario Engineer on that model. It reads the threats itself, chains the techniques your workspace already detects in kill-chain order and hands the rest to the Detection Engineer. It only proposes: the scenario still ends as a draft change request a person reviews.
• Firing tests where Splunk cannot replay a detection. When nothing can replay a detection here (it has no SPL, the org has no Splunk test target, its SPL cannot be confined to the test index, or Splunk macros, data models or lookups it needs are missing), the Validation Engineer now proposes the recorded datasets Talon's in-house Sigma check can read, when the detection has a Sigma rule: JSON lines such as CloudTrail, Microsoft 365, Entra ID and Okta. The change request says merging replays nothing into a SIEM and that a person runs the in-house check from Forge → the detection → Simulation after the merge. Windows XML and raw-log datasets are dropped with the reason, and when neither path can run the tool refuses and gives both reasons.

Changed

• The Triage Analyst works every detection-health signal from Claw. Failed deploys, noisy detections and broken or silent SIEM rules go to the same agent as failing validations and Triage with AI, and Monitor's "Tune with AI" opens it too. For a SIEM rule Talon does not manage it proposes a remediation plan for an admin to apply, never a Sigma edit. Proposals already waiting keep the Detection Engineer. To give one to the Triage Analyst, use Assign to teammate, then Assign & run on its card with Auto. Do not dismiss it: Claw proposes a dismissed problem again only when it recurs. If you saved a custom tool list for the Triage Analyst, grant it list_streams and propose_siem_action, and a role prompt you saved for it keeps its old instructions until you reset or update it; a Detection Engineer with a saved tool list needs get_library_rule.
• Plan the work no longer re-proposes work in flight. It skips what is pending, dispatched with its card still open, or dismissed since the model last changed, and says when an agent it needs is turned off. A Threat Modeler run no longer overwrites a person's save made after it read the model.
• Threat Intel has one Analyze report button, in the page header. The two near-identical buttons in the filter bar are now one, and its result has Open in chat for the assistant.
• Threat model and automation canvases open tidied. Trust zones in a threat model no longer overlap, and a right-click menu adds a component at the cursor, tidies the layout, connects components, moves one to a zone, duplicates it, or removes a component or flow.
• The profile page matches Talon Labs. A cover banner with your name, role and sign-in details, stat tiles, and Overview, Security and Activity tabs.
• Organisation Files shows pending changes. Org YAML staged but not yet committed appears in the tree, marked added, modified or deleted, as in the workspace Workbench.
• Threat model next actions prove a detection before drafting a new one. The order is now restore, onboard, deploy, validate, draft, map and analyse, so a model with many uncovered techniques no longer hides Prove it with the Validation Engineer or drops that work from Plan the work. Next actions still lists eight and has a Show all toggle for the rest.
• Plan the work no longer proposes a firing test a person has already been asked to run. While an open Firing test card on the Workboard links the detection, planning counts that test as already planned, whichever threat model the card links.
• The Validation Engineer finds recorded attack data for detections that read only through macros. A detection whose SPL names no sourcetype and reads its data through macros such as sysmon or cloudtrail is matched on what those macros read in the synced Splunk content library. A macro that pins sources is matched on those sources alone, so a generic sourcetype such as XmlWinEventLog never lets in another channel's data. A macro that reads more than one OS's logs, such as sysmon for Windows and Linux Sysmon, is matched only on the OS the detection's Sigma logsource or data sources name, and on neither when they name none.
• request_firing_test_run picks the check that can run. With no provider named, it falls back to the in-house check when nothing can replay the detection, and it refuses an in-house check whose only material is attack data with no JSON lines.
• Sigma rules on Entra ID and Google Workspace logs match the Splunk sourcetypes those logs arrive under: azure:monitor:aad for sign-in and audit logs, and gws:reports:admin and gws:reports:login for Workspace admin and login logs. Library data readiness picks this up at the next content sync.

Removed

• Settings → Hosting. The page and its menu entry are gone.

Fixed

• Sigma conversions run on the target. Splunk gets Sysmon source and EventCode mapping, Sentinel KQL names its table and Chronicle maps to UDM, where most rules came out as bare Sigma field filters before. Library conversions re-render once with the new converter.
• Azure Sentinel rules load after an interrupted first sync. A content mirror left half-checked-out by a restart repairs itself on the next sync instead of failing every update.
• Change-request and commit diffs show their content again. The diff pane showed a single empty line for every file, whether added, modified or deleted, and so did the Workbench commit diff and detection history. Each hunk now carries its line counts, so every file shows its real before and after.
• The diff and code editors stop raising blocked-worker errors. The change-request and commit diffs and the Sigma, query, Workbench and settings editors no longer try to start background workers the security policy refuses, so they no longer log those refusals or uncaught page errors. They already did their work on the page itself.
• A recorded replay that cannot be confined to the test index sends nothing. For a detection whose SPL starts with a generating command or sets its own index=, Talon used to download its attack data and send it to the Splunk test target, and only then refuse the replay. It now refuses before downloading anything, on merge, in the scheduled validation sweep and when run by hand.

v1.0.1-beta, 17 October 2026

Added

• Talon Threat → Threat Models models a system with STRIDE and checks it against your SIEM. Draw components, trust zones and data flows on a canvas, or start from an example. Each component lists the log sources it should send, and each threat carries ATT&CK techniques. The canvas then shows which logs the SIEM has, which techniques are live, ready, blind or uncovered, and which STRIDE questions are still open, with next actions for each. Models are YAML files in the workspace repository, saved for your next commit.
• Threat models import from OWASP Threat Dragon and Threagile, and export to Threat Dragon. Threat Dragon 2 JSON comes in with its STRIDE threats and trust boundary boxes; Threagile YAML brings its assets, boundaries and links. Anything that cannot map is listed before you import.
• A Threat Modeler agent joins Talon Claw. It reads a model with its live coverage, answers open STRIDE questions, maps threats to ATT&CK and adds missing log sources. Like every agent it only proposes: approving its proposal opens a draft change request for review.
• Threat models can answer a STRIDE question "not applicable". Give a reason and the question closes, without writing a threat only to accept it. The answer is saved in the model's YAML file, exported to Threat Dragon, and the Threat Modeler can propose it.
• "Plan the work" turns a threat model's gaps into proposals on the Workboard. A log source the SIEM lacks goes to the Data Engineer; a technique with a ready rule nobody deployed, or with no rule, goes to the Detection Engineer. Each card links back to the model, and planning again adds nothing that is already waiting.
• A threat model shows which techniques are validated. A deployed detection whose latest Talon Monitor test or Talon Replay run saw it fire reads Validated, above Live. A Live technique nobody has tested gets a next action to prove it fires.
• A threat model shows the work it started. Proposals still waiting, the Workboard cards they became and the detections those cards drafted appear on the model, and each threat lists the detections drafted for it.
• A threat model shows threat intel. Each threat names the priority actors from your Threat Profile that use its techniques. Components list the products they run, and a new Threat intel overlay shows their known exploited vulnerabilities from the CISA KEV catalog.

Changed

• A threat model judges each threat on its own component's logs. A rule that reads a different system's logs no longer marks a threat covered; the panel names the logs it reads instead. A rule that does not say what it reads still counts.
• Talon Connect's overview covers all four of its sections. Six figures now include detection sources and sync failures, a Sections row says what each section holds, a Detection Sources panel lists each source with the rules imported from it, and Latest Syncs lists every connection's most recent sync, newest first. Latest Syncs is each connection's last sync, not a history.

Fixed

• Talon Connect's overview opens when a workspace has a Vector, Logstash, VirusTotal or ServiceNow integration. Its topology now colours each connection by its status and is readable in light mode.

v1.0.0-beta, 16 October 2026

First public release of Talon Studio, in public beta, for linux/amd64. Expect rough edges and breaking changes between releases.

Added

• A Talon key is required. Without one, every page opens on the key screen, where an admin pastes it, and the API answers 403 with the code licence_required.
• The Community Edition runs on the key that comes with a Talon Labs account. The key is checked offline, on the box.
• Until a key is added, agents and outgoing notifications are paused. Syncs keep running, and nothing is queued.
• Community limits are 2 users, 1 workspace, 1 SIEM connection, 1 deployment target and 2 read-only API tokens, deploying only from main. Enterprise is in development and not on sale.
• First start generates secrets and a random first-admin password in /data/secrets. The password is printed once in the container log and saved to initial-admin.txt; change it at first sign-in. First run then asks for the key, the organisation and a team.
• The update check asks talonlabs.dev which release is newest. The sidebar's version icon is green when current and amber when an update is waiting, and the Releases dialog shows the notes of each newer release, read from talonlabs.dev. TALON_DISABLE_UPDATE_CHECK=true turns off the check and the notes.
• Admins see a banner on every page when a health check fails, saying what to do. It covers the database, detection storage, Sigma conversion, the detection library and the licence.
• Talon Claw's Brain shows your workspace as seven security departments. Each piece of work is Running, Idle, Can't reach, Unowned or Human (kept with a person).
• Talon Claw's chat shows each tool call and a timing badge on every reply, and groups conversations by day. Type @ to send a message to one agent. In Ask Claw, / at the start of a message lists the tool shortcuts.
• Talon Claw searches by words as well as meaning, and reranks its top matches with a small model that runs on the box. It downloads 87 MB on first start and after each upgrade; TALON_RERANK=off turns it off.
• Claude Code (subscription) and Codex (subscription) can be AI providers, billed to a Claude, ChatGPT or Codex plan instead of an API key. Add them under Talon Claw → Settings. A Codex token goes on the connection or in CODEX_ACCESS_TOKEN.
• The assistant's voice runs in its own container, kokoro, beside Studio: the Kokoro-82M model, from an image your machine pulls from its publisher. The release compose file runs the service and points TALON_TTS_URL at it; Helm installs set config.ttsUrl to a Kokoro service they run. With none, replies are read by the browser's built-in voice. The Studio image carries neither kokoro-js nor phonemizer, whose eSpeak NG is GPL-3.0-or-later.
• Talon Monitor has a Triage tab that tracks each detection with an open problem. Slack and Teams destinations send it when "Detection triage" is ticked under Admin → Integrations.
• Triage with AI asks the Triage Analyst agent to propose a fix as a change request. Validating it scores each changed detection on its golden events, before and after.
• Rule health shows which Splunk searches, Microsoft Sentinel scheduled rules and enabled Elastic detection rules have stopped running. Sentinel needs auditing and health monitoring turned on; the Elastic API key needs read on .kibana-event-log-*. A disabled or unscheduled rule shows as unknown, and so does each rule until its SIEM's log covers 30 days.
• Talon checks the Microsoft Sentinel and Elastic rules it deploys for fields their table or data stream doesn't have. A detection's Target validation panel uses its SIEM's own terms: Sentinel rules read KQL, tables and ASIM; Elastic rules read data streams and ECS.
• Talon Atlas can colour the ATT&CK matrix by your SIEM's alerts over 7, 30 or 90 days. A technique with alerts but no saved detection gets a dashed amber outline.
• Talon Threat → Adversaries → Priorities ranks what to build next by what you can act on, and leaves out a technique an enabled SIEM rule already covers. Gaps with a library rule that already runs on your data come first, then gaps your SIEM data can detect, then gaps that need data onboarded; within each, techniques used by your Threat Profile's actors lead. The API's coverage/gaps and the MCP list_technique_gaps tool use the same order and return the same fields.
• Forge → Adopt can migrate a Splunk rule to Sentinel or a Sentinel rule to Splunk: AI translates it, both versions run over the same window, and the translation is staged as a draft change request with both counts. The counts are matches over the window, not alerts, and they only compare if both SIEMs ingest the same data.
• Google SecOps (Chronicle) rules import with their YARA-L text and their real on/off state, and Talon reads every page of rules and log types. The credential needs to read rule deployments; if it can't, the sync says so.
• Talon Search has investigation notebooks: notes and searches kept together, with each search's results saved as they were when it ran. Everyone with access to the workspace can read a notebook; engineers can edit it and link it to a SOC case. Find them under Talon Search → Notebooks.
• Notifications can be sent by email. Add an Email destination under Admin → Integrations, or an Email channel under SOC → Settings, with your SMTP server (STARTTLS or TLS), a sender and up to 20 recipients. It has the same event, severity and workspace filters as Slack and Teams. The SMTP password is stored encrypted and never shown again. For a relay whose certificate comes from an internal CA, paste that CA's certificate and Talon trusts it instead of the public ones.
• Talon Flow's HTTP step can send POST, PUT, PATCH and DELETE requests once an admin approves each one. They wait under Admin → MCP → Actions, and are sent only if the host is still on FLOW_HTTP_ALLOWLIST.
• The beta image tag is the newest merge to main, scanned and signed like a release. There is no edge tag. Pin vX.Y.Z-beta to take only numbered releases.
• The Talon Labs Community Edition Licence ships in the image at /app/LICENSE, and names Talon Studio. Talon Studio is not open source.

Security

• Images are signed with cosign and carry a CycloneDX SBOM attestation. Install → Pull the image shows how to check both with cosign 3.
• Behind a proxy (TALON_TRUST_PROXY=true), rate limits and IP-allowlisted API tokens trust only the last X-Forwarded-For hop and ignore X-Real-IP. Your proxy must set X-Forwarded-For.
• An approved MCP action runs once, even when two admins approve it at the same moment. The second sees "Action is already running".
• The image carries only the compiled bundle and the two scripts the entrypoint runs with plain node, not the application's TypeScript source. Its Debian packages are upgraded when it is built.
• Dependencies carry the fixes for CVE-2026-96889 (sharp 0.35.5, its bundled librsvg), GHSA-6qxp-vccf-f47h (MCP SDK 1.31) and CVE-2026-103111 (libpcre2-8-0).