# Security Policy

DylrDev takes security seriously because it stores credentials for contact center and telephony platforms. Thank you for helping keep it safe.

## Supported versions

DylrDev is a hosted service. Only the version currently running at https://dylr.dev is supported.

## Reporting a vulnerability

**Please do not open a public issue for a security problem.**

Report it privately by emailing **security@dylr.dev**. If we publish our source code, we will also turn on private vulnerability reporting for that repository and say so here.

Please include what you found, steps to reproduce, the impact you think it has, and whether you want credit.

## What to expect

- We acknowledge your report within **3 business days**.
- We confirm whether it is a valid issue and its severity within 7 days of acknowledging.
- Critical and high severity issues: fix or mitigation as fast as we can, usually within 14 days.
- Medium and low severity: within 90 days.
- We tell you when it is fixed, and credit you if you want (there is no cash bounty).
- Please give us up to 90 days to fix an issue before public disclosure. If we need longer we will tell you why.

## Safe harbor

If you act in good faith, we will not pursue legal action against you for security research that stays within these rules:

- Test only against your own account, using test or sandbox credentials. Never use real customer credentials.
- Do not access, change, or keep other people's data. If you reach it by accident, stop and tell us.
- Do not degrade the service (no denial of service or heavy load testing).
- No social engineering, phishing, or physical attacks.
- Do not attack the platform vendors or third parties DylrDev connects to. They have their own rules.
- Give us a reasonable chance to fix the issue before disclosing it.

This safe harbor covers Dylr LLC only.

## Scope

In scope: the DylrDev web app, MCP endpoints, OAuth endpoints, connector adapters and policy files, and any DylrDev source code we publish.

Out of scope: third party platform issues (report to the vendor), reports from automated scanners with no demonstrated impact, missing best-practice headers without a real risk, and social engineering of our team.

## Things we especially care about

- Reading or using another account's connection (tenant isolation).
- Getting stored credentials, tokens, or the master key.
- Bypassing tiers, arming, approvals, safety presets, or caps (for example running a DANGEROUS tool without arming or approval, or getting a tool trusted that should never be).
- Reading the full arguments of a pending approval without being allowed to approve it, or after it was decided or expired.
- A tool missing from a connector's policy file, or classified too leniently.
- Calling an upstream host that was not chosen at connect time (SSRF).
- Authentication, session, CSRF, or OAuth weaknesses.

## Rewards and credit

We do not run a bug bounty. We offer public credit in release notes and our security acknowledgements, with your permission.

## Contact

security@dylr.dev (general contact: ryan@dylr.dev). To report abuse of DylrDev rather than a vulnerability, email abuse@dylr.dev.

Postal mail: Dylr LLC, Attn: Ryan Shatzkamer, 2831 E Oakland Park Blvd, Ste 9 #3216, Fort Lauderdale, FL 33306. This is a mail-receiving address, not an office, so please report security issues by email, not by post.