Security

DeviceLink is designed with security at every layer. Here is how we protect your data.

Data in Transit

All communication between your device, DeviceLink, and the AI platforms you connect is encrypted using TLS. The specific TLS version depends on infrastructure configuration and is kept current with industry standards.

Data at Rest

The DeviceLink agent stores device credentials locally using AES-256-GCM encryption with keys derived from your machine identity via PBKDF2. No plaintext credentials are written to disk.

When you share a folder from a browser tab instead, credentials live in that browser's own storage. The signing key that identifies the device is created so that no code can read it back, and the token that keeps the session alive is encrypted with a second key the browser will not hand to any script. Neither can be copied off the machine. This protects what is stored - it does not protect against code running in the page itself, which is why a browser tab is the shorter-lived option and the agent remains the one we recommend for a device you rely on.

File contents are never stored on DeviceLink servers. They are streamed in real-time between your device and the requesting client.

Every connection is encrypted with TLS, from your device to DeviceLink and from DeviceLink on to the AI platform. Passing a request along means our service decrypts it, so file contents exist in server memory for as long as it takes to forward them. They are never written to disk, cached, or logged.

Authentication

  • OAuth 2.0 with PKCE (S256) for user authentication via Google, GitHub, or Microsoft
  • Optional email and password sign-in, stored as a scrypt hash with a per-account salt, never as plaintext
  • ES256 (ECDSA P-256) JWT tokens for API and MCP access
  • Ed25519 proof-of-possession signatures for device identity verification
  • Device authorization requires explicit user consent through a browser-based verification flow
  • Short-lived access tokens with automatic refresh

Local-First Architecture

DeviceLink operates on a local-first principle. Your files remain on your device. Access is granted only to directories you explicitly share, and only while the device sharing them is connected - the agent for as long as it runs, or a browser tab for as long as it stays open. You can disconnect at any time.

  • Path traversal protection prevents access outside shared directories, on every device type
  • Symlink and junction escape detection prevents boundary bypasses, on every device type. The agent resolves the real path of every file it opens and refuses one that lands outside the shared folder; a browser tab asks the browser to resolve the handle against the folder you picked and refuses the read when it does not resolve inside it
  • Configurable ignore rules filter sensitive files

The two device types differ in what they can tell you, not in what they allow. A browser tab cannot report that an entry is a symlink, because the browser interface it is built on does not expose links as such. It still refuses to read through one that leaves the folder you shared.

Audit Logging

Security-relevant actions - sign-ins, device approvals, access changes, tool calls - are recorded in an audit log that organization administrators can review. Entries record the acting account, the IP address and browser the request came from, and the result. See the privacy policy for what is kept and for how long.

Report a Vulnerability

If you find a security vulnerability, report it through our support page. Tell us what you found, how to reproduce it, and what you think the impact is. We read every report, we will tell you what we decide, and we will let you know when a fix ships. We do not run a paid bounty programme.

In scope: the DeviceLink web application, API and connection service at our own domains, and the published @devicelink/dlink agent.

Out of scope: the third-party providers listed on our subprocessors page, and any system we do not operate. We cannot authorise testing against someone else's infrastructure - report those to the provider directly. Also out of scope: denial of service and load testing, social engineering of our people or our customers, physical attacks, high-volume automated scanning, and reports produced only by a scanner with no demonstrated impact.

Working with us. If you make a good-faith effort to follow this policy, we will not initiate legal action against you for your research, and if someone else does we will make clear that your work was authorised. To stay within that, please: stay inside the scope above; use only your own accounts and your own test data; stop as soon as you have shown a problem exists; do not access, modify, retain or disclose anyone else's data; do not degrade the service for other people; and give us a reasonable chance to fix the issue before you discuss it publicly. This is our commitment, not a waiver of anyone else's rights, and it cannot authorise anything unlawful.

Changes to this page

  • October 2026 - Described how credentials are held when a folder is shared from a browser tab. Stated that the local-first guarantee and symlink containment apply to every device type, and that a browser tab cannot report that an entry is a symlink though it still refuses to read through one. Expanded the vulnerability reporting section with scope, prohibited activity, and the terms under which we will not initiate legal action against good-faith research.

Last updated: October 2026