Security Overview · Everdeck

Draft for review. This overview is a draft pending review by a Singapore-qualified lawyer. It is not final and may change before Everdeck launches.

Everdeck agents act with our customers' credentials, so FLOW FN PTE. LTD. (UEN 202617303Z) designs it around three things that must never leak: data, credentials and authority. Each has its own controls, and none of them depends on an AI model behaving well. This overview describes them; our Data Processing Agreement makes them commitments.

1. Hosting and location

Customer data is stored in Singapore: the database on Neon in AWS Singapore, the application on DigitalOcean in Singapore. The files your agents read or save are kept in the same database, under the same protections as the rest of your data.
Encryption keys are protected by AWS KMS in Singapore, and service emails are sent through Amazon SES in the same region.
The services we rely on are listed on our Subprocessors page.

2. Tenant isolation

Every table that holds customer data is protected by row-level security in the database. Each request is bound to exactly one account before it reads or writes anything, so a query cannot return another customer's rows even if application code omits a filter.
Work that must happen before an account is known, such as signing in, goes through narrow, reviewed database functions instead of broad access.
Automated tests try to read and write across accounts, and deliberately weaken the protections to prove the tests catch it.
Our staff console reads through a separate, read-only database role. Staff can change an account only through a few narrow actions: suspending or restoring it, setting its plan, extending its trial and, after an identity check, resetting the second factors of a member who has lost all of them. A reset removes that member's authenticator app, passkeys and recovery codes, signs them out everywhere and removes their Slack approval links. Their password stays, their next sign-in asks them to set up a new second factor, and we email them about the reset. Each action checks the staff member's role and is recorded with their reason in our staff audit trail and in your own audit log. A reset is recorded in the audit log of every account the member belongs to.

3. Encryption and credentials

All traffic uses TLS. Data is encrypted at rest.
Model keys, OAuth app secrets, app tokens, and the credentials of MCP and API servers are sealed with AES-256-GCM using a data key that belongs to one account. Data keys are wrapped by a key held in AWS KMS that never leaves it, so a copy of the database alone reveals no secrets.
Each ciphertext is bound to its account and record, so a value copied elsewhere cannot be decrypted.
A secret is decrypted only inside the step that uses it. It is never shown again after saving; only its last four characters are displayed. Secrets are kept out of logs, and a connection's own secrets are scrubbed from anything its tools return to an agent.
Deleting an account deletes its data keys, which makes its encrypted secrets unreadable in our live database at once. Database backups keep copies of both until they expire, within 30 days.

4. Signing in and access

Every user must set up two-factor authentication: a passkey or an authenticator app, plus ten single-use recovery codes. Someone who loses all of them can ask our support team to reset them, which we do only after checking who is asking (section 2).
Passwords are hashed with Argon2id, must be at least 12 characters long, and are checked against known breaches using a method that never sends the password, or its full hash, anywhere. If that check can't be reached, the password is accepted rather than locking people out.
Sign-up and sign-in are rate limited and protected against bots.
Sessions use a random token in a secure, HTTP-only cookie, stored only as a hash. They end after 7 days without use and after 30 days at most, and users can see and revoke them on their Profile page.
We email you when someone signs in to your account from a device that hasn't been used to sign in to it in the last 90 days.
Sensitive changes, such as to credentials, policies, billing or deletions, need a second-factor check from the last 15 minutes.
Permissions are checked against roles for every request, at account and company level.

5. Agent safeguards

Agents can use only the tools their charter grants, and every tool call passes a policy check first.
Actions that move money, delete data or change permissions always need a person to approve. No one can approve their own request, and unanswered requests are refused.
Approvals are bound to the exact details approved; any change needs a new approval.
Content from outside the company, such as emails, web pages and customers' tickets, is labelled as untrusted data, not as instructions. Once an agent has read it, its tier 3 and 4 actions need a person to approve by default for the rest of that session. An Owner can allow a named reviewer agent to approve tier 3 actions instead, but never tier 4. Our AI Agents policy explains the risk tiers.
Tools from MCP servers are approved one by one, and a changed tool description needs approval again.
Addresses customers add for servers, APIs and webhooks are checked before every call, so they can't be used to reach private networks.
Spending caps, session limits and kill switches let customers stop work at once.

6. Audit and monitoring

Changes and agent actions are written to an append-only audit log. Each entry includes a hash of the previous one, so tampering shows. Everyone in a company can read its entries on the Audit log page; account owners and admins can also read the whole account's.
Our staff console shows agent sessions and their failures across accounts, so our team can spot problems. Only staff with the Compliance role can open the content of a session, and each time they must give a reason. That is recorded in our staff audit trail, which can't be changed or deleted, and in your own audit log, as is every change staff make to your account, including a reset of a member's second factors.
Staff sign in to the console with a password and an authenticator code every time, and their actions need an authenticator code entered in the last 5 minutes.

7. Development and operations

Code is reviewed and tested before release, including automated security and isolation tests.
Dependencies are pinned with hashes and scanned for known vulnerabilities.
Releases are built and checked on our own machines and deployed with a fixed image tag.
Database backups support point-in-time recovery, and we test restores.
Before general availability, an independent firm will test Everdeck, focusing on tenant isolation, approval bypasses and server-side request forgery.

8. Incidents

We assess suspected incidents promptly. We notify affected customers of a personal data breach without undue delay, and within 48 hours of becoming aware of it as our Data Processing Agreement requires. Where a breach is notifiable under Singapore law, we notify the Personal Data Protection Commission within 3 calendar days of assessing it as notifiable.

9. Reporting a vulnerability

Please report security issues to [email protected], following our Responsible Disclosure Policy. Our contact details are also published in security.txt.