Security & Compliance

This guide is written for the person who has to sign off before Orkestia touches a production cloud account: the platform engineer, the security reviewer, the technical lead doing an evaluation. It explains the actual mechanisms behind Orkestia's security posture and what is available today versus on the roadmap.

The short version: Orkestia is built so that the secure path is the only path. Customer cloud code and data stay in your accounts. Execution of cloud workflows happens there. App Data is the explicit exception: rows of apps that opted into the platform data plane live on Orkestia-managed Postgres, isolated by identity and ownership — not a copy of your cloud warehouse. App Host is the explicit exception for hosting: a claimed site runs on a shared pool you do not kubeconfig. Every tenant is isolated by construction, and everything the platform did for your organization is recoverable as an org-scoped audit trail.

The trust boundary: Zero Code Custody

The single most important architectural fact for an evaluator is where execution happens. Orkestia is an orchestrator and an observability plane. Cloud jobs and provider resources stay in your accounts. If you opt in to App Data or App Host, those apps' rows, the claimed site, and (when Buzz is on) site MinIO including Files run on Orkestia-managed infrastructure with the same identity isolation — still not your git, still not a dump of your cloud data plane.

Cross-account access without static keys

Orkestia reaches into a customer cloud account through a role it assumes, not a key it stores. You create a role in your own account that trusts Orkestia's platform principal, gated by an external ID that the platform supplies. This is the standard AWS confused-deputy mitigation.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "<orkestia-platform-principal>" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "<your-unique-external-id>" }
    }
  }]
}

What this buys an evaluator:

• No long-lived secrets in Orkestia's store. Access is a short-lived STS session, scoped by the role's own permission policy — which you author and can tighten or revoke at any time.
• Revocation is one-sided and instant. Delete the trust relationship in your account and Orkestia can no longer assume the role. There is no credential to rotate or leak.
• Least privilege is yours to set. The blast radius of any Orkestia workflow is the union of the role policies you granted — nothing more.

For DNS-driven flows (custom domains, app enablement) the same delegated-credential principle applies via provider connections — see DNS providers.

Identity & authentication

Orkestia has two distinct identity models, and it's worth keeping them separate when reasoning about security.

Member-account controls (authentication provider, password management, active sessions, account deletion) live under Settings → Security. Authentication is handled by AWS Cognito, so password storage, strength rules, recovery, and MFA are never implemented in application code.

For the apps you expose to end-users via App Enablement, the security guarantees are enforced end to end:

See Identity & multi-tenancy for the full model.

Tenant isolation by construction

Multi-tenant breaches almost always come from a missing filter, not a wrong one. Orkestia's design removes the opportunity to forget.

• Org scope is resolved server-side from the token. When you call the workflow MCP, your organization_uuid is resolved from your authenticated identity — you do not pass it, and you cannot override it. Runs are scoped to your org automatically.
• Scoped data steps bind the tenant filter from identity. A query workflow cannot express "read another org's rows"; the filter is derived, not supplied.
• The audit surface is org-scoped by construction. Cross-org reads are not expressible in the audit query API — a query can only ever return your organization's runs.

Agent Exchange: two orgs, one ledger

Agent Exchange is the sanctioned cross-org channel for hiring Staff actors. It does not punch a hole in tenant isolation.

• Mutations take the party from claims. buyer_organization_uuid / seller_organization_uuid on hire or publish are ignored. You cannot hire "as" another org by stuffing a UUID.
• Dispatch is a grant, not a shared token. An active lease is proven, then the seller-side run is pinned to the seller org under a named system principal.
• Orkestia never holds the funds. Settlement rides the seller's Stripe / AbacatePay / Mercado Pago account. The platform stores contract evidence.
• Seller invoke output is untrusted data. Do not treat it as instructions or render it as a prompt. Payloads stay under the listing DPA.

Operator path: Settlement & trust.

// Conceptual: the caller never supplies the tenant filter.
// It is bound from the verified principal, server-side.
const run = await start_workflow("audit.workflow-run.query", {
  workflow_type_prefixes: ["kubernetes.", "deploy.k8s."],
  state: "terminal",
  // organization_uuid is injected from the token — not a parameter you set
});

The audit log & evidence packs

Every action on Orkestia is a workflow, and every workflow records every state transition. The audit log (the audit.* workflow library) is the typed, read-only query surface over that transition log — so you can answer "what ran for my organization, and what happened?" without writing raw SQL or risking a mutation.

Why this matters for compliance:

• One source of truth. The data already lives in the engine — the audit log exposes it safely instead of copying it into a parallel store that can drift.
• Read-only and side-effect-free. Every audit workflow is a DataWorkflow or read-only Workflow; auditing cannot mutate state.
• Evidence packs. Compose the queries above over a time range or workflow group into a portable artifact you can hand directly to an auditor — answering "prove what the platform did for us" without a screen-scrape.
• Prefix-composed grouping. Ask for "all kubernetes workflows" or "all billing workflows" by passing the prefixes you care about, with no hard-coded filters.

FailGuard — reliability guardrails

FailGuard is the automated error-fix guardrail for production. Connect a GitHub repository and a Sentry project; when production throws an error, FailGuard deduplicates it by fingerprint, indexes the relevant code, and runs the failguard.error-fix workflow that explores, designs, generates, reviews, evaluates — and, within the controls you set, opens a pull request.

Two security-relevant properties: a generated fix is a proposal, not a merge — it lands as a reviewed PR, and the review requirement / confidence threshold are guardrails you control; and because every repair attempt is a workflow run, it is visible to the audit log above. Repair history is workflow-run history.

Mapping to common compliance concerns

The table below maps typical reviewer questions to the mechanism that answers them. It is a map of capabilities, not a certification claim.

Where to go next