Loading documentation…
Orithos workflows let you chain security scans, deployment gates, guardrail generation, Jira sync, and team notifications into automated pipelines. Workflows execute via Temporal (primary) with automatic fallback to ARQ.
Defines how the workflow starts. Options:
refs/heads/*).Runs a security scan against an agent using a scan template. The template provides probe selection, depth, and attack suite. Agent ID and optional Connection ID override the template defaults.
Fields:
Evaluates scan results against a deployment threshold. Gate passes if the ratio of (critical + high findings) / total findings is below the threshold.
Threshold: A value between 0 and 1. Lower values are stricter. Default: 0.7 means the gate fails if more than 70% of findings are critical or high.
Generates guardrail constraints from scan findings. Calls the guardrail generator which produces structured rules and constraints that can be applied to the agent configuration.
Min Severity: Only findings at or above this severity are addressed (critical, high, medium, or low).
Syncs findings to Jira as issues. Configure Jira via Settings > Integrations > Jira.
Two modes:
Creates a GitHub pull request with guardrail changes. Uses the GitHub OAuth token from the GitHub integration settings (Connect with GitHub OAuth under Integrations > GitHub). The token must have repo scope.
Sends a notification to all configured channels (Slack, Teams, Discord). Configure channels via Settings > Integrations > Notifications.
Fields:
Insert dropdown to add dynamic fields from scan results.Fires an HTTP POST to an arbitrary URL with scan completion results. Use for custom integrations that do not have a dedicated node.
When configuring the Notify node, available dynamic fields:
| Field | Description | Example |
|---|---|---|
| {{ step.0.findings_count }} | Total number of findings | 12 |
| {{ step.0.critical_count }} | Critical severity findings | 3 |
| {{ step.0.high_count }} | High severity findings | 5 |
| {{ step.0.medium_count }} | Medium severity findings | 3 |
| {{ step.0.low_count }} | Low severity findings | 1 |
| {{ step.0.highest_severity }} | Highest severity found | critical |
| {{ step.0.scan_run_id }} | The scan run ID | abc123 |
| {{ step.0.jira_key }} | Jira issue key (from Jira Sync step) | PROJ-42 |
| {{ step.0.status }} | Step status | completed |
1. User clicks Execute on the workflow detail page
2. API tries Temporal first — builds a SecurityScanConfig from the workflow definition
3. If Temporal is unreachable, falls back to ARQ (basic step execution: scan → jira_sync → notify_channels)
4. Temporal executes all steps sequentially with retry and timeout policies:
scan → gate → jira_sync (if fail)
→ remediate (if fail + auto_fix)
→ notify_channels
→ webhook (if configured)5. Results are stored in workflow_runs and visible on the workflow detail page