Automation, integrations and developer tools

Plexicus Automation: triggers, steps and the flow model

Plexicus Automation sits alongside the Validate → Understand → Remediate workflow of Proof-Driven AppSec. It applies your team’s recurring decisions (“fix this now”, “ticket that”, “ask the AppSec lead first”) to every matching finding. Open it from the main left sidebar; the page is titled Automations, and paths in this module start there, such as Automations New automation .

Picture a Critical SQL injection in the login handler of your billing API. A flow can request a remediation pull request, wait for your AppSec lead to approve, open a Jira issue and post an in-app notification. Nothing merges on its own; your team reviews the pull request.

Trigger → Decide → Act → Record

Every flow has four parts:

1. Trigger. One event starts a run. Each flow has exactly one trigger.
2. Decide. Condition steps route the run by severity, finding type, repository or webhook data. Every step also has a success path and an error path.
3. Act. Action steps request a remediation, open a ticket, notify people or call a connected system.
4. Record. Runs are stored with per-step logs, flow changes go to the audit log (module 10), and tickets are linked on the finding’s timeline.

Triggers

Trigger	A run starts when	Notes
New finding	Plexicus creates a finding	Optional filters: Severity, Finding type, Repository ID
Finding enriched	Plexicus adds context to an existing finding	Same optional filters
Finding reopened	A scan detects a finding again after it was resolved	Runs on each reopen, once the earlier run has ended
Webhook	A signed request reaches the flow’s Ingress URL	Covered in lesson 3
Schedule	A cron schedule fires	5-field cron plus a timezone (UTC by default)
Manual	Someone starts the run with Run now	Shown as “Manual only” in the list

To set the trigger, select the Trigger node on the canvas and edit its panel; you don’t drag triggers from the palette. After you save, reopen the trigger panel to check that your filters or schedule were kept, and dry-run the flow before an admin activates it.

Two rules shape finding-event flows. First, a flow runs automatically at most once per finding. The exception is a flow whose trigger is Finding reopened: it runs on every reopen, as long as its earlier run for that finding has ended. A New finding or Finding enriched flow does not run again on a reopen, so build a separate Finding reopened flow to act on reopened findings. Second, Deduplicate by fingerprint groups findings that share a secret fingerprint into the run already in progress, so one leaked API key leads to one rotation instead of five.

Steps

Step	What it does	Required settings
Remediation	Requests an AI remediation, such as a pull request for review (module 7)	Remediation type
Ticket	Opens a ticket with a provider such as Jira	Ticket provider (project key optional)
Notify	Creates an in-app notification	Notification channel, used as the title; message optional
Wait for approval	Pauses the run until someone approves or rejects	Optional approver role and timeout, set in seconds
Condition (if)	Follows the “yes” edge when true, otherwise the “no” edge	Condition
Condition (switch)	Takes the first matching case, or the error edge if none match	Cases
Connector	Calls one capability of a registered integration	Connector type, capability, connector name

Five secret-rotation steps power the Secret rotation template. Notify is in-app only. To reach another system, use a Ticket step or a Connector step that calls an HTTP API integration.

Conditions use restricted JSON logic. This one is meant to match Critical findings:

{ "==": [{ "var": "finding.severity" }, "Critical"] }

Allowed operators: ==, !=, >, <, >=, <=, and, or, not, in and var. You can test finding fields such as severity, type, status and repository_id, and webhook data as trigger.payload.FIELD. Values are compared exactly, including case. Prefer the visual condition builder, and dry-run against a finding you know is Critical before relying on a hand-written condition.

Building flows safely

Plexicus puts several safeguards between an idea and a live flow: disabled drafts, dry runs, admin-only activation, versions and run history.

Three ways to start

Templates. Automations Start from a template offers ready-made flows:

• Auto-remediate + ticket: on a new finding, request an AI remediation, open a Jira ticket and send an in-app notification if a step fails.
• Conditional remediation: High and Critical findings go to automated remediation with a pull request, and everything else becomes a Jira ticket for triage.
• Secret rotation: rotate a leaked secret, store it in HashiCorp Vault, open a draft PR that replaces the hardcoded value with an environment variable, verify the new value by reading it back, wait for admin approval, then promote the PR. Any failure opens a Jira ticket.

Prompt to flow. Automations New from prompt turns a plain-English description of up to 4,000 characters into a draft, using the AI model configured for your organization. For example: “When a critical finding is created, wait for admin approval, then open a Jira ticket.” The draft lists every external system it will reach under This flow will contact:, and nothing is saved until you click Confirm and save draft.

Visual editor. Automations New automation opens three panes: the step palette on the left (Triggers, Logic, Actions and Integrations), the canvas in the middle and the inspector on the right with Config, Last run I/O and Notes tabs. Drag a step onto the canvas or double-click to add one. The inspector marks each step Configured or Incomplete. The current release adds undo and redo and a schedule builder with a next-run preview.

Whichever way you start, you get a disabled draft that does nothing until an admin activates it. Plexicus validates the flow when you save, and problems such as two edges leaving one branch for different targets appear under This flow has validation errors.

Dry runs

A dry run walks the whole flow and simulates every step that would touch an external system. Each step records what it would have done, for example “Would create jira ticket in project SEC”, and secret-like parameters are masked. Dry runs work on drafts, do not count against execution limits and appear in run history with a Dry run badge. Enter a Finding ID in the editor’s top bar and click Dry run. In the current release you can also test schedule and webhook flows without a finding ID.

Activation and versions

Only organization admins can create, edit, activate or delete flows; other users get read-only access and can still read run history.

Activation re-checks every connection the flow uses, including Connector steps and the Ticket step’s provider. If a test fails, you see Activation failed with the failing connector. Depending on your plan, the number of active flows and manual runs may be capped.

Editing an active flow and clicking Save new version creates the next version. Runs in progress stay on the version they started with, and older versions are kept. After saving, check the Status column and activate the new version if it shows Inactive.

Run history, statuses and approvals

Open Automations Edit Runs to see each run’s Automation, Finding, Status and Started time. Expand a row for per-step logs, or use Replay to step through a run with each step’s input and output.

Status	Meaning
Running	Steps are executing
Waiting	Paused at a Wait for approval step
Completed	The flow reached an end, on a success path or a failure path
Failed	The run stopped with an error, or ran longer than the 30-day maximum
Cancelled	The run was stopped before it finished

Waiting runs show Approve, Reject and Cancel. Approve continues on the success path. Reject and a timeout follow the error path. Cancel behaves like Reject: the run continues on the error path. The timeout is set in seconds and defaults to 7 days (604,800 seconds). If the step names an approver role, only users with that role can approve or reject.

Ticketing and outbound integrations

Plexicus connects to other systems in two places: Settings Integrations holds the ticketing connectors behind the Create Ticket button on findings, and the Automation integrations page holds the systems your flows use.

Connect Jira and ServiceNow

Open Settings Integrations Ticket Management , which lists Jira, ServiceNow and Webhook.

Jira has four tabs: Credentials, Stage Configuration, Test Connection and Create Ticket. Credentials asks for an Email Address, an API Token and the Server URL of your Jira Cloud instance, such as company.atlassian.net.

ServiceNow asks for an OAuth Token and your Instance URL, such as https://dev12345.service-now.com. Plexicus raises incidents in state New with category Security. Which connectors you can enable depends on your plan.

Both connectors have two stages that you switch on or off under Stage Configuration:

• Create Issue covers tickets created from findings.
• Pull Request applies when Plexicus opens a remediation pull request. A linked ticket gets a comment with the PR link and is marked in progress. If no ticket is linked yet, Plexicus creates one.

Each stage has a Priority Mapping (by default Jira maps Critical to Highest, and ServiceNow maps Critical to “1 - Critical”) and an optional Field Mapping that fills ticket fields from finding data with placeholders such as %Finding.title%. The stage also offers filter options; try them on a sample finding before you rely on them. Run Test Connection after saving credentials.

Create a ticket from a finding

On a finding’s detail page, the Create Ticket dropdown lists each configured provider. Jira opens a form with Service, Issue Type (Bug, Task, Story, Epic), Project Key and an optional Priority Override. ServiceNow raises the incident straight away using the stage’s mappings. Webhook sends the finding to your configured endpoint.

Plexicus links the ticket’s ID, URL and status to the finding and adds a “ticket created” entry to its timeline. Don’t assume the ticket closes by itself when the finding is resolved; close it through your tracker’s normal workflow.

Outgoing webhooks and automation integrations

The Webhook connector sends findings to an HTTP endpoint you control. Its wizard has four steps: Settings (Webhook Name, Webhook URL, HTTP Method POST or PUT, Data Format), Authentication (None, Basic or Bearer Token), Headers and Preview, where you check the payload and send a test.

The Automation integrations page lists the connected external systems your automations can use: HashiCorp Vault, Kubernetes Secrets, Jira, ServiceNow, Source control, HTTP API and Outgoing webhook. The Credentials reference field holds a pointer to stored credentials, never the secret itself. Each card shows Unverified, Healthy or Unhealthy, and Save and test checks a new integration right away. You can’t delete an integration that a flow still uses.

Signed inbound webhooks

A flow with a Webhook trigger gets its own Ingress URL. In the trigger panel, click Generate new secret and copy it immediately, because it is shown only once. Generating a new secret replaces the old one immediately, so update every caller at the same time. The caller signs the raw request body with HMAC-SHA256 using that secret and sends the hex digest in the X-Plexicus-Signature header as sha256=HEX_DIGEST. The panel includes a ready-made example request. In a shell, the signing step looks like this:

BODY='{"service":"billing-api","event":"deploy"}'
SIG=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$WEBHOOK_SECRET" | awk '{print $NF}')
curl -X POST "$INGRESS_URL" \
  -H "Content-Type: application/json" \
  -H "X-Plexicus-Signature: sha256=$SIG" \
  --data "$BODY"

Sign the exact bytes you send. If the caller re-serializes the JSON after signing, the signature no longer matches.

HTTP response	Recent deliveries label	Meaning
202	Accepted	A new run starts for every accepted delivery
401	Invalid signature	The signature is missing or does not match the body and current secret, or no secret has been generated yet
409	Inactive	The flow is inactive or does not use a Webhook trigger
400	Invalid JSON	The body is not valid JSON
413	Payload too large	The body exceeds the size limit
429	Rate limited	Too many deliveries for the organization

Developer access: API tokens and the REST API

Scripts, CI pipelines and IDE agents all reach Plexicus through tokens. Choosing the right one keeps access traceable and easy to revoke.

Personal API tokens

Go to Settings API Tokens . Enter a Token name, choose an Expiration (30 days, 90 days or No expiration) and click Generate token. The value appears once under “Save your token now”. Copy it, then click I’ve saved it. The Active tokens table lists Name, Created, Expires and Type, with Revoke on each row.

A personal token has no separate scopes. It acts as you, with your role and organization permissions. A token created by a developer can do what that developer can do in the console and nothing more. Revoking a token takes effect immediately, and any later call with it returns 401. Token creation is recorded in the audit log.

Good habits:

• Create one token per tool (a reporting script, your IDE, a CI job) so you can revoke one without breaking the others.
• Prefer a 30- or 90-day expiry. If you choose No expiration, check the Expires column, because a long default lifetime may still apply.

The organization Plexalyzer token

The Plexalyzer token, also called the CI/CD scanner token, belongs to the organization rather than to a person. It authenticates the Plexalyzer scanner in your pipelines. Admins create it, with an optional expiry date, under Settings Plexalyzer Token . In some releases the same token appears as the CI/CD scanner token section of Settings API Tokens . Module 3 covers storing it as the PLEXALYZER_TOKEN CI secret and setting up pipelines.

Plexicus has no organization-level token for general API calls. A script that should outlive one person’s access still needs a personal API token, so choose its owner deliberately, give the token its own name and revoke it when it is no longer needed.

Token	Belongs to	Use it for
Personal API token	You, with your role	Scripts, integrations, the MCP server
CLI token	You, with your role	The Plexicus TUI, created by plexicus login
Plexalyzer token	The organization	The Plexalyzer scanner in CI/CD only

REST API basics

Every request sends Authorization: Bearer followed by your token and Accept: application/json, plus Content-Type: application/json on POST, PUT and PATCH. The SaaS base URL is in the API guide at docs.plexicus.ai; a self-hosted deployment uses its own URL. Resource paths are plural, such as /repositories, /findings, /remediations, /repository-scans and /automations.

curl -H "Authorization: Bearer $PLEXICUS_API_TOKEN" \
     -H "Accept: application/json" \
     "$PLEXICUS_API_URL/findings?filters%5Bseverity%5D=critical,high&limit=25"

Lists use cursor pagination. A response holds items, total and a next link; pass its cursor to get the next page. Most endpoints return 25 items per page by default, and limit changes that.

Long-running actions return 202 and continue in the background. POST /repository-scans with a repository_id and a scan_type of app or sbom starts a scan. POST /remediations with a finding_id requests an AI fix; poll GET /remediations?finding_id=... until it returns the diff and guidance (404 means not ready yet). AI actions draw on your AI usage allowance, shown on Settings Billing and in your profile menu (modules 7 and 10). You can also start a flow through the executions endpoint of /automations, for up to 100 findings per call and optionally as a dry run.

Errors use the RFC 7807 Problem Details format. A 401 means the token is invalid, expired or revoked. A 403 means the token works but your role or your plan does not allow the action. A 429 means you hit a rate limit, so retry with exponential backoff.

Working from the terminal and the IDE

Two developer tools put findings where you already work: the Plexicus TUI in your terminal and the Plexicus MCP server in your IDE.

The Plexicus TUI

Download the binary for macOS Apple Silicon, macOS Intel or Linux x86-64 from the GitHub Releases page of github.com/plexicus/tui. Then:

plexicus --version   # confirm the install
plexicus login       # sign in through your browser
plexicus             # browse findings and connected repositories

On first launch, a setup wizard asks for your Plexicus server URL.

Key	Action
F	Open filters
/	Search
Enter	Open finding details
r	Request AI remediation
p	Create a pull request

Press r, review the diff, and only then press p. The pull request goes through your normal review, and your team keeps merge control.

What plexicus login does

plexicus login opens your browser on the Plexicus authorization page. Sign in if needed, including 2FA if it is on. The page shows “Authorizing Plexicus CLI…” and then “CLI authorized”. Behind the scenes, Plexicus creates a personal API token named CLI - YYYY-MM-DD, valid for 365 days, and your browser hands it to the CLI on a local 127.0.0.1 address. The CLI stores it in ~/.config/plexicus.

Because it is a normal personal token, it appears in Settings API Tokens , where you revoke it. plexicus logout only deletes the local copy. On a headless machine with no browser, generate a personal token and export it as PLEXICUS_API_TOKEN instead.

The Plexicus MCP server

The Plexicus MCP server (package plexicus-mcp) runs locally on your machine and gives an MCP-compatible IDE agent access to the Plexicus REST API with your personal token. The documented clients include Cursor, VS Code, Windsurf and a command-line coding agent. Setup takes three steps:

1. Choose a client.
2. Choose a launch method: uvx plexicus-mcp (recommended), pipx run plexicus-mcp or pip install plexicus-mcp.
3. Configure your token and connect. After you generate a token, the Use with your IDE (MCP) section of the API Tokens page shows pre-filled snippets: a one-line command for command-line clients and a JSON config for Cursor, VS Code and Windsurf.

{
  "mcpServers": {
    "plexicus": {
      "command": "uvx",
      "args": ["plexicus-mcp"],
      "env": {
        "PLEXICUS_API_TOKEN": "YOUR_TOKEN",
        "PLEXICUS_API_URL": "YOUR_API_URL"
      }
    }
  }
}

PLEXICUS_API_TOKEN is required. PLEXICUS_API_URL is optional; it defaults to the SaaS API and is set for self-hosted deployments. With a bad token, tools return “Authentication failed — the API token is invalid, expired or revoked.”

The server exposes 10 tools. Only request_scan and generate_remediation change anything; the rest are read-only.

Tool	Purpose
get_current_repository	Match your workspace’s git remote to a Plexicus repository
list_repositories, get_repository	Browse repositories, severity counts and scan state
list_findings, get_finding	Filter by severity, status, CWE or title, then read details
request_scan, get_scan_status	Start an app or SBOM scan and follow it
generate_remediation, get_remediation	Request an AI fix and fetch its diff and guidance
get_security_posture	Account-wide totals and the riskiest repositories

It also ships three guided prompts (fix_finding, triage_findings, security_review) and two resources: plexicus://repositories and a findings resource per repository. Every tool returns a readable summary plus the raw API data.

Key takeaways

• Every flow has one trigger, steps with success and error paths, and a recorded run. A flow runs once per finding; only a flow with a Finding reopened trigger runs again, on each reopen.
• Flows start as disabled drafts. Dry-run them, have an admin activate them (activation re-tests connections), and read per-step logs, because Completed can include a failed step.
• Jira, ServiceNow and outgoing webhooks live under Settings Integrations Ticket Management . Inbound webhooks must be signed with HMAC-SHA256 using the flow’s current secret.
• Personal API tokens act with your own role; the organization Plexalyzer token is for the scanner only. Use one token per tool and revoke what you don’t use.
• plexicus login creates a revocable personal token for the TUI. The MCP server gives IDE agents 10 tools, and suggested fixes never become pull requests without you.