Planned capability

Security program

Make every security statement traceable to evidence

Plan DewEngine security around tenant isolation, least privilege, protected authorization material, bounded data retention, auditable actions, and recoverable operations. Architecture and local tests can demonstrate design intent, but this route deliberately stops short of claiming a production security posture, certification, or regulatory compliance.

Illustrative product surface. The workflows below are planned, not a live connector.

Talk to us ↗Read technical guides →

Planned boundary

Security architecture is not a certification

The customer security and compliance surface is planned and not callable. DewEngine has no public production environment, independent audit, certification, penetration-test report, compliance attestation, or completed processor program.

Current evidence: Development code hashes API keys, scopes records by workspace in services and SQL, encrypts staged and active Google authorization material through configured crypto, sanitizes some provider attempts, signs webhooks, and checks destinations. Production KMS, row-level security, backup controls, and operated monitoring remain absent.
Target contract: Authenticate every request into one workspace and authorize the exact account, resource, and action before connector work is created; Protect provider credentials with envelope encryption and narrowly scoped decryption while excluding secrets from logs, events, webhooks, and support views; Record administrative and communication actions in an immutable audit stream with customer-controlled retention and deletion boundaries
Known limits: Passing repository tests does not establish production configuration, organizational controls, cloud security, availability, privacy compliance, or resistance to an independent adversary; Local ciphertext clearance does not prove managed-key destruction, upstream grant revocation, object-store deletion, backup expiry, or full data-subject completion
Release gates: Complete threat modeling, production KMS, secret rotation, row-level defense, tenant escape testing, and independent penetration review; Prove encrypted backups, restoration, retention expiry, disaster recovery, incident response, vulnerability management, and access review; Publish accurate subprocessors, data flows, contractual controls, and any formal attestations only after the corresponding audits finish

Tenant boundary

Resolve ownership before touching a record

An API key or future user session should resolve one workspace and environment. Services then include that tenant in every lookup and mutation, including joins to account, command, event, delivery, and provider-attempt state. Opaque identifiers reduce accidental leakage but do not replace authorization tests and database-level defense against a missing predicate.

Exercise cross-tenant identifiers across every endpoint and worker lease
Keep internal UUIDs and public IDs separate

Implementation custody

Decrypt authorization only inside the required operation

The target service stores ciphertext and a key reference, while managed KMS policy limits which worker identity can unwrap it. Plaintext exists in memory for the shortest practical interval and never enters job payloads, diagnostics, traces, or customer webhooks. Rotation must preserve recoverability without leaving old active material indefinitely.

Separate application data keys from managed wrapping keys
Audit decrypt purpose without recording the decrypted value

Network and delivery

Treat callback destinations as outbound attack input

Customer webhook URLs can target private networks, redirect unexpectedly, present invalid TLS, or respond with oversized bodies. Destination policy should resolve and revalidate addresses, restrict schemes and ports, bound redirects and timeouts, and record only sanitized results. Similar egress policy is required for connector hosts and any future browser-isolated runtime.

Test DNS rebinding and redirect changes, not only the submitted URL
Keep private-destination exceptions disabled in operated environments

Data lifecycle

Delete across every store and derived index

A disconnect fences future writes; deletion then addresses active secrets, staged grants, normalized records, raw payloads, attachments, audit exceptions, search indexes, replicas, and backups under documented retention. Upstream revocation is a separate outcome with its own ambiguity. Support needs proof of each stage without retaining the customer content being removed.

Model legal or security holds explicitly instead of silently skipping deletion
Test interrupted retirement jobs until they converge safely

Assurance gate

Publish claims only after the control operates

A control matrix should link each public statement to code, configuration, tests, owner, review date, and production evidence. External assessment must examine the deployed environment and organizational process, not a local fake provider. Any certification scope, exclusions, and report period should appear beside the claim so customers can evaluate what was actually tested.

Fail site checks when wording outruns capability evidence
Schedule recurring access, restoration, and incident exercises

Illustrative contract

Preview the intended integration boundary.

This shape documents the intended account and resource boundary. It is not callable, and it does not generate provider traffic.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapePlanned · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No live connector · no provider request

Questions

Before you build.

Is DewEngine currently certified against a security or privacy standard?+

No certification or attestation is claimed on this route. The repository contains development controls and tests, while a production program, independent assessment, documented scope, and operated evidence remain release work.

Does encrypted database content prove that provider credentials are safely managed?+

No. Secure custody also requires managed keys, identity-scoped decrypt permission, rotation, memory and log hygiene, backup treatment, incident procedures, deletion proof, and tests against the actual production configuration.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗