Threat model

Read this before Deployment if you’re evaluating VectorStep for a security review. That page is the operational reference for getting it running; this one answers “what is trusted, what is exposed, and where does this belong on my network” — the questions a reviewer needs answered before either matters.

What VectorStep is, in security terms

A single-tenant service that receives untrusted webhook input, runs LLM-driven pipelines whose steps can call tools and take real actions, and gates all of that behind a trust vector — verifier results, grounding checks, deterministic checks, calibration history, and readiness policy, none of which is a compliance control, all of which is described on Verifiers and the pages it links to. It is designed for deployment inside a trusted network, fronted by your own authentication and TLS termination where each of those belongs — see Securing a deployment for the concrete steps.

The trust boundaries

Principal	Trusted to	Not trusted to
Webhook sender	Trigger a configured pipeline, supply payload data	Choose which pipeline runs beyond the configured mapping, supply templates or config
viewer	Read runs, prompts, outputs, costs	Change anything
operator	Trigger, rerun, replay, approve gated actions, grade runs	Change pipeline or agent config
admin	Author pipelines, steps, agents, tool policy	— this is the highest privilege; see below
Agent at run time	Call the tools its agent.yaml grants, subject to the Gateway’s tool_policy	Exceed that allowlist
MCP tool server subprocess	Receive its own declared env: values	Read the Gateway’s other secrets

Role definitions and the full route-by-route requirement table live on Security; this table is about trust, not mechanism.

Admin equals host access

This is the single most consequential property of the product, and it does not get a footnote: an admin token is equivalent to a shell on the service host, unless two config keys are both left at their default.

A type: shell deterministic check runs its command through the real shell, inheriting the service process’s own environment and permissions. An unsandboxed Jinja2 template — any prompt_template, expect expression, or templated field in pipeline config — can execute arbitrary Python in-process via the standard attribute-traversal tricks. Both are disabled by default:

security:
  allow_shell_checks: false   # default
  template_sandbox: true      # default

With both at their defaults, pipeline authorship is contained — an admin token can rewrite any pipeline or step, but cannot use that access to reach the host. Set allow_shell_checks: true and that stops being true: writing pipeline config is administering the host, for anyone who holds an admin token, not just for the operator who flipped the key. There is no partial version of this — an operator who needs pipeline authors to be a lower privilege tier than sysadmins must leave both at their default and push local filesystem or CLI-tool access needs through Grounding’s type: webhook deterministic check instead, which reaches anything with an HTTP API (Prometheus, Alertmanager, the Kubernetes API, Jira, ServiceNow, cloud provider APIs) without this tradeoff. See Configuration reference for what enabling either key gives up in the other direction.

What a compromise of each credential yields

Credential	Yields
Webhook token	Trigger configured pipelines, spend the LLM budget those pipelines use, cause any gated action the pipeline already permits
viewer token	Read every prompt and output ever recorded — which may contain whatever the webhook payloads and the tools returned, including production data
operator token	Approve actions a human was meant to gate
admin token	Full control of pipeline and agent behaviour, and host access if allow_shell_checks/template_sandbox are off (above)
Gateway admin token	Rewrite agent definitions and their tool grants — a different credential from VectorStep’s own admin, held by whoever authors agents, not by VectorStep itself
Gateway invoke token	Run agents and read agent definitions — the credential VectorStep’s own executors.gateway.token holds; cannot rewrite anything

Data handling

Run records, prompts, agent traces, tool outputs, and artifacts are persisted in the database and (if configured) the artifact store — see Deployment. Provider API keys and tokens live in environment variables only, resolved via ${VAR} substitution; none are ever written to a database row or a log line intact (see TLS and network defaults for what protects them in transit). Distributed tracing (OpenTelemetry) is disabled by default and only exports run data if you explicitly configure it. Separately, the service and Gateway each send a single anonymous ping on startup — an install identifier, version, OS/arch, and install method, never hostnames, IPs, config, or any data processed by VectorStep — see Anonymous usage reporting for the full payload and how to disable it.

Say this plainly: the database inherits the sensitivity of whatever systems your pipelines touch. A pipeline that triages a payments incident will have payments data in its recorded prompts and outputs. Treat database backups and artifact storage with the same handling requirements as the systems the pipelines were built to observe.

What is not built

No SSO or OIDC — authentication is named tokens in config, not a user system. No rate limiting or account lockout on authentication attempts. No per-team write isolation — any admin token can write any pipeline, regardless of team attribution. No secret-manager integration — secrets are environment variables, resolved by the process, nothing more. No signed or exportable audit log — Security’s audit trail is a database table, not a tamper-evident export. These are tracked, not forgotten — see the project’s own working roadmap for status if you need to know before evaluating further.

No compliance claims

VectorStep is not SOC 2 aligned, not GDPR-assessed, not vetted for any regulated-workload framework — none of that has been evaluated, and nothing on this site should be read as implying otherwise. This page describes mechanisms. Map them to whatever framework your own review requires.