Security center

Find the security evidence your review needs.

Start with architecture, control status, data handling or agent trust. See the available records and the questions that still need a release-specific answer.

Current control information, clearly scoped

On this page2 sections

Security architecture and control status

Follow the boundary from identity to evidence.

Architecture and build evidence available · certification and remaining deployed proof are not implied
Download the public security overview Review security in a walkthrough
Reviewed 2026-08-15 · public overview · not certification
Inspect the technical architecture

Security architecture

Control architecture
Boundary visible
Control architectureConceptual boundary
  1. Identity

    Role, MFA, and customer scope

  2. Data

    Regional boundary and protected records

  3. Action

    Policy, approval, and stop conditions

  4. Evidence

    Decision, result, and review trail

Illustrative Security architecture concept—not a live product screenshot.
  1. 01

    Identity and tenant scope

    Dayrook resolves the principal, active tenant, customer, data region, session assurance, role, and entitlement before protected work reaches a domain owner.

  2. 02

    Policy and approval

    The owning route or service checks RBAC/ABAC, MFA, billing state, approval, consent, purpose-bound secret access, and the current resource state.

  3. 03

    Regional execution

    Selected-region services, workers, PostgreSQL, Valkey, and object storage run the operation; agents and collectors independently verify signed machine instructions and local policy.

  4. 04

    Evidence and recovery

    Allow, deny, material failure, provider result, retry, dead letter, rollback, restore, and customer communication evidence returns to the owning workflow and audit path.

US and EU platform foundation

Provider foundation active

Vultr records active US and EU VKE, PostgreSQL, Valkey, load-balancer, and regional storage foundations; remaining public edge, certificate, runtime, and customer-workflow proof stays explicit.

Overview reviewed 2026-08-15
Supporting evidence and open questions →

Tenant and regional database isolation

Regional tests recorded · workflow proof continues

The requirements record deployed tenant-isolation tests against the canonical US and EU database targets while broader product and provider journeys still require release-specific evidence.

Overview reviewed 2026-08-15
Supporting evidence and open questions →

Agent and collector command trust

Build verified · deployed device proof pending

mTLS identities, pinning, signed envelopes, expiry, nonce, replay checks, and local policy are defined and build-tested; real signed-device and collector runs remain release evidence.

Overview reviewed 2026-08-15
Supporting evidence and open questions →

Encryption and secret boundaries

Control design recorded · release proof continues

The security model requires encrypted regional data and state, object encryption for backups, client-side Vault item encryption, purpose-bound secret references, short-lived grants, and no plaintext secret logging. Release-specific runtime and recovery evidence remains part of diligence.

Overview reviewed 2026-08-15
Supporting evidence and open questions →

Vulnerability reporting and remediation

Reporting path available · response promise not published

Security concerns and suspected vulnerabilities can be routed through the security inquiry path. Triage, containment, remediation, evidence, and disclosure follow the incident process; no public severity-response deadline is claimed without an approved operating commitment.

Overview reviewed 2026-08-15
Supporting evidence and open questions →

Observability and incident evidence

Provider projects exist · runtime receipts pending

Sentry projects and PostHog dashboards are provider-recorded, but complete deployed, privacy-reviewed event and incident receipts remain pending.

Overview reviewed 2026-08-15
Supporting evidence and open questions →

SOC 2, ISO 27001, HIPAA-ready, GDPR-ready, and PCI posture

Readiness work · no certification claim

Architecture and control requirements support readiness work. Certification, legal compliance, BAA, DPA, or customer-specific claims require the appropriate external audit, assessor, legal review, approved agreement, and current evidence.

Overview reviewed 2026-08-15
Supporting evidence and open questions →

Incident path

From signal to accountable follow-through.

Report a security concern
  1. Classify impact and severity, page the accountable operator, and open one incident record.
  2. Contain the affected tenant, region, provider, agent, credential, or workflow without expanding access.
  3. Record impacted tenants, start and end time, exposure assessment, evidence, decisions, and corrective action.
  4. Publish status and customer communication when a user-facing workflow is affected.
  5. Close with recovery verification, root cause, prevention work, owners, due dates, and a postmortem where required.

Questions, answered

Security center: common questions

Does Dayrook publish a trust center?

This security center is the public entry point; access to detailed evidence can depend on sensitivity, approval, and an evaluation relationship.

How does operational AI access customer systems?

AI can use only the configured provider, model, tools, tenant scope, role, autonomy level, and approval path permitted for the workflow.

Where can I review suppliers and data processing?

See the subprocessor and DPA pages, noting their published approval and effective status.