Security architecture, written for your vendor questionnaire.

01 · Overview

Orkena is a governed agent runtime sold to regulated institutions. The security model is built around four commitments: per-tenant isolation enforced by the database itself, envelope encryption under customer-held keys, egress control on code execution, and a tamper-evident record of every authorization decision. This page answers the standard vendor-security questionnaire sections in order, and it says explicitly where the answer is a roadmap item rather than a shipped control. Where a question needs a formal document — a signed DPA, a control-mapping detail, a completed questionnaire — the contact is info@orkena.com.

A fixed rule governs this page: nothing here claims a certification not held. Where a framework is relevant, the language is control-mapping and readiness, never compliance.

02 · Architecture at a glance

Orkena runs as a single Helm chart in one of two self-hosted modes today: customer VPC, or air-gapped; a managed (SaaS, region-pinned) tier is on the roadmap (2027). In every mode the security boundary is the same set of network, database and cryptographic controls.

Every workload ships with a NetworkPolicy: deny-unless-allowed egress, and ingress closed everywhere except the documented peer list. Containers run non-root with a read-only root filesystem, capabilities.drop: [ALL] and the runtime-default seccomp profile. Images are pinned by digest, not by tag. Telemetry to Orkena is off by default.

03 · Tenancy model

Multi-tenant isolation is enforced at the database layer, not the application layer. Line by line:

• Row-level security: every row carries a tenant key; Postgres enforces it at the query layer. The application role connects with NOBYPASSRLS, so a missed predicate in application code cannot read across tenants — the query fails closed. Every tenant route requires an explicit permission check; a missing check returns 403, not data.
• Per-tenant hash chain: each tenant's ledger is a separate hash chain. Evidence for one tenant is cryptographically independent of every other tenant; a modification in one cannot affect another.
• Connection pool scoping: pooled connections are tenant-scoped; no cross-tenant connection reuse.
• Schema isolation in air-gap/VPC: single-tenant deployments use dedicated schemas with no shared tables.

This is tested, not asserted: a 36-case RLS suite plus a live scanner that checks every SQL statement in the codebase against the RLS posture run in CI, and a tenancy fuzz suite sends foreign-org identifiers against every tenant route expecting uniform 403/404.

04 · Encryption

• At rest — envelope encryption: data keys are generated per tenant, wrapped by a key encryption key under your KMS (AWS KMS, GCP KMS, Azure Key Vault, or HashiCorp Vault). Orkena never stores your KEK; the wrapped key is useless without your KMS.
• In transit: TLS 1.3 everywhere, including internal service calls between workloads in the cluster.
• Key rotation: data keys rotate on a configurable schedule; re-wrapping is supported without tenant downtime.
• Key material at end of contract: destroyed under your KMS control — Orkena holds nothing that survives the key's destruction.

05 · Credential handling

Customer-provided secrets — LLM provider keys, downstream tool credentials — are stored encrypted under the tenant envelope, are scoped to the specific agent and tool that needs them, and rotate on schedule or on revocation. Each agent is its own principal with scoped credentials; there is no shared key across agents, so a compromised agent cannot present another agent's identity. Credential use is itself a policy decision, evaluated before every use.

Secrets do not leak into output or logs: values passed into code execution are registered with a scrubbing layer that redacts them from captured stdout/stderr, then zeroizes the registration at call end. A canary-sink test suite proves a planted secret never reaches structured, JSON or raw log sinks. Session tokens are short-TTL RS256 JWTs; refresh is delegated to your identity provider. Rate limits (a leaky-bucket per key and per org) sit in front of the API.

06 · Sandbox for code execution

Agent tool code is untrusted input. The sandbox service is a pure executor — no database, no tenancy surface — that fails closed against four threats: host compromise, network abuse, resource exhaustion, and secret exfiltration.

Isolation, by deployment:

• Production: the sandbox workload carries a configurable runtimeClassName; operators set it to a gVisor or Firecracker runtime class on the sandbox node pool. A NetworkPolicy denies all egress except the object store (for artifact handoff) and the CIDRs the operator declares. With an empty allowlist, guest code has no network at all.
• Container backend (dev/staging, host runners): hardened docker flags — --network=none --read-only --cap-drop ALL --no-new-privileges --pids-limit 64, memory limit, non-root user.
• Local backend (CI): a subprocess in a rebuilt environment under a per-run tmpfs root; the client fails closed — if the sandbox service is unreachable, execution raises SANDBOX_UNAVAILABLE rather than running unsandboxed.

Enforcement layers, every backend:

• Egress guard, deny-by-default: python guests run with an injected guard replacing socket construction; any connect outside the request's allowlist raises, and the service maps it to SANDBOX_EGRESS_BLOCKED. Non-python runtimes have no in-process guard, so the local backend refuses them outright — fail-closed, never a warning. Production enforcement for those runtimes is the container isolation and NetworkPolicy above.
• Resource limits: a hard timeout watchdog that kills the process tree, a memory cap (RLIMIT_AS), a 1 MiB stdout/stderr cap, and a pids limit. Requests above the service maximum are rejected with 422 before execution.
• Workdir confinement: the guest's working directory sits under a per-run scratch root that is destroyed after the run; escape payloads land inside a directory that no longer exists.
• Secret scrubbing: credentials and env_vars passed to the guest are redacted from captured output and zeroized at call end.
• Artifact handoff: files the guest writes are collected before teardown and handed to the object store by reference; object lifecycle policy is the operator's.

Escape smoke tests, an egress matrix (urllib, http.client, raw sockets against the allowlist), limit tests and scrubbing tests run in CI on every change.

07 · Prompt-injection containment

Content from untrusted sources — tool results, retrieved documents, inbound mail — is tainted at the point of ingestion. Taint is a provenance marker, not a verdict: it propagates through model calls and transforms, so anything derived from untrusted content stays tainted no matter how many steps later it appears. Any irreversible action derived from tainted content is denied by default and routed to human approval, independently of whether an injection classifier detected it. Classifiers are a detection layer; provenance is the control. The policy that fires is plain Cedar, readable by your security team:

forbid (action in [Action::"invoke_tool"]) when {
  resource.side_effects == "irreversible" && context.tainted
};

08 · SDLC

• Review and change discipline: code review required on every change; no self-merge; migrations reviewed and traceable; one task, one commit.
• Dependency gates, every PR: uv audit against the OSV database fails on any finding in the Python lockfile; npm audit fails on any HIGH/CRITICAL advisory outside a documented allowlist. One allowlist entry exists today — a react-router advisory with no fixed release in the shipped major, on a code path the application does not exercise; it carries a review date and is removed on upgrade. Every other exception requires a new documented row.
• Image scanning: trivy scans every built image at CRITICAL/HIGH; any fixable advisory fails the build. Results upload as SARIF.
• SBOM and signing: every image is signed with cosign and ships with an SPDX SBOM generated by syft at build time, pinning every package layer. Operators can re-verify the signature and regenerate the SBOM from an image they hold.
• Base image posture: digest-pinned bases (python:3.12-slim@sha256:…); non-root user 10001; read-only root filesystem at runtime. A distroless runtime base is a tracked hardening item, not a shipped claim.
• Truth-floor verification: every tech-name claim in the product is verified against the repository before it ships to the site. Claims that do not map to an import do not ship.

09 · Access controls

• Customer access: SSO (SAML / OIDC) with mandatory MFA; role-based access inside each org; high-impact approvals carry quorum rules and conflict-of-interest blocks (self-approval and same-team approvals are structurally rejected).
• Orkena staff: principle of least privilege; no standing access to tenant data; break-glass access exists under dual control and full audit. In VPC and air-gap modes, Orkena staff operate nothing in your environment at all.
• Known gap, stated plainly: WebAuthn step-up for high-impact approvals is on the roadmap; the compensating control today is the four-eyes approval gate above. High-impact approvals are documented as such in the readiness assessment.

10 · Logging and monitoring

The runtime ledger logs every authorization, execution, approval and administrative action — that is the product's evidence surface, and it is tamper-evident by construction: hash-chained, with Ed25519 anchors taken periodically. The ledger is not a log file; it is the record a regulator or auditor can verify offline.

Operational logs (access, infrastructure) are separate from the ledger, retention-limited, and access-controlled. SLO dashboards track error budgets; alerts have defined owners and a breach runbook. Telemetry to Orkena is opt-in and disabled by default in VPC and air-gap modes.

11 · Vulnerability disclosure

Report to info@orkena.com. Do not open a public issue for a live vulnerability.

Reporters are credited unless they prefer anonymity and are included in the coordinated-disclosure process. Safe harbour: researchers acting in good faith — no testing against production instances, no access to data they do not own, no destructive or denial-of-service testing, stopping and reporting as soon as the issue is demonstrated — will not face legal action for the research. Orkena is pre-1.0: only the latest release line is supported, and no LTS commitment exists yet.

12 · Incident response

Incident classification follows the DORA-style criteria — affected customers, duration, geographical spread, data loss severity, criticality of affected services, economic impact — and the platform produces the evidence for each criterion: SLO burn snapshots, ledger volumes per org, region cells, chain-verification results. Notification commitments, from the point an incident is classified:

Communication runs through the designated security contact. Post-mortems are written and shared; findings feed back into the SDLC. In VPC and air-gap modes, Orkena has no access to your environment — your team runs the incident process with software-level support, and the ledger gives you the immutable record of everything the runtime did. The runbooks the platform is designed around — kill switch, SLO breach, backup/restore, DR, game-day rehearsal — follow the same structure your DORA reporting will ask for.

13 · Sub-processors

See the trust centre for the current list, purposes, regions and DPA commitments. The register is maintained DORA-style: every sub-processor is listed with its function, and changes are notified 30 days in advance with a right to object. Air-gap deployments use zero sub-processors by construction — the bundle ships everything needed to run.

14 · Data retention and deletion

Default retention is customer-configurable. At end of contract, a full export is available — evidence bundles are yours, always, and verify without any Orkena service in the loop — after which data is hard-deleted per a documented deletion process with written confirmation. Cryptographic key material is destroyed under your KMS control; once the key is destroyed, the wrapped data keys are unrecoverable by anyone, including Orkena.

15 · Business continuity

Managed tier (roadmap, 2027): three-region high availability, validated in a controlled test environment; RPO/RTO commitments will be documented in the DPA rather than asserted on a page. VPC and air-gap modes inherit your infrastructure's continuity posture — the software is designed so runs resume from checkpoint after failure, and the backup/restore and DR drills are documented runbooks your team can execute (restore → migrate → ledger re-verification, proving the chain survived the restore).

16 · Certifications and attestations

The honest register: no external audit has yet been completed against SOC 2, ISO 27001, or any other framework. What exists and what is planned:

• SOC 2 readiness is in progress; an audit engagement is planned. A Type I readiness assessment maps controls to the Trust Service Criteria (Security + Availability + Confidentiality) with test-backed evidence — RLS suites, scan gates, drill logs — and a Type II observation window is planned to open within 12 months. Design partners receive control-mapping details ahead of the report.
• ASVS L2 self-assessment is maintained against the platform's application-security surface.
• Penetration testing: pen-test-style suites run in CI on every change — cross-tenant access control (RLS bypass), SSRF including DNS rebinding, sandbox escape and egress abuse, secret handling, authN/session, rate-limit bypass, resource exhaustion, supply chain. An external commercial penetration test against the staged deployment is planned before GA, and a clean external report (no critical/high) is a GA entry criterion.
• Controls are mapped to ISO/IEC 42001 and NIST AI RMF. The mappings live in the compliance register.

Nothing on this site claims a certification not held, and nothing will until the attestation exists. This page and /compliance undergo legal review before publication.

17 · Requesting a full SIG / CAIQ

Email info@orkena.com and we will respond within one business day with the current questionnaire pack — control-mapping detail for SOC 2 TSC and ISO 42001, with the evidence references behind each control — or a documented answer to your specific questions.