Security Center
When a package version turns out to be vulnerable, you can make sure nothing in your organization runs it. In the Security Center, an admin blocks a version range, sees every stack, manifest, space and run that holds it, moves them to a clean version in one step, and stops the running work that cannot wait.
Available to org admins and owners. Members see the effect of a block on their own spaces and manifests.
What you can do with it
- Close the door in seconds. Block
tool-x <1.4.3. Within seconds, no space, run, deputy, schedule or trigger can start with a version in that range. - Fix everything with one confirmation. Preview which stacks republish and which manifests move to the newest installed version that is not blocked, then confirm once.
- Stop what is running, now or later. Stop the running spaces and runs that hold the version when you create the block, or whenever you decide to. Spaces with their own disk keep it.
- Bring outdated spaces up to date. See the spaces that run an older manifest than they should, tell their owners, or restart them all onto their manifest.
Open the Security Center
Open Security Center in the admin area. It has these tabs:
| Tab | What it shows |
|---|---|
| Overview | Four counts on one screen: Active blocks, Affected spaces, Spaces to be checked (spaces with no package record yet) and Outdated spaces. Each count links to its tab. |
| Blocked versions | Your blocks. Create one, open one to see what it affects, fix it, stop its running work or Unblock it. Removed blocks stay as history behind Show removed. |
| Affected & outdated spaces | Spaces that run a blocked version, and spaces that run an older manifest than they should. |
| Egress | Where agent traffic went and what was blocked. |
| Credentials | Which credentials exist and how old they are. |
Block a version range
- Open Blocked versions and start a new block.
- Choose what you are blocking: a marketplace package, or the runtime versions a toolchain package offers, for example node inside the node toolchain.
- Enter the version range and a reason. Everyone who is refused sees the reason.
- Choose what happens to work that is running now: Leave running and notify owners (the default) or Stop them now. The dialog shows how many running spaces and runs hold a version in the range.
- Confirm.
The block applies within 5 seconds. Blocks belong to your organization and never affect another one. Overlapping blocks on the same package all apply, and unblocking one leaves the others in force. An org can hold up to 200 active blocks.
If the range matches no installed version, the block is still created and you are told that no installed version matches. The block applies as soon as a matching version is installed.
Range syntax
| Write | Meaning |
|---|---|
1.4.2 | Exactly version 1.4.2. |
=1.4.2 | Exactly version 1.4.2. |
<1.4.3 | Every version below 1.4.3. |
<=1.4.3 | 1.4.3 and everything below it. |
>1.4.0 | Every version above 1.4.0. |
>=1.4.0, <1.4.3 | A comma means and. This is 1.4.0 up to, not including, 1.4.3. |
<1.2.0 || >=2.0.0, <2.0.4 | || means or. Each side can hold several comparators joined by commas. |
Prereleases are included, so <1.4.3 also blocks 1.4.2-hotfix. A leading v is ignored. A version that is not in major.minor.patch form is blocked only by writing it exactly. Ranges accept the operators =, <, <=, > and >=. Shorthand such as ~, ^ and * is rejected with a message that lists the supported operators.
A range that matches every version of the package asks you to confirm a second time before it is saved.
What a block stops
A block applies on every path that starts work:
- creating a space and forking a space
- launching from an agent tool
- starting a run
- deputies, schedules and triggers
- orchestration child runs and continuations
- starting a stopped space
A refused launch names the package, the version and your reason, and starts nothing. If Marshal cannot check the block list at that moment, the launch is refused too, so a blocked version is never started by accident.
Starting a stopped space
A stopped space remembers the packages it was created with. When you start a space that holds a blocked version, Marshal builds it again from its current manifest and starts it on that, even when your organization keeps spaces as they were made and even when the manifest is held. Where the manifest has already moved to a clean version, the space starts on it. Where the manifest still holds the blocked version, the start is refused with a link to the manifest, and the space stays stopped with its disk intact if it has one.
While any block is active, spaces created before Marshal recorded their packages are checked the same way when they next start.
Saving a manifest
You can always save a manifest. When it holds a blocked version, the save shows a warning that names the package, and launches from it are refused until it moves to a clean version. Cloning a manifest that holds a blocked version shows the same warning.
See what a block affects
Open a block to see everything that holds a version in its range, each with its owner and a link:
- stacks
- manifests
- running spaces
- stopped spaces
- running runs
- spaces with No package record: spaces created before Marshal recorded their packages. They are counted as Spaces to be checked, and each is checked on its next start.
Spaces outside the range are not listed. When nothing uses the range, the block says so.
Affected spaces and manifests carry a Blocked version badge naming the package. Hover it for the reason and what to do next.
Fix affected
Fix affected moves stacks and manifests onto the newest installed version that is not blocked by any active block.
- Open a block and select Fix affected.
- Read the preview. Nothing has changed yet. Each stack shows the version it will republish on. Each manifest shows its current and target versions. A major version change is marked major; a move to an older version is marked older; a manifest whose hold is overridden shows overrides hold; one whose version pin is rewritten shows rewrites pin.
- Confirm. The stacks republish and the manifests move. Held manifests and manifests that pin the blocked version move too, because a block overrides a hold and a pin.
Items that cannot move are listed with the reason:
| Reason | What it means |
|---|---|
| No installed version is outside the block | Every installed version of the package is blocked. Install a clean version, then fix again. |
| No offered runtime is outside the block | No runtime the toolchain offers is outside your blocks. |
| A toolchain would break on the new version | The move would leave a toolchain without a runtime it needs. |
| The stack has unpublished draft changes | Publish or discard the draft first. |
| Its stack cannot move | The stack a manifest builds on cannot be republished. |
| Its stack failed to republish | The stack was tried and the republish did not finish. The manifest stays where it was. |
| It changed while the fix ran | Someone edited the item after the preview. Preview again. |
An item that cannot move shows Cannot move with its reason, and one that was passed over shows Skipped with its reason. If the plan changes after you open the preview, the dialog says so and shows the new plan. Review it, then choose Apply the new plan.
Every move is recorded in the audit log. Automatic updates and the stack cascade never choose a blocked version.
Stop the running work
Stopping is your choice, at any time:
- At block time. Pick Stop them now in the block dialog.
- Later. Select Stop all affected on the block. The running spaces that hold the version stop, and the running runs that hold it are cancelled.
Each space stops through the normal stop path and shows Stopped for security as its stop reason. A space with its own disk keeps it; a space without one loses its workspace when it stops. Spaces and runs outside the range keep running. A space that fails to stop is shown with its error and does not hold up the rest. Running spaces with no package record keep running and stay counted as spaces to be checked. Restart them from the outdated list to refresh them, or stop them one by one.
Owner emails
Each person who owns an affected space or manifest gets one email per block. It names the package, the range and your reason, and lists only that person’s own spaces and manifests with links to them. Manifests owned by a team or the whole org are not mailed. Emails are on by default and need your organization’s mail provider to be set up.
Each person controls them on the Settings tab of the Alerts page, under A package version your spaces or manifests use was blocked (email). Turn Email me when it is raised off to stop the email, or turn Show this alert off to stop it as well. Only people who own a space or manifest see the switch. The Notify owners email for outdated spaces is sent under the same kind, so opting out stops it too. See Alerts. The Blocked version badge shows either way.
Outdated spaces
A space is outdated when it runs an older manifest than it should. The Affected & outdated spaces tab lists them with their owners.
- Notify owners sends each owner one email that lists their outdated spaces. Pressing it again within 24 hours sends nothing more.
- Restart all stops each running outdated space and starts it again on its current manifest. It does this even when your organization keeps spaces as they were made and when the manifest is held. A space without its own disk keeps running and is listed as skipped, so its work is never lost. Each restart is recorded.
Who can do what
| Role | What they can do |
|---|---|
| Org admin or owner | Everything in the Security Center: create and remove blocks, see what is affected, fix, stop, notify and restart. |
| Member | Open no Security Center pages. See the Blocked version badge on their own spaces and manifests, and the reason when one of their launches or starts is refused. A refusal never names other people’s spaces, owners or counts. |
For space owners
If you see Start refused: blocked version, an admin blocked a package version that your space holds. The message names the package, the version and the reason, and links to your manifest.
- Open the manifest from the link.
- Move it to a version of the package that is not blocked (upgrade the manifest). If your admin has already used Fix affected, it may be done.
- Start the space again. It starts on the clean version. If the space has its own disk, your files are as you left them.
A space that an admin stopped for security shows Stopped for security. If it has its own disk, its workspace is kept. Update the manifest, then start it. If the manifest has no clean version to move to, ask an admin to install one.
From an AI agent
The same controls are available as agent tools for org admins. See Connect an AI agent (MCP).
| Tool | What it does |
|---|---|
security_overview | Counts of active blocks, affected spaces and outdated spaces. |
security_blocks_list | Lists your blocks. |
security_blocks_create | Creates a block with a package (installed or not) or toolchain runtime, a range, a reason and what to do with running work. |
security_blocks_remove | Removes a block. |
security_blocks_affected | Lists what a block affects. |
security_blocks_fix | Previews Fix affected, then applies it on confirmation. |
security_blocks_stop_affected | Stops the running affected spaces and cancels the running affected runs. |
security_outdated_spaces | Lists outdated spaces. |
security_outdated_notify | Notifies the owners of outdated spaces. |
security_outdated_restart | Restarts the running outdated spaces onto their manifests. |
Try it
Open Security Center > Blocked versions, create a block for a version you do not use, and open it. The block shows that nothing currently uses the range. Select Unblock when you are done; you see “Block removed”.