Security Overview

Why this page exists

DAKAEi holds access to things that matter, such as your inbox, your calendar, and your team's documents. This page describes how that access is protected. It is a description of practice, not a contractual warranty, and it stays at a level that does not hand an attacker a map.

Encryption and secrets

Traffic between you and the service is encrypted with TLS. Data is encrypted at rest in the systems that store it.

Encryption keys are held in managed key storage, separated from the data they protect, and access to them is restricted to the systems that need it.

Credentials for connected apps are stored encrypted and used only to carry out actions initiated by you or by an automation you configured.

Passwords are never stored in a readable form. We store only a one-way hash, so a copy of our database does not reveal them.

Access control

Every request is scoped to the authenticated account, and data is isolated per account at the query level.

Internal access to production data follows least privilege: it is limited to the people whose role requires it, granted for the narrowest scope that works, and reviewed when someone changes role or leaves.

Administrative access requires multi-factor authentication.

Administrative and authentication events are logged, so access to production can be reconstructed after the fact.

People with access are bound by confidentiality obligations in their contracts, and are trained on handling customer data before they get it.

Connected apps and agents

Connecting an app is explicit, per-app, and asks for the narrowest permissions the feature needs.

You can revoke access at any time from the product, which invalidates the stored credential.

Actions that send or write are taken on your instruction. Where an action is irreversible or outward-facing, the product asks first.

An agent can only reach the apps you attached to it, within the permissions your account already holds. Creating an agent never widens access.

Backups and deletion

Backups are encrypted and access to them is restricted in the same way as production data.

Deleting content removes it from the product immediately, and deletion propagates to backups on the schedule set out in the Privacy Policy, so a restore cannot quietly resurrect deleted data indefinitely.

Monitoring and incidents

We log application errors and monitor for unusual patterns, including attempts to access accounts that are not yours.

We have a documented procedure for handling suspected incidents: contain, assess what data is involved, notify, then fix the cause.

If we identify a personal data breach, we will notify the Information Commissioner's Office within 72 hours where the law requires it, and tell affected users without undue delay where the breach is likely to result in a high risk to them. We will say what we know, what we do not yet know, and what we are doing about it.

Reporting a vulnerability

If you believe you have found a vulnerability, write to contact@dakaei.com with enough detail to reproduce it. Please give us a reasonable opportunity to fix it before disclosing it publicly.

We will not pursue legal action against researchers who act in good faith, stay within their own test accounts, avoid degrading the service, and do not access or retain other people's data.

Do not run automated scanning or load testing against the service without asking us first.