Security
Technical reference. This page is for integrations, advanced configuration, or platform operations. For portal tasks, start with the user guide.
Orqestra enforces security at multiple layers: authentication, policy obligations, guardrails, injection detection, and tenant isolation.
Authentication
The runtime-gateway requires a signed, single-use service credential on
/v1/execute and every other guarded route:
Authorization: Bearer <orqestra-service-credential.v1 JWT>The control plane mints this credential per request, binding it to the
calling subject (for example service:control-plane) and to the exact
(method, route) pair the request targets. The runtime-gateway verifies it
against its own dedicated trust root and rejects a repeated jti as a
replay. There is no static bearer token and no local-development fallback:
a missing verification keyset or an unreachable replay store fails the
request closed with 503 in every environment, including local.
Outside local development, runtime execution entrypoints also require the control-plane actor assertion header. The assertion is a short-lived signed JWT bound to the exact route and canonical request body; the runtime rejects replayed assertion IDs before it builds execution identity.
The portal proxy converts httpOnly session cookies into Bearer tokens before forwarding requests to the control plane, which mints the signed service credential on the runtime-gateway leg itself — the portal and its callers never see or supply that credential.
Policy obligations
All 7 obligation types are enforced at runtime:
| Obligation | Timing | Effect |
|---|---|---|
apply_token_budget | Pre (inline) | Limits cumulative token usage |
restrict_knowledge_base_scope | Pre (inline) | Filters allowed knowledge bases |
require_human_review | Pre | Blocks execution, returns approval_required |
use_release | Pre | Validates execution uses the specified release |
use_model_config | Pre | Validates model config matches obligation |
capture_evidence | Post | Warns if no evidence artifacts produced |
redact_or_filter_output | Post | Applies PII redaction to output |
Operator-authored output-redaction rules are bounded at authoring, activation,
and runtime. There can be at most 16 strict rules (512-character patterns and
256-character replacements). The two non-streaming response sinks share one
fixed regex budget; invalid patterns, subject overflow, timeouts, replacement
expansion, or budget exhaustion fail closed to [REDACTED]. The streaming
limitation remains unchanged: already-emitted SSE frames cannot be rewritten
by post-execution enforcement.
Guardrails
Pre-execution guardrails check agent goals and LLM inputs:
- PII detection — email, phone, credit card, SSN patterns with block/redact/mask/flag actions
- Prompt injection — detects “ignore previous instructions”, “DAN mode”, jailbreak patterns
- Topic denial — configurable denied topic list with custom refusal messages
- Custom rules — arbitrary regex patterns with configurable actions
Injection detection hooks
Prebuilt PreToolUse hooks detect injection attacks in tool arguments:
- Command injection — shell chaining, command substitution, banned commands in
code_execution - SQL injection — UNION SELECT, DROP TABLE, tautologies, time-based injection in database tools
- SSRF — private IP ranges, cloud metadata endpoints (169.254.169.254), localhost, DNS-pinned HTTP plugin egress, SMTP host/port egress targets, and bounded runtime egress audit events
Enable via the hooks system.
Audit trail
Every operator action and enforcement decision is recorded in a tamper-evident, hash-chained audit log. See the Audit & Compliance guide for retention defaults, WORM configuration, and verification workflow.
Tenant isolation
Core repositories (Workload, Asset, Release) use TenantScopedRepository
to filter queries by tenant_id. Other data (executions, triggers, memory)
is implicitly scoped through workload_id foreign key chains.
Secret management
The runtime uses a configurable secret resolver controlled by
ORQESTRA_SECRET_BACKEND:
| Backend | Provider |
|---|---|
env (default) | Environment variables |
vault | HashiCorp Vault |
azure_key_vault | Azure Key Vault |
aws_secrets_manager | AWS Secrets Manager |
gcp_secret_manager | GCP Secret Manager |
config | Static configuration |
Vault is supported for local and deployed environments. Cloud deployments can use Vault or their provider-native secret manager, depending on the platform team’s operating model. See Connections & Secrets for secret CRUD, connection bindings, backend configuration, and redaction behavior. On AKS, the Azure Key Vault runtime backend requires workload identity and a complete workspace scope; the runtime refuses bare references and checks the stored scope tags on every read.
Tool permissions
Operators can grant persistent tool access at the workload level:
curl -X POST http://localhost:8000/v1/workloads/{id}/tool-permissions \
-d '{"plugin_slug": "http_request", "granted_by": "operator:alice"}'Prefix matching is supported: http_request:GET:* grants GET-only access.