Script Library

The Script Library is where you write and approve scripts that TridentStack Control runs on your endpoints. A script runs on demand from the Endpoints page, on a schedule or at startup and login through Script Automation, or as the remediation for a failing Endpoint Check.

Account verification

Custom Scripts require a verified account. New and free accounts cannot create, publish, approve, or run scripts, or use Script Automation, until verified. Paying an invoice verifies the account; having a card on file alone does not. You can also contact TridentStack support. A refunded, disputed, or returned payment removes verification associated with that payment. Existing accounts with active endpoints are already verified.

Create and publish a script

Open Orchestration > Script Library, select New Script, and choose a name, platform, language, and run context. The available languages depend on the platform: Windows supports PowerShell 5.1, PowerShell 7, and Batch; Linux and macOS support Shell. Scripts run as System by default (root on Linux and macOS), or you can choose Logged-in user. A user-context script is skipped when nobody is signed in.

Set a timeout between 1 minute and 4 hours. The default is 10 minutes. Choose the exit codes that count as success; any other exit code marks the run failed. Add parameters for values that change between runs. Parameters can be text, number, or true/false, and can be required or have a default. A sensitive parameter is encrypted at rest, masked in output, and cannot have a default. Sensitive parameters are unavailable when the script runs as the logged-in user. Batch scripts do not support parameters.

Select Create script to save a new script as a draft. Save draft saves later edits. Select Publish to make the version available to runs, or Submit for approval if your tenant requires a second administrator to approve versions. An approved version is frozen. Editing it creates a new draft, while the approved version continues to run until its replacement is approved.

Write a script that uses parameters

A script reads its parameters from environment variables. Each parameter arrives as TS_PARAM_ followed by its name, so a parameter named TARGET_DIR is TS_PARAM_TARGET_DIR. Parameter names use capital letters, digits, and underscores, and start with a letter. Values always arrive as text: a true/false parameter is true or false, and a number is written in decimal. A parameter left empty with no default is passed as an empty value.

# PowerShell
$target = $env:TS_PARAM_TARGET_DIR

# Shell
target="$TS_PARAM_TARGET_DIR"

TridentStack Control also sets a few variables that describe the run:

• TS_SCRIPT_NAME and TS_SCRIPT_SLUG: the script's name and its fixed folder and file name.
• TS_RUN_ID: the run's ID, as shown in Run History.
• TS_AUTOMATION_NAME: the automation that started the run, when an automation started it.
• TS_FAILED_CHECKS: on a remediation run, a JSON list of the failing checks, each with its ID and name. The list is shortened, or left out, if it is too long to pass in the environment.

Values are never placed on the command line. Exit with a code from the script's success list (0 by default) when the script succeeds, and any other code when it fails. Anything the script writes to standard output and standard error appears in Run History.

Versions and approval

Open a script and select Versions to review its versions and approval status. When script approval is required, a submitted version waits for a different administrator with the Approve Scripts permission. The approver can review changes to parameters used by automations or check policies before approving. Sensitive values are not shown to the approver.

An administrator can manage approval in Settings > Sign-on Settings, under Script approval. The option Require a second administrator to approve script versions before they can run applies to script versions. The separate option Also require approval for automation changes (script, parameters, targets, run-as) extends approval to those automation changes and to linking a remediation script to a check policy.

Run Script and remediation

To run a script once, select the Scripts tab in the Script Library, open the script's Actions menu, and choose Run.... Choose endpoints on the script's platform, enter parameter values, and select Run on [number] endpoints. You can also select endpoints in the Endpoints list and choose Run Script. Runs appear in Run History. See Script Automation for scheduled runs and Endpoint Checks for remediation.

Run history and output

Select Run History in the Script Library, or open a script and select Run History, to review runs. A run records its script and version, endpoint, source, initiator, start time, duration, status, and exit code when available. Expand a run to see its arguments and output. Secret parameter values are never displayed; history indicates whether each was set.

Output shown in Run History is capped at 64 KB for standard output and 16 KB for standard error. When output is longer, the beginning and end are shown and the full byte count is reported. The endpoint keeps the full output, up to 2 MB, for the last 5 runs of each script. Stored output is removed after 90 days; run details remain. Select a queued or running row and choose Halt script to ask the endpoint to stop it. The run history reports whether the endpoint confirmed the stop or the script ended before the halt arrived.

Permissions

Six permissions in the Scripts category control what a user can do. Set them on a role in Settings > Roles.

Permission	What it allows
View Scripts	View the Script Library, automations, and run history
View Script Output	Read the output captured from script runs
Manage Scripts	Create, edit, submit, and archive scripts
Approve Scripts	Approve or reject script versions and, when required, automation changes
Run Scripts	Run approved scripts on demand, cancel runs, and resume paused automations
Automate Scripts	Create and change automations and remediation links, and pause all automations

The Administrator role holds all six. The Policy Manager role holds View Scripts, View Script Output, and Run Scripts. The Standard User role holds View Scripts. Without View Script Output, Run History shows Output hidden in place of the output. Running, approving, and changing scripts also asks you to confirm your identity.

Allow-listing

The Allow-listing section in the script editor shows the script file path, the TridentStack Control process that launches it, the process chain, interpreter, and command line. Select Copy for your security team to copy these details. The paths and command lines are generated for the script's platform, language, and name. An approved version also shows its SHA-256 hash; the hash changes with each approved version.

For reference, <slug> is the script's fixed folder and file name, derived from the name when the script is created. The generated script paths are:

• Windows PowerShell 5.1, PowerShell 7, or Batch: C:\ProgramData\TridentStack Control\Scripts\<slug>\<slug>.ps1 for PowerShell, or C:\ProgramData\TridentStack Control\Scripts\<slug>\<slug>.cmd for Batch.
• Linux or macOS Shell: /var/lib/tridentstack/scripts/<slug>/<slug>.sh.

The parent process is C:\Program Files\TridentStack Control\bin\tridentstack-core.exe on Windows, /opt/tridentstack/bin/tridentstack-agent on Linux, and /usr/local/sbin/tridentstack-agent on macOS. The Allow-listing section shows the full process chain for the selected Run as setting. The command line uses the PowerShell 5.1, PowerShell 7, or Batch interpreter on Windows, followed by that script's path. On Linux and macOS, the script path is the command line. Use Copy for your security team for the complete command line for your script.

In your security tooling, match the script path, parent process, and command line together. Do not allow-list the whole Scripts directory or the interpreter. A path-and-parent exception without a hash trusts any content written to that path. If your tooling supports hash matching, account for the hash changing with each approved version.

Remote access tools

TridentStack Control detects well-known remote access tools such as AnyDesk, ScreenConnect, and TeamViewer. A tenant administrator must confirm each script version after signing in again. The confirmation reads: "I confirm this remote access tool is installed with the knowledge of the people who use these endpoints."

Until confirmed, a script version cannot run. If a script contains a remote access tool under another name, TridentStack Control blocks it. Name the script after the product it contains, then publish a new version. You can withdraw a confirmation at any time.

Changing parameters on a script in use

You can change a parameter's type, mark it secret or not secret, add a required parameter, or remove one, even while automations and Endpoint Check remediations use the script. When you publish the new version (or submit it for approval), TridentStack Control checks every automation and remediation that uses the script:

• Values that convert are updated for you. Text such as "true" or "false" becomes a true/false value, and text such as "10" becomes a number.
• Removed parameters are cleared from each automation and remediation.
• Values that cannot be carried over are listed in the publish dialog. This covers text that is not a valid true/false value or number, a parameter whose secret setting changed, and a new required parameter. The dialog groups them under each automation and remediation, and Publish stays unavailable until each one has a value.

If your tenant requires a second administrator to approve versions, the values you enter are saved with the version. The approver sees the same list, without secret values, and the values are applied when they approve. If another automation starts using the script before you publish, the dialog shows it and asks for its values. If the automations or remediations using the script change after you submit a version for approval, approval stops with a message asking the approver to reject the version so you can submit it again.

When a security filter blocks a save

TridentStack Control sits behind a web security filter that rejects requests resembling known attacks. A few ordinary shell patterns can trip it, most often a command that follows a semicolon and fetches a URL, such as echo "start"; curl https://example.com/. When that happens, saving or creating the script shows a message that a security filter blocked the request, and nothing is saved.

Put the command on its own line instead and save again:

echo "start"
curl https://example.com/

If the message persists, contact TridentStack support with the reference shown in the message.