WorkspaceTalon Studio v1.0.2-beta

Overview

The unit of Git-backed detection engineering: content as YAML in a per-workspace repository, change requests for review, workspace roles, and a governed release pipeline.

What it is

A workspace is a project with its own Git repository, the source of truth for its detections, sourcetypes, deployment targets, automations and release artifacts. Content changes are commits, so they are versioned, reviewable and diffable; Postgres holds the working copy the UI reads, plus the things that never live in Git (users, credentials, change-request approvals, validation and run history).

workspace repository layout (new workspaces)

Talon/workspace.yaml     # manifest: name, SIEM types, require-CRs flag, SOC, Claw autonomy

Talon/detections/        # one YAML file per detection (detections/ in older workspaces)

Talon/streams/           # sourcetype metadata from your SIEM

Talon/targets/           # deployment targets (no credentials)

Talon/deployments/       # generated release artifacts, one folder per SIEM

agents/skills/           # Talon Flow automations

Community Edition: one workspace

The Community Edition allows one workspace. Once it exists, the New workspace card on Workspace → Organisation reads "Workspace limit reached", and creating another is refused with "Workspace limit reached (1/1). More come with Enterprise, which is in development." See Licensing.

How it works

main and branches. main is what ships. Every other branch is backed by a change request: New branch… creates a draft change request on its own branch off main. Engineers may commit to main directly unless the workspace's Require change requests setting is on, in which case only workspace owners can.

Change requests. A change request carries the files changed, the detections affected, automatic validation and its reviewers. Agent edits always arrive as change requests on their own agent/… branch, never on main.

Approve & merge. A member with approve permission approves once the change request's gate is ready, as many times as the review policy requires, and then merges it to main. See Change Requests.

Roles. Per-workspace roles: viewer (read), engineer (edit, commit, open, approve and merge change requests, deploy), owner (all of that plus workspace settings and members). A workspace role can only narrow the user's org role: an org analyst cannot approve or deploy anywhere, a readonly user only reads, and an org admin is an owner of every workspace. Custom roles can narrow further.

Change requests & deploys

Detections reach a SIEM through the release pipeline, built from what is committed on main. Splunk gets a Talon app package (its detections as savedsearches.conf); Sentinel, Elastic and Chronicle get one rule per detection (an analytics-rule JSON, a detection-rule JSON and a YARA-L rule), converted from Sigma by the bundled pySigma service.

Convert on deploy. A rule is rendered per target at deploy time, so a detection written once ships to every SIEM the workspace uses.

Targets and branches. The Community Edition deploys from main only and allows one deployment target across the install. Deploying other branches to their own targets, and more targets, come with Enterprise, which is in development.

Check → deploy → record. A readiness check confirms the target is reachable and authorised; the deploy installs (Splunk Cloud ACS, Splunk REST or SSH for Splunk; REST for the others) and writes a deployment record. Roll Back Deploy on a detection's page re-pushes its previous successful deployment, on all four SIEMs.

The hard release blocker

One validation result fails the release outright rather than warning: a detection that fails environment-readiness validation (it cannot run in the connected SIEM) blocks, whatever the org's validation policy. Open or approved-but-unmerged change requests only warn, because main's committed state ships regardless and in-flight branches cannot affect the package. Behavioural and simulation failures also warn under the default policy; an org can switch its validation policy to block.

Usage

Create the workspace from New workspace on Workspace → Organisation (/workspaces/organisation); you become its owner. Set its SIEM types in its workspace settings, and have an admin grant people access under Settings → Users & teams → Teams & access.

Edit detections in Forge, Atlas or YAML. On main an edit waits as a pending change until you commit it from the workbench; for review first, use New branch… and commit there.

Open for review, approve and merge the change request at /workspaces/<id>/change-requests (Workspace → Change Requests).

Deploy from /workspaces/<id>/deployments (Workspace → Deployments), and roll a detection back from its page if needed.

Tip

Turn on Require change requests in the workspace settings to make review mandatory: engineers then have to work on a branch, every change ships through a reviewed change request with validation, and main stays a known-good state you can always deploy from.