The runtime is the security boundary. The model is an implementation detail.
Dropstone CLI treats every model output as untrusted text. Whatever the model writes — code, shell commands, URLs to fetch, file edits — does nothing on your machine until you explicitly approve it. In Build mode, every destructive action prompts you with three choices: Allow once, Allow always, or Reject.
This is the security boundary. It is the same control surface that Anthropic, Databricks, NIST AI RMF, and every serious agentic-AI security framework converges on. The industry term is Human-in-the-Loop (HITL); the engineering principle is treat-model-as-untrusted-input.
If a model were to suggest a malicious shell command, file write, or network call, it would appear in your terminal as a proposed action. Nothing executes. You read it, decide, and either approve or reject. There is no path from model output to your filesystem that bypasses you.
Accept-All mode auto-approves tool calls for the current session. It is intentionally opt-in and clearly labelled in yellow. Use it only when you have already reviewed the agent's plan.
Every Dropstone chat is served by US-hosted inference providers, selected for their published latency, capacity, and data-handling guarantees. Requests route across multiple providers for redundancy, with automatic failover between them.
Provider selection is enforced in code, not configuration — China-hosted endpoints (the model labs' native APIs) are excluded by design and cannot be selected at runtime. Failover between US providers is permitted; falling out of the US-only set is not.
Every upstream call leaves Dropstone with data collection disabled. If any provider in the routing chain would retain the prompt or the completion, the request fails closed rather than falling through to one that would. This is enforced at the API boundary on every call, not asserted in marketing copy.
That guarantee covers the model providers. Dropstone itself is a separate question, and the honest answer is that we do keep some of your content. Request logs hold metadata only, meaning the model identifier, token counts, latency, cost, and status code. Nothing from a request reaches third-party analytics. Two other things are retained against your account, both set out below and in the Privacy Policy. The first is the context that gives the assistant memory between sessions. The second is coding session text, kept only for consumer accounts that have the setting switched on, and used to post-train our own model.
Both are exportable and deletable from dashboard settings. Neither one is a request log. They are stored separately and governed by sections 5.2 and 5.3 of the Privacy Policy.
The first of those applies to consumer accounts only. When the "Improve Dropstone" setting is on (default for Free, Pro, and Max, and one click to turn off in settings), the CLI sends anonymous coding-outcome metadata used to train our routing and verification models. That means whether an edit was accepted, whether tests passed, the turn count, a coarse failure category, and the model and effort used. Never your code, prompts, diffs, completions, or tool arguments. The table that stores it has no column capable of holding content, so this is a structural guarantee rather than a policy promise.
Separately, consumer accounts (Free, Pro, and Max) share "full coding sessions" on by default, the same posture the major labs use for consumer data. The session text, meaning your task, the model's diffs, and test output, is used to post-train our open-weight model on real, test-verified work. It is text only and we never collect raw images. You can turn this off at any time in dashboard settings to keep your sessions private, and stored samples are deletable on request.
Commercial and enterprise accounts are excluded entirely. We never collect metadata or session content from them regardless of any toggle, and we never train on their data. The zero-retention guarantee above is unqualified for those buyers.
Dropstone Fast 1.7, Pro 1.7, and Heavy 1.7 are branded names. The underlying model behind each tier is selected each cycle by Blankline Research's open-weight frontier evaluation, and the brand stays stable as the model changes underneath.
The version suffix 1.7 encodes Year 1, Month 7 — July 2026. Each cycle re-evaluates the open-weight frontier on independently measured capability and agentic tool-use benchmarks, compared like-for-like, and pins the best fit to each tier.
The underlying model is an implementation detail. The brand is the stable interface. When a better model emerges, the brand follows.
Images attached to any Dropstone tier are processed through Dropstone Vision 1.5, currently built on Gemini 3.5 Flash (84% MMMU-Pro, tied for industry leadership). The caption is then forwarded as text to the user's selected reasoning model.
Captions are keyed by SHA-256 of the image bytes. The same image attached twice returns the cached caption with sub-millisecond latency and zero additional API cost. Cache entries expire within 24 hours and do not persist beyond the server process lifetime.
We cannot mathematically prove that any frontier foundation model is free of embedded behaviors. Goldwasser, Kim, Vaikuntanathan & Zamir (2022) proved that no party can — this applies equally to Claude, GPT-5, Gemini, and every closed-weight model in production today. The limit is cryptographic, not engineering.
We acknowledge this openly. Our security guarantees do not depend on proving the model is clean. They depend on the runtime architecture above: the model cannot affect your machine without your explicit approval, and inference cannot retain your data because we forbid it at the API boundary.
Model origin is a security non-issue when the runtime treats every model as adversarial. We do.
The complete list of third parties that may process customer data on Dropstone's behalf:
This list is the full set. Changes are reflected here within seven business days of any addition or removal.
Dropstone is a thin authenticated proxy. Request logs hold no customer code, prompts, completions, or attached files, and commercial and enterprise accounts have nothing retained beyond that. Consumer memory and session sharing are covered in section 03. Customer data is otherwise processed only by subprocessors that maintain their own current security certifications, and the chain is audited end to end through inheritance.
| Subprocessor | Certifications |
|---|---|
| OpenRouter | SOC 2 Type II |
| US-hosted inference providers | SOC 2 Type II (HIPAA-ready) |
| Google AI Studio | SOC 1 / 2 / 3, ISO 27001 / 17 / 18, FedRAMP High, HIPAA, PCI DSS |
| Stripe | PCI DSS Level 1, SOC 1, SOC 2, ISO 27001 |
A Dropstone-level SOC 2 Type I audit is planned for our enterprise GA. We commission it earlier on request — enterprise prospects with procurement requirements can write to [email protected] to schedule.
Inherited compliance is not a substitute for our own audit — it is the floor we operate above. Certifications listed reflect each subprocessor's current published status; verify directly with the provider before relying on them for procurement.
For organizations operating under FedRAMP-adjacent, DoD-procurement, or specific regulated-finance requirements where open-weight model provenance restrictions apply, Dropstone offers an Enterprise tier built on US-trained open-weight models. The runtime architecture is identical; only the underlying model selection differs.
VPC deployment, BYOK encryption, and self-hosted deployment inside your own environment are available on request. Dropstone does not hold a SOC 2 certification of its own. Section 08 sets out what our subprocessors are certified for and what we are not.
Contact [email protected].
If you discover a vulnerability or unexpected behavior in Dropstone CLI, the Dropstone server, or any infrastructure listed in Section 07, please report it to [email protected]. We acknowledge all reports within 48 hours.
We do not currently operate a bug bounty program. Coordinated disclosure with named credit is offered for any substantive report.