Legal
How we use your data
A plain-language account of what happens to your data inside Shortspan - what is encrypted, what is logged, what leaves your machine, and what we can and cannot see.
- Effective
- Last updated
- Entity
- Shortspan Technologies
01Why this page exists
Our Privacy Policy is the legal document. This page is the engineering answer to the question a security reviewer actually asks: what data does Shortspan touch, where does it go, and what could an insider or an attacker see?
Nothing here overrides the Privacy Policy, the Terms, or the Data Processing Addendum. Where they conflict, those documents control.
02The four classes of data
- Secret material
- Passwords, API keys, private keys, connection strings, certificates. Encrypted before it reaches storage; decrypted only in memory, in-request, to serve an authorized retrieval. Never logged, never in analytics, never in an error report.
- Resource metadata
- Names, hostnames, ports, usernames, tags, project structure, host key fingerprints. Stored in plaintext because the product has to search, list, and display it. Treat it as visible to anyone with console access to your Workspace.
- Audit records
- Who asked for what, when, from which device and IP, and what the answer was. Append-only and deliberately hard to erase - that is the point of an audit trail.
- Operational telemetry
- Request timings, error traces, plan-limit counters, CLI version strings. Used to keep the Service up and to decide what to build. Scrubbed of secret values before it is written.
03What encryption actually protects
- 01A secret arrives over TLS and is never written to disk in plaintext.
- 02A fresh 256-bit data key encrypts it with AES-256-GCM, producing ciphertext plus an authentication tag.
- 03That data key is itself encrypted under your organization’s master key and stored beside the ciphertext.
- 04The master key is held separately from the database, so a stolen database dump alone does not yield plaintext.
- 05On an authorized read, the data key is unwrapped in memory, the value is decrypted, returned over TLS, and the buffers are released.
What this does not protect against: an attacker who holds both the database and the master key at the same time, or a compromised administrator inside your own Workspace who is authorized to read the secret. Encryption narrows the blast radius; access policy and the audit trail cover the rest.
04What the CLI puts on your machine
The CLI is deliberately thin about what it persists. On a normal workstation it writes:
| On disk | Not on disk |
|---|---|
| A configuration file with the API host, active organization, and active project | Any secret value, ever |
| A session token scoped to your device, in the OS keychain where one is available | SSH private keys or brokered database passwords |
| A device installation identifier so you can revoke this machine specifically | A cached credential usable while the broker is unreachable |
Injected secrets are passed to the child process environment and held in process memory for the life of that process. They do not touch your shell history, and no `.env` file is written. When the process exits, they are gone.
05What Shortspan staff can see
- Your account details, Workspace name, plan, and billing state - needed for support and billing.
- Resource metadata and audit records, if you ask us to investigate a support issue and grant access.
- Aggregate usage counts and error traces from our monitoring, with secret values scrubbed.
Staff cannot read your secret values through the product. Production access requires multi-factor authentication, is limited to a small on-call group, and is itself logged and reviewed.
06The audit trail
Every credential issuance, secret read, runbook execution, access approval, and administrative change is recorded with the actor, the target, the device, the source IP, and the outcome. Records are append-only.
Because audit records are a security control, they are not deletable on request in the way ordinary content is. Where a data subject exercises a right to erasure, we pseudonymise the identifying fields rather than destroy the record, and we explain what we did.
07Where data leaves our systems
Only to the sub-processors listed on our sub-processors page, each for a specific and disclosed purpose. Secret material never leaves our own infrastructure: it is not sent to the payment processor, the email provider, the error tracker, or any analytics service.
| Destination | What goes there |
|---|---|
| Payment processor | Billing contact and subscription state only |
| Email provider | Recipient address and message content of transactional email |
| Error monitoring | Stack traces and request metadata, with secret values scrubbed |
| Edge network / CDN | IP address and request metadata for TLS and DDoS protection |
08Getting your data out
You can export your Workspace at any time from the console, or through the CLI and API. Exports include resource metadata, runbook definitions, team structure, and - where your role permits - decrypted secret values.
Audit history is exportable in a machine-readable format suitable for ingestion by a SIEM. There is no export fee and no lock-in period.
If you need an export we do not yet offer through the product, email support@shortspan.dev and we will produce it.
09Deletion
- 01Deleting a resource removes it from the console and API immediately.
- 02Closing a Workspace starts a 30-day window during which you can still export; after that, records are purged from primary storage.
- 03Encrypted backups age out on a rolling 60-day cycle, at which point the data is unrecoverable.
- 04Billing and tax records are retained for the period tax law requires, regardless of account closure.
10Still have questions
Security reviews and vendor questionnaires go to security@shortspan.dev. Data protection questions go to privacy@shortspan.dev. We answer both from a real person, not a form letter.