Always allowed
List, get, search, report. Nothing changes in your platform.
dylr.dev Security
Security, in plain language. What we protect, how, and where the limits are.
DylrDev holds keys to systems that can place calls, change routing and touch customer lists. We store as little as possible, encrypt what we keep, refuse risky actions until you say yes, and log every call so you can check our work.
The data path. Every tool call takes this route, every time.
Tiers, enforced on our server. A confirm button in a chat is not a security boundary.
Allowed, your client asks
Reversible or low impact edits. The tool label tells your AI client to ask you first.
Refused until you say yes
Deletes, dialing, bulk lead changes, users and roles, live flows, spending, raw writes. Arm for 15, 30 or 60 minutes, or approve one exact call.
The facts. The same ones our security overview and privacy policy state.
| Encryption in transit | HTTPS everywhere, between your AI and us and between us and your platform. |
|---|---|
| Credentials at rest | A random data key per connection (AES-GCM, 256 bit) seals your credentials. That key is wrapped by a master key held as a platform secret, never in code or the database, and the wrap is bound to your account and connection. Decrypted only in memory during a request, never logged, never returned by any API. The app shows at most the last 4 characters of an identifier. |
| Passwords | Never stored. A salted, peppered PBKDF2-SHA256 hash with a random salt per user. 12 to 128 characters, common passwords blocked. |
| Tokens and sessions | Stored only as hashes. Access tokens last 1 hour, refresh tokens 30 days, CLI tokens until you revoke them. Each token reaches one connection. |
| Where data lives | Cloudflare: Workers for the service, D1 for the database. Operated from the United States on Cloudflare's global network. |
| What we never keep | Your conversations with your AI, call recordings, and the customer data your tools return. Results pass through in memory and only a short summary such as "returned 25 records" is logged. |
| Retention | Audit log 90 days, with arguments reduced to an approved list of safe fields. Security events 90 days. Credentials and tokens until you revoke the connection or delete your account, then deleted at once. Staff access log 12 months. |
| Staff access | The staff console shows account and connection metadata, never credentials, and every staff request goes to an append-only log. A read-only support view needs a written reason and a fresh password, lasts 30 minutes, cannot call your platform, and is shown on your Security page and emailed to you. |
| Sub-processors | Cloudflare: hosting, database, static files, email delivery, and the Turnstile bot check on the sign-up, forgot password, resend code and invite forms (no cookie). Have I Been Pwned: an optional breached-password check that receives only the first 5 characters of a SHA-1 hash. |
| Cookies and tracking | The app, sign-in, sign-up, reset, invite and staff pages: only the first-party cookies for sign-in, no analytics, no session replay, no tracking pixels and no third-party scripts except Turnstile on the forms above. The public pages: analytics, session replay and LinkedIn insights load only after you allow them in the cookie bar, and never record what you type. No ads, and we never sell your data. See the cookie notice. |
| Outside audits | None yet. DylrDev has not been through a SOC 2 or an independent penetration test. Outside review is welcome. |
Full detail: the privacy policy, the cookie notice and the terms.
Signing in, and staying in control. Small rules that stop common attacks.
Email codes on new devices
Six digits, ten minutes, once, with limited attempts. We email you when a sign-in comes from a new device.
Password again for risky steps
Arming, approving, creating tokens, deleting, and changing your password or email ask for it if you have not entered it in 15 minutes.
Revoke means delete
One click hard-deletes a connection's credentials, tokens, approvals and arming state. Also rotate the key at your vendor.
What we do not protect against. We would rather tell you than let you find out.
- A compromise of our running service. Someone who controls our hosting account, deployed code and secrets could decrypt credentials. Encryption protects stored data, not a fully compromised runtime.
- Over-privileged credentials. Give us an admin key and anything an admin can do is possible, subject to the tiers.
- Write actions that look harmless. Writes run without arming. With confirmations off in your AI client, no human sees them first.
- Reads that leak. Read results go to your AI vendor. A tricked AI could reveal what it read.
- Your AI account, email or device. If one of them is taken over, an attacker may act as you. Protect your email with two-step verification.
- Insiders with production access. Today one person, the founder, holds it. Support sessions are logged and shown to you, but no in-app rule fully removes that power.
- Perfect redaction. Audit redaction keeps only approved fields, but an approved field can still hold something sensitive you typed into it.
- Availability. DylrDev is free and has no uptime guarantee.
Found a vulnerability? Tell us first, and we will tell you when it is fixed.
- We acknowledge reports within 3 business days.
- Act in good faith and we will not take legal action against you.
- No bug bounty, but we are glad to credit you publicly, with your permission.
- Please do not open a public issue, and do not test against other people's accounts.
security@dylr.dev
Full disclosure policy, including scope and safe harbor.
Abuse of DylrDev: abuse@dylr.dev