Autonomous Security (Preview)

note

API paths that contain tenant keep that word for compatibility. In the product it means your workspace.

If a term is unfamiliar, open the Glossary.

This page is a workspace-facing preview for Dralvia autonomous security capabilities planned for future rollout.

Current status

• Architecture and safety contracts are in progress.
• Workspace-facing autonomous actions are not generally available yet.
• Decision log export is available for audit preview.
• For resilience scope, see Continuous Adversarial Resilience (/docs/tenant/autonomous-resilience).
• For deception scope, see Autonomous Deception (Preview) (/docs/tenant/autonomous-deception).
• For global early-warning scope, see Global Early Warning (Preview) (/docs/tenant/autonomous-global-early-warning).
• For trusted federation scope, see Trusted Federation (Preview) (/docs/tenant/autonomous-trusted-federation).

Platform release note:

• autonomous security release gates treat High/Critical dependency findings as blocked unless they are either patched or explicitly time-boxed in the platform hardening policy, so scheduled release pipelines can stop when an accepted exception expires or a new advisory appears

Workspace readiness snapshot

Recent platform releases delivered the workspace-facing readiness baseline:

• #/autonomous-readiness for module toggles and readiness probes
• #/risk-economics for business-impact based autonomous planning
• decision log + compliance export preview endpoints for audit workflows

Architecture at a glance

Autonomous workflows run through a guarded pipeline:

1. Policy check (default-deny + workspace scope checks)
2. Workflow orchestration with idempotency and bounded retries
3. Action execution with rollback support for reversible actions
4. Immutable decision log append
5. EvidencePack (Dralvia's exportable evidence report) generation + verification metadata

This is why you may see workflows pause in pending_approval for high-risk actions.

What to expect when enabled

• Explicit policy guardrails (default deny + workspace isolation)
• Auditable decision envelopes with confidence, evidence, and rollback metadata
• Staged rollouts with human override controls

Decision log export (preview)

If your workspace has autonomous decisions enabled, you can request an export from:

• GET /api/autonomous/decision-log/export?format=json
• GET /api/autonomous/decision-log/export?format=ndjson

Notes:

• Export is workspace-scoped.
• Hash-chain verification is available via GET /api/autonomous/decision-log/verify.

Compliance export (preview)

Workspace admins can export autonomous compliance evidence directly:

• GET /api/autonomous/compliance/matrix?window_days=30
• GET /api/autonomous/compliance/export?format=json&window_days=30
• GET /api/autonomous/compliance/export?format=csv&window_days=30

What is included automatically:

• workflow run IDs and status/timestamps
• decision IDs
• EvidencePack IDs/hashes
• transparency indexes
• adversary model ID/version (for model-driven workflows)
• business-impact marker (has_business_impact) when risk-economics is attached
• deception workflow marker (deception_workflow) for deception-mesh workflow rows
• systemic workflow marker (systemic_workflow) for systemic-anomaly response workflow rows
• crisis workflow marker (crisis_workflow) for crisis-coordination workflow rows
• federation workflow marker (federation_workflow) for trusted-federation policy-exchange workflow rows
• deception evidence snapshot in matrix/export JSON:
  • topology_present
  • mesh_state_present
  • feedback_events_window
  • deception_workflows_window
• systemic evidence snapshot in matrix/export JSON:
  • snapshot_present
  • detector_runs_window
  • systemic_workflows_window
  • workflow_memory_entries_window
  • simulation_reports_window
  • performance_profiles_window
• crisis evidence snapshot in matrix/export JSON:
  • registry_present
  • coalition_entries_window
  • incident_entries_window
  • crisis_workflows_window
  • workflow_memory_entries_window
  • simulation_reports_window
  • performance_profiles_window
• federation evidence snapshot in matrix/export JSON:
  • registry_present
  • partner_entries_window
  • intent_entries_window
  • federation_workflows_window
  • workflow_memory_entries_window
  • simulation_reports_window
  • performance_profiles_window

Optional query parameters:

• window_days: lookback window (1..3650)
• framework: comma-separated framework filter (for control matrix/export summaries)
• legacy compatibility: days is accepted as an alias for window_days

Workspace readiness UX (preview)

In the workspace console you can manage readiness from:

• #/autonomous-readiness

This page lets you:

• enable/disable autonomous modules for your workspace
• view recent autonomous workflow actions
• view recent autonomous audit chain entries
• view readiness summary counters (modules enabled, workflow/audit volumes, pending approvals)
• run a deception readiness probe for deception-mesh validation
• run a systemic readiness probe for Global Early Warning validation (safe synthetic signals)
• run a crisis readiness probe for crisis-coordination validation (coalition/incident + simulation/performance + optional workflow)
• run a federation readiness probe for trusted-federation validation (partner/intent + simulation/performance/security + optional workflow)
• view deception readiness telemetry (deception_readiness) for topology/mesh/feedback/workflow health
• view systemic readiness telemetry (systemic_readiness) for snapshot/simulation/profile health
• view crisis readiness telemetry (crisis_readiness) for incident/coalition/workflow-memory and quality/scale posture
• view federation readiness telemetry (federation_readiness) for registry/memory/simulation/performance/security/scale posture

Readiness APIs:

• GET /api/autonomous/tenant-readiness
• POST /api/autonomous/tenant-readiness/modules/<module_key>
• POST /api/autonomous/tenant-readiness/probe

Optional query parameters for GET /api/autonomous/tenant-readiness:

• actions_limit (default 20, max 100)
• audits_limit (default 20, max 100)
• support_errors_limit (default 5, max 20)

Populate the page:

1. Open #/autonomous-readiness.
2. Click Run probe (safe, no-impact). This calls POST /api/autonomous/tenant-readiness/probe.
3. (Optional) Click Run deception probe to start a deception workflow readiness check (profile=deception).
4. (Optional) Click Run systemic probe to seed Global Early Warning readiness assets (profile=systemic).
5. (Optional) Click Run crisis probe to seed crisis-coordination readiness assets (profile=crisis).
6. (Optional) Click Run federation probe to seed trusted-federation readiness assets (profile=federation).
7. Click Refresh (or wait a few seconds) to see the action/audit and readiness snapshots update.

Deception probe note:

• profile=deception requires a configured deception topology for your workspace.
• If missing, API returns deception_topology_nodes_required.

Crisis probe note:

• profile=crisis creates workspace-scoped probe coalition/incident assets and can run simulation/performance/workflow checks.
• Safe flags for low-impact checks:
  • run_workflow=false
  • run_simulation=false
  • run_performance_profile=false

Federation probe note:

• profile=federation creates workspace-scoped probe partner/intent assets and can run simulation/performance/security/workflow checks.
• Safe flags for low-impact checks:
  • run_workflow=false
  • run_simulation=false
  • run_performance_profile=false
  • run_security_posture=false

If you see an error like "Unable to load workspace readiness":

• confirm you are signed in
• hard refresh once, then retry Refresh
• if it persists, contact support with the browser console error and timestamp

Risk economics (preview)

Workspace admins can map incident severity to business impact and auto-plan response:

• UI route: #/risk-economics
• Profile API: GET/POST /api/autonomous/risk-economics/profile
• Estimate API: POST /api/autonomous/risk-economics/estimate
• Plan API: POST /api/autonomous/risk-economics/plan

What this provides:

• estimated impact cost in EUR (estimated_cost_eur)
• SLA breach likelihood (sla_breach_risk)
• recommended response urgency (recommended_priority)
• playbook/action recommendations for automated workflows

Typical flow:

1. Save your business profile (revenue/SLO/multiplier).
2. Run impact estimate for your incident signal.
3. Compute a recommended plan.
4. Start workflow with auto_plan: true for zero-touch execution under approval guardrails.

Adversary model store (preview)

Workspace admins can manage versioned adversary profiles that map tactics to detections and counter-actions.

• UI route: #/adversary-models
• UI sections:
  • Overview: model inventory, latest version, workflow capacity, and quality snapshot
  • Author: immutable model version authoring plus latest model reference
  • Workflow: workflow start, quota, counter-strategy generation, approval, rollback, and EvidencePack actions
  • Quality: model drift and quality monitoring
  • Simulation: deterministic simulation harness checks
  • Deception: deception recovery, performance, security posture, feedback-loop, and scale checks
  • Healing: adversary-model workflow recovery and performance profiling
  • Versions: recent immutable versions
• APIs:
  • GET /api/autonomous/adversary-models
  • GET /api/autonomous/adversary-models/latest
  • POST /api/autonomous/adversary-models
  • POST /api/autonomous/adversary-models/start-workflow
  • POST /api/autonomous/adversary-models/self-heal/reconcile
  • POST /api/autonomous/adversary-models/performance-profile
  • POST /api/autonomous/adversary-models/counter-strategies/generate
  • GET /api/autonomous/adversary-models/quality-monitor
  • POST /api/autonomous/simulation-harness/run
  • GET /api/autonomous/workflows/quota
  • GET /api/autonomous/contracts/adversary-models

What this provides:

• immutable model versioning (model_id:vN)
• workspace-scoped read/write behavior with cross-workspace deny
• optional model confidence (0.0..1.0) with confidence band in responses

Typical flow:

1. Create a baseline model with tactics/detections/counter-actions.
2. Save a new version whenever mappings change.
3. Use latest API (or UI latest card) as the active planning reference.
4. Start a governed workflow directly from the latest model in the Workflow section:
   • UI button: Start workflow from latest model
   • API: POST /api/autonomous/adversary-models/start-workflow
5. Operate workflow lifecycle from the Workflow section:
   • Refresh workflow
   • Approve workflow (second approver required for high-risk actions)
   • Rollback workflow (after success, idempotent)
   • Get EvidencePack (retrieve immutable pack metadata)
   • Verify EvidencePack (signature/hash/inclusion verification)
   • APIs:
     • GET /api/autonomous/workflows/<workflow_id>
     • POST /api/autonomous/workflows/<workflow_id>/approve
     • POST /api/autonomous/workflows/<workflow_id>/rollback
     • GET /api/autonomous/workflows/<workflow_id>/evidencepack
     • GET /api/autonomous/workflows/<workflow_id>/evidencepack/verify
6. If monitoring is enabled, model-workflow failures/latency trigger autonomous alerts through your configured notification channel using the same autonomous alert pipeline.
7. Generate and validate model-derived counter-strategies in the Workflow section:
   • UI buttons: Generate counter-strategies or Generate + promote safest
   • API: POST /api/autonomous/adversary-models/counter-strategies/generate
   • Use promote: true to persist only pass-grade candidates into workspace memory (counter_strategy_generator namespace).
8. Track model drift + quality health:
   • UI section: Quality -> Model drift + quality monitoring in #/adversary-models
   • API: GET /api/autonomous/adversary-models/quality-monitor
   • Use this to detect confidence drift per action before degradation impacts autonomous response quality.
9. Run deterministic simulation harness checks for release confidence:
   • UI section: Simulation -> Simulation harness expansion in #/adversary-models
   • API: POST /api/autonomous/simulation-harness/run
   • Use verify_deterministic: true to validate replay consistency and persist_report: true to keep the latest report in workspace memory (simulation_harness/latest).
10. Reconcile transient failed model workflows:

• UI section: Healing -> Self-healing routines in #/adversary-models
• API: POST /api/autonomous/adversary-models/self-heal/reconcile
• Scope is limited to adversary-model workflows (adversary_response_workflow) to avoid touching unrelated workflow classes.

11. Build model-workflow performance profile:

• UI section: Healing -> Performance profiling in #/adversary-models
• API: POST /api/autonomous/adversary-models/performance-profile
• Use this to review execution/end-to-end p95 against your target and track all_targets_met before rollout decisions.

12. Check workspace workflow quota headroom before higher-volume runs:

• UI section: Workflow -> Scale & multi-workspace load in #/adversary-models
• API: GET /api/autonomous/workflows/quota
• Use this to monitor active_workflows, available_slots, and per-workflow-type load to avoid noisy-neighbor incidents.

Readiness snapshot

Operational readiness for workspaces is considered complete across four layers:

1. Governed autonomy baseline (workflow/approval/audit controls)
2. Business-impact steering (risk economics + auto-plan)
3. Resilience controls (memory/drift/simulation/self-heal/performance/hardening)
4. Scale/readiness closure (quota/DR/compliance/release/supportability/security review)

Workspace-facing routes you should use:

• #/autonomous-readiness for module toggles + readiness probes
• #/risk-economics for business profile, impact estimate, and recommended plan

Workspace APIs you can automate against:

• GET /api/autonomous/tenant-readiness
• POST /api/autonomous/tenant-readiness/modules/<module_key>
• GET /api/autonomous/risk-economics/profile
• POST /api/autonomous/risk-economics/profile
• POST /api/autonomous/risk-economics/estimate
• POST /api/autonomous/risk-economics/plan

Supportability (preview)

If troubleshooting is needed, workspace admins can fetch the autonomous error catalog:

• GET /api/autonomous/support/errors

It returns known error codes and suggested operator actions.

The workspace readiness page (#/autonomous-readiness) also includes a Supportability panel with:

• direct links to workspace-safe readiness, error, and continuity guides in Dralvia Docs
• a top error list (code, surface, operator_action)
• API quick reference to /api/autonomous/support/errors

Attack-path graph (preview)

Workspace admins can generate and query a predictive attack-path graph snapshot:

• POST /api/autonomous/attack-path/graph
• GET /api/autonomous/attack-path/graph
• GET /api/autonomous/contracts/attack-path-graph

What you get:

• graph nodes (assets/identities/roles/services/data stores)
• trust edges (can_reach, can_auth, can_assume, can_read, can_admin)
• ranked top_paths with score, confidence, and evidence
• predictive decision envelope with confidence, evidence, and rollback fields

Notes:

• Graph snapshots are workspace-scoped.
• Cross-workspace reads are blocked by policy.

Pre-incident risk predictor (preview)

Workspace admins can request ranked pre-incident risk predictions:

• POST /api/autonomous/predict/risk
• GET /api/autonomous/predict/risk
• GET /api/autonomous/contracts/preincident-risk-predictor

The response includes:

• ranked prediction list (predictions)
• tracked false_positive_rate_30d
• gated action plan per prediction (requires_approval for medium/high risk)

Weekly SOC-less report (preview)

Workspace admins can receive a weekly autonomous operations summary generated by the platform:

• low/medium incident volume
• low/medium auto-handled count
• low/medium manual backlog status
• high-risk pending approval count

Report artifacts are generated by autonomous weekly report automation and can be shared in operations reviews.

Workflow orchestration (preview)

Workspace-scoped workflow endpoints are available for controlled rollouts:

• POST /api/autonomous/workflows/start
• GET /api/autonomous/workflows
• GET /api/autonomous/workflows/<workflow_id>
• POST /api/autonomous/workflows/<workflow_id>/approve
• POST /api/autonomous/workflows/<workflow_id>/retry
• POST /api/autonomous/workflows/<workflow_id>/rollback
• GET /api/autonomous/action-state
• GET /api/autonomous/workflows/<workflow_id>/evidencepack
• GET /api/autonomous/workflows/<workflow_id>/evidencepack/verify

Controls:

• Idempotency key prevents duplicate workflow creation.
• Retry attempts are bounded to avoid runaway loops.
• Workflow completion writes to the workspace decision log.
• High-risk actions pause in pending_approval until a second approver confirms them.
• Rollback restores prior resource state snapshots and writes a rollback audit entry.
• Successful workflows auto-generate signed EvidencePacks with immutable IDs and transparency proofs.
• Workflow list queries are workspace-scoped and support queue filters (status, approval_state).
• Failed transient workflows can be auto-recovered by platform self-heal routines with MTTR tracking.

Playbook library (preview)

Workspace admins can manage versioned autonomous playbooks and test them in dry-run mode.

Endpoints:

• GET /api/autonomous/playbooks/starter (starter catalog, 10+ templates)
• GET /api/autonomous/playbooks (workspace-scoped versions)
• POST /api/autonomous/playbooks (create next version)
• POST /api/autonomous/playbooks/dry-run (simulate execution without side effects)

Current status values you can expect in workflow responses:

• queued
• running
• pending_approval
• succeeded
• failed
• rolled_back

Reversible actions (preview)

Autonomous workflows support reversible action-state handling for:

• host isolation flows (host.isolate)
• identity/session revoke flows (identity.token.revoke, identity.session.revoke)
• SWG/domain block flows (swg.domain.block)

What each one does today. Be clear about this before you build a workflow on it, because the actions are at different stages:

Action	What happens when the workflow runs
identity.token.revoke / identity.session.revoke	The session is really revoked at the identity provider, the same way the manual revoke control does it. The result is recorded honestly: revoked when the provider confirmed it, simulated when the provider call did not succeed, and no_session when the workflow gave no session to revoke.
host.isolate	Records the intended isolation state and makes it reversible. It does not yet cut the endpoint off the network.
swg.domain.block	Records the intended block state and makes it reversible. It does not yet change your live web access policy.

Treat the second and third as intent-and-audit today. Use the workspace controls in Web Access Protection and EDR to apply those changes, and drive automation from the revoke flow while the others catch up.

You can inspect state with:

• GET /api/autonomous/action-state?resource_type=<type>&resource_id=<id>

A revoke also appears in your Security Activity timeline under the response surface, with the outcome attached, so an automated revoke and an analyst's manual revoke read the same way.

No manual tuning is required for workspaces at this stage.

Long-term memory store (preview)

Workspaces can persist workflow memory in a strict workspace-scoped store.

Endpoints:

• POST /api/autonomous/memory
• GET /api/autonomous/memory
• GET /api/autonomous/memory/<namespace>/<memory_key>
• POST /api/autonomous/memory/prune
• GET /api/autonomous/memory/summary
• GET /api/autonomous/contracts/memory-store

UI route:

• #/autonomous-memory

Example write payload:

{
  "namespace": "policy",
  "memory_key": "blocklist:v1",
  "value": { "domains": ["evil.example"] },
  "ttl_days": 30
}

Notes:

• Data is isolated per workspace; cross-workspace access is blocked.
• Use ttl_days (or expires_at) to control retention.
• Expired entries are hidden by default and can be removed with prune.
• Summary provides active vs expired counts per namespace.
• The UI console supports filter + prune + write flows for operators who prefer GUI.

Who this is for

This guide is for workspace owners, workspace admins, and security operators who need clear, repeatable steps without support intervention for day-to-day execution.

Role-based start here

• Workspace Owner: Start with Before you start, then complete Step-by-step and Known limits and rate limits.
• Workspace Admin: Focus on Step-by-step, What each button does, and API and automation.
• Security Analyst: Start at Day-2 operations and Troubleshooting, then use API error quick reference.
• Integrator/Engineer: Start at API and automation, then validate with Step-by-step and FAQ.

Before you start

Use this short checklist before making changes:

1. Confirm you are signed into the correct workspace account.
2. Confirm your role includes the permissions needed for this page.
3. Confirm your browser session is fresh (if pages behave unexpectedly, sign out/in once).
4. Confirm required prerequisites (API keys, agent enrollment, license, upstream integrations) are already in place.

Step-by-step

Follow this sequence for predictable results:

1. Open the workspace from the workspace menu.
2. Review current status/health/last update indicators before making changes.
3. Apply one change at a time and save.
4. Run the available validate/probe/refresh action.
5. Confirm the expected output appears (status change, new event, successful result).
6. If behavior is not as expected, use Troubleshooting below before repeating actions.

Day-2 operations

After initial setup, keep this surface healthy with a simple routine:

1. Daily: verify data freshness and error banners.
2. Weekly: review trends, limits, and failed actions.
3. Monthly: review permissions, keys/tokens, and stale entities.
4. After any incident: capture evidence and update your internal operating notes.

What each button does

Button labels can vary by module, but behavior is consistent:

• Refresh: reloads the latest data from backend APIs without changing configuration.
• Save: persists workspace-scoped configuration changes.
• Run/Probe/Validate: executes a non-destructive health or verification action.
• Download: fetches workspace-scoped artifact(s) (for example bundle, checksum, signature, or report).
• Verify: checks integrity/consistency and returns pass/fail details.
• Enable/Disable: toggles module behavior for your workspace; audit evidence should be recorded.

If a button appears disabled, check role permissions, required fields, and workspace license/feature entitlement first.

Self-check playbook

Use this 5-step isolation flow before escalating:

1. Configuration: confirm required inputs are present and formatted correctly.
2. Permission: confirm your role can perform the action (401/403 usually indicates authz/authn mismatch).
3. License/feature: confirm the feature is enabled for your workspace plan and module toggles.
4. Quota/rate limit: check for 429 responses and cooldown windows.
5. Service health: if you see 5xx, retry once after 30-60 seconds and capture exact error text.

If still failing, escalate with workspace ID, UTC timestamp, route, action, payload shape (no secrets), and screenshot/error response.

Troubleshooting

Use this quick triage order to reduce time-to-fix:

1. Auth/session: refresh token by signing out/in.
2. Workspace context: confirm you are in the correct workspace.
3. Inputs/config: verify required fields and formats.
4. Quota/license: confirm limits and feature entitlement.
5. Service health: retry after short delay if backend is transiently degraded.

For escalation, include workspace ID, timestamp (UTC), route name, action attempted, and full error message.

API and automation

Everything in this page should remain workspace-scoped. If your team prefers automation, use the corresponding API endpoints with the same guardrails as the UI:

• Use authenticated requests bound to your workspace context.
• Use idempotency/retry controls where available.
• Validate outcomes in the UI after automated runs.

If your endpoint mapping is not obvious, start from Help Center and follow the linked API docs.

Next best actions

After finishing this page, continue with related workflows so your workspace setup stays end-to-end complete:

• EDR response and host actions
• Web Access Protection and dry-run events
• Identity risk and OAuth response
• EvidencePack verification and transparency log
• Risk economics and plan recommendation

FAQ

Q: I clicked save but nothing changed. A: Refresh once, confirm permissions, and verify required fields.

Q: Why do I see missing API key/unauthorized errors? A: Confirm your workspace API key/session is valid and mapped to the correct workspace scope.

Q: Can non-admin users use this page? A: Usually read-only access is possible; write actions require workspace-admin or equivalent roles.

Next steps

After finishing this guide:

1. Validate the result in the related dashboard/workspace.
2. Export or capture evidence if this affects compliance/incident operations.
3. Share the same runbook internally so other operators follow identical steps.
4. Return to Help Center for adjacent workflows.

API error quick reference

Use this matrix when a UI action fails with an HTTP/API error.

Error	Meaning	What to do now
401 Unauthorized	Session token is missing/expired or request is not authenticated.	Sign out/in, refresh once, then retry. Confirm your session is active in the correct workspace.
403 Forbidden	You are authenticated but your role is not allowed to perform this action.	Confirm your role includes the required permission for this button/action. Ask workspace admin to grant access.
404 Not Found	The route/resource does not exist in current workspace context (or feature not enabled).	Confirm URL/route, workspace context, and feature availability. Refresh and retry; if persistent, capture timestamp and route and contact support.
429 Too Many Requests	Rate limit/quota window was exceeded.	Wait for cooldown/reset window, retry once, then reduce burst traffic/backoff if automated.
500 Internal Server Error	Backend failed unexpectedly while processing the request.	Retry after 30-60 seconds. If still failing, escalate with workspace ID, UTC time, route, action, and full error text.

Known limits and rate limits

These limits can vary by plan and feature, but behavior is consistent:

• Burst traffic can trigger 429 Too Many Requests.
• Workspace quotas apply per feature/module and reset on configured windows.
• Repeated retries without backoff can extend recovery time during saturation.

Recommended operator behavior:

1. Retry once after cooldown for 429 responses.
2. Use exponential backoff in automation.
3. Monitor usage/quota dashboards for sustained high utilization.
4. Request quota review when normal workload regularly approaches limits.