How we look after your keys and your data

1. External KMS Envelope Encryption & Key Wrappers

Unlike platforms that store tenant credentials and operational payloads in plaintext, COWE uses an envelope encryption architecture. Each tenant organization has a unique Data Encryption Key (DEK). When you enable an external KMS (implemented via HashiCorp Vault Transit), that DEK is wrapped by a Key Encryption Key that COWE never stores; deployments without an external KMS use a platform-managed key instead.

Data at rest is encrypted with AES-256-GCM (Galois/Counter Mode), and secrets are decrypted only in volatile memory during step execution. Organizations using an external KMS can invoke crypto-shredding — revoking the wrapped DEK so encrypted historical records can no longer be decrypted.

2. Script Sandboxing

A workflow step can run C#, Python or JavaScript that you wrote. None of it executes in the engine. Scripts are handed to a separate sandbox service, so the process holding the master key, your decrypted credentials and the database connection never compiles or runs them. There is one path, not a fast path and a safe one.

That service sits on a network declared internal — no gateway, so it cannot reach the internet or any service not on that network. It runs as an unprivileged user on a read-only root filesystem, with every Linux capability dropped, no-new-privileges set, and hard CPU and memory ceilings. Scripts are cancelled at a fixed timeout, so a runaway loop ends on a clock rather than on someone noticing.

C# is also checked before it runs: a semantic pass over the syntax tree resolves what the code actually refers to and rejects reflection, process and filesystem types and the dynamic keyword — reading the symbols rather than grepping the text, so a name assembled at runtime cannot walk past it.

In Production the API refuses to boot unless the sandbox's address is configured. Without it the engine would fall back to running your script as a subprocess on its own host, beside everything the sandbox exists to keep it away from — so it fails at startup instead of quietly downgrading.

3. Durable, Distributed Execution

Workflows execute on a pull-based worker model over a durable message broker, so throughput scales horizontally by adding worker nodes. Every state transition is persisted to a relational datastore, and a transactional outbox guarantees that a workflow's state change and the message that advances it commit atomically — no dropped or duplicated side effects if a node dies mid-step.

Long-running processes are dehydrated to the database while they wait (timers, human approvals, external webhooks) and rehydrated on wake-up, so a workflow can pause for seconds or months without holding a thread. Database advisory locks and optimistic concurrency keep a single instance consistent even when multiple workers compete for it.

4. Reliable by Design

COWE models the hard parts of real business processes natively. BPMN compensation lets a failed multi-step transaction unwind through explicitly modelled rollback steps in reverse order — reservation released, invoice voided — rather than leaving half-finished state. Steps can declare native retries with backoff for transient failures, and a dead-letter worker captures anything that exhausts its attempts for inspection and replay.

Triggers accept an idempotency key, so a retried "start workflow" call returns the existing run instead of creating a duplicate — safe to call from webhooks and at-least-once message sources.

5. Strict Multi-Tenant Isolation

Every tenant's workflows, definitions, secrets and audit logs are partitioned by organization and enforced with database-level query filters, so one organization can never read or act on another's data. Execution runs in a per-request/per-message scope bound to the owning organization, and connector credentials are decrypted only in volatile memory for the duration of a single step.

6. Enterprise Identity & Provisioning (SSO + SCIM 2.0)

Authentication runs on a dedicated enterprise identity layer. COWE speaks OIDC to it; that layer federates your existing identity provider over OIDC or SAML 2.0, so employees sign in with your corporate identity. Federation is configured with you during onboarding rather than from the portal. On the Enterprise plan, SCIM 2.0 connects directly to Okta, Microsoft Entra ID and other providers to automatically provision and deprovision users. When someone leaves your directory, their COWE access is revoked the same minute — at both the application and identity-provider layers — so off-boarding is never a manual step you can forget.

7. Observability & Operations

The engine emits distributed traces per workflow and per step, operational metrics (active workflows, step latency, outbox throughput, worker health) over standard exporters, and structured JSON logs correlated by instance ID. A visual replay tool lets operators step through any run, inspect variables at each node, and retry or resume from the point of failure — turning production incidents into a few clicks rather than a database surgery.

8. Caching & Distributed Locking

Plan entitlements are read on nearly every request, so they are held in an in-memory cache rather than fetched from the database each time. Worker nodes take short-lived distributed locks so that two of them cannot advance the same workflow instance at once.

Message consumers carry idempotency keys, so a message the broker delivers more than once — a retry after a timeout, a redelivery after a node dies mid-acknowledgement — is recognised and not acted on twice. This is at-least-once delivery made safe to repeat, not a guarantee that a duplicate can never occur: a side effect already committed to a third party before the crash is outside anything this layer can undo, which is why steps that move money also carry their own idempotency key to the provider.

If the cache is unavailable the system falls back to the primary datastore. It gets slower; it does not get wrong.

9. Standardized 3-Pattern Connector Architecture

COWE ships 196 production connectors — across Productivity, ITSM, Developer Tools, CRM, Marketing, Accounting, Logistics, Fintech and Security. A connector is one action against one service, so a single app usually accounts for several of them; that is why this figure is larger than the number of apps quoted elsewhere on the site. They follow a common 3-pattern contract:

• Create Pattern: Creates entities (e.g. Jira Issue, Zendesk Ticket, Google Calendar Event) and outputs the generated ID and payload.
• Update Pattern: Updates existing entities (e.g. Asana Task Status, ServiceNow Incident State, HubSpot Lead) with mandatory entity ID matching.
• Lookup Pattern: Queries entities (e.g. Google Workspace User, PagerDuty Incident, Dynamics 365 Record) and injects results into workflow variables.

10. Personal Data Classification & Masking

Workflow variables are masked where they leave the system, not where they are stored. Masking them at rest would break the run — step implementations read variables mid-execution, {{name}} substitution resolves from them and connector payloads are assembled from them — so the engine keeps working on real values while every projection redacts. That split is only safe if a redacted value can never be written back, so the variable, operator-edit and time-travel write paths all reject a payload carrying a redaction token rather than persisting it over the original.

Classification is declared at the connector, not inferred from the value. A connector saying a field is an ID number is knowledge; a regex deciding a value looks like one is a guess — and the guess is what misses a name, an address or a salary, none of which have a shape. Declared names are recorded against the run as it touches them, so what was sensitive when it was written stays sensitive even after the workflow definition is edited. Pattern matching still runs over everything else, covering SA ID numbers (validated by Luhn check digit and embedded date), E.164 and SA national phone formats, card numbers, SSNs and email addresses.

Replay decoding happens server-side, so a time-travel view cannot hand a client the undecoded original and call it masked. Audit messages are masked on write under a per-organization policy (masking on by default) and capped at 4,000 characters, keeping an unbounded vendor error body out of the database, the portal replay and the SIEM stream at once.

11. Edge Execution & a Complete Audit Trail

A step can be marked for edge execution and dispatched to a worker running inside your own network — against a database, ERP or line-of-business system that never touches the internet. The cloud holds the workflow state; the edge holds the execution. Steps are streamed to the worker over an authenticated event stream and results are posted back, at which point the instance resumes exactly where it paused. The worker authenticates with a key carrying a dedicated edge:worker scope: claiming queued steps and writing their results is a capability of its own, not something a general-purpose organization key inherits.

Crucially, the audit trail the step wrote on the edge travels back with the result. The step executes against a context inside the worker process, and every line it records — the call it made, the response it got, the reason it failed — is returned and written into the instance's own trail, stamped with the time the work actually happened rather than the time the result arrived. An edge step touches systems the cloud cannot see, which is precisely when the record of what it did matters most.

The trust boundary is explicit. The organization's masking policy travels down with the task so identifiers are redacted before they leave the edge host, and is re-applied on ingest rather than taken on trust. Entry counts, message lengths and step identifiers are all bounded at the API: an edge worker is trusted to execute your steps, not to decide how much a completion request may write into your database and security monitoring.

Edge delegation is an Enterprise entitlement, checked when the step is delegated rather than when a worker connects — a task queued against a tenant who can never claim it would surface a plan problem as an instance that hangs. Steps are metered on completion at the standard one credit, so a task no worker ever picks up costs nothing and a step that fails is not billed. Completion is idempotent: a worker's at-least-once retry of a result whose response was lost is acknowledged rather than reprocessed, so neither the charge nor the audit trail is duplicated.