CoreLayer AI Security Platform logoCoreLayer AI Security Platform

Run all four phases

Execute CSA, ART, DCA, and RTD in lifecycle order from one versioned manifest.

Terminal
secureai run --config secureai.run.yaml

Create the manifest

secureai.run.yaml
version: 1

build:
  target: ./prompts
  config: secureai.config.yaml
  fail_on: high

test:
  target: http://127.0.0.1:8090/v1/chat/completions
  model: proxied-model
  intensity: standard
  concurrency: 4
  rps: 5
  fail_asr: 5

validate:
  - type: rag
    input: ./security/rag.yaml
    fail_below: 70
  - type: guardrail
    input: ./prompts/system.md
    fail_below: 70

runtime:
  - type: lcac
    policy: ./security/lcac-policy.yaml
    context: ./security/context-sample.json
  - type: cbe
    profile: ./security/capability-profile.yaml
    session: ./security/session-sample.json

Start the model proxy first

When ART uses a non-OpenAI provider, start secureai proxy and set test.target to its local Chat Completions URL. See Model proxy.

Execution order

OrderPhaseManifest input
1CSAbuild.target and optional scan settings
2ARTtest.target, model traffic settings, and ASR gate
3DCAEvery RAG or guardrail check in the validate list
4RTDEvery LCAC, LBF, or CBE check in the runtime list

The order is fixed so CSA findings reach ART through the local Intelligence Bus, and runtime checks can consume earlier runtime signals. A manifest must configure every phase. Add more than one DCA or RTD check when the application has several artefacts.

Gate and error behaviour

  • A policy gate failure is recorded and later checks continue. The final process exit code is 1 if any gate failed.
  • Invalid YAML, a missing file, an unavailable endpoint, or another execution error stops the run. The process exits 2.
  • A clean run exits 0.

Credentials

ART still fetches the CoreLayer attack corpus, so run secureai login first. If the ART target itself needs a key, use api_key_env or an env:VARIABLE_NAME header value in the manifest. Do not place a secret directly in committed YAML.

Terminal
test:
  target: https://gateway.example.com/v1/chat/completions
  api_key_env: MODEL_GATEWAY_KEY
  headers:
    X-Tenant-ID: env:MODEL_TENANT_ID

One report for the whole run

--report writes a single document covering every phase that ran: CSA findings by file, the per-category attack success table from ART, DCA domain scores and weak controls, and the RTD policy violations, anomaly scores and capability breaches. The headline score is the weakest phase, not the average, so a strong static scan cannot bury a bad adversarial result.

Terminal
secureai run --report assessment.pdf

The PDF is rendered on your machine by a local Chrome or Chromium. Nothing is uploaded to produce it, so an assessment containing prompt excerpts and attack payloads never leaves the host that generated it. If no browser is found, the HTML is written alongside instead and the run still succeeds — print that to PDF from any browser.

Model responses are withheld by default

The notable-attacks table lists the payloads that succeeded, but not what the model replied, because a successful jailbreak's output can contain whatever the model was induced to emit. Pass store_responses: true in the manifest's test block if you need the replies as evidence, and treat the resulting document accordingly.

Command options

FlagDefaultDescription
--configsecureai.run.yamlLifecycle manifest path.
--reportoffWrite a combined four-phase assessment. A .pdf path is rendered locally and needs Chrome or Chromium installed; a .html path always works.
--formatterminalterminal or json phase output.
--server$SECUREAI_SERVERControl-plane URL inherited by every phase.
--no-uploadoffKeep all phase results local.