Security model

Shortspan reduces the number of places a credential exists and the length of time it exists there, and records every time one is handed out. That is the whole claim. Everything below is the detail of how far it goes and where it stops.

Credential sprawl

Keys on laptops, passwords in chat threads, access keys in dotfiles. Nothing is distributed, so nothing accumulates.

A lost or stolen machine

The machine holds an API token, not credentials. Revoke the device and it holds nothing - no key to rotate, no password to change.

Offboarding you cannot verify

Removing someone ends their access everywhere at once. There is no set of local files you have to hope they deleted.

An unanswerable audit

Every credential release is recorded with actor, resource, time, and source. "Who read that?" has an answer.

Standing production access

Access requests are time-boxed and expire on their own, so nobody accumulates access nobody remembers granting.

A leaked database

Secrets are encrypted with per-workspace keys wrapped by a root key held outside the database. A dump alone yields nothing.

Stated plainly, because a security tool whose limits are unclear is worse than one with fewer features.

A compromised developer machine

Malware running as you can read a brokered credential out of process memory, or simply run shortspan itself. The window narrows from forever to one command; it does not close.

A compromised server

An attacker with root and the root key can decrypt everything. That is what "the server decrypts to broker" means, and no arrangement of application-level controls changes it.

Misuse by someone legitimately authorized

A developer entitled to a production database credential can do anything that credential permits. Shortspan records it; it does not prevent it. Register narrow credentials.

What a credential can do once released

Shortspan controls who may obtain a credential, not its powers. A scoped IAM user is worth more than any policy layered over an administrator key.

What happens inside an SSH session

Session recording is not implemented. The record says a session was opened, by whom, and when - not what was typed.

A malicious runbook

Steps run on the executor's machine with their permissions and are not sandboxed. Review runbooks the way you review code.

On the hosted service, a deliberate constraint: the administrative control plane is built to be usable without being able to read customer credentials.

It shows that a secret exists, its type, when it was created and last rotated, which encryption key version protects it, its relationships, and its audit activity. It has no "reveal customer secret" feature. There is no admin path to secret plaintext, SSH keys, database passwords, AWS keys, kubeconfigs, API token plaintext, or wrapped keys - and the test suite asserts that, so it cannot be added by accident.

• Envelope encryption with per-workspace master keys, rooted in a key held outside the database.

• TLS enforced on the API; plaintext refused with 426 rather than redirected.

• Role checks in middleware, not controllers, so an endpoint cannot forget one.

• A separate, much tighter rate limit on every operation that returns plaintext.

• Two-step credential exchange for SSH, so the credential is not in the authorized response.

• Append-only audit logging of every credential release, including refusals.

• TOTP two-factor and WebAuthn passkeys, with notification on every credential change.

• Bearer tokens with narrowing abilities, revocable individually or by device.

• Time-boxed access grants that expire without human action.

• Central version blocking, so a CLI release with a defect can be withdrawn.

• Invitations stored as hashes, expiring in seven days, revoked on reissue.

• A separate authentication domain, separate session store, and step-up authentication for the platform control plane.

Listed so nobody plans around something that does not exist. These appear as Enterprise capabilities and are marked coming soon in the product.

• SAML SSO, OIDC, SCIM provisioning, and LDAP.

• HSM- or KMS-backed root keys. The code has the seam; the implementation is deferred.

• Dynamic credentials minted per session against your provider.

• Session recording.

• IP allowlisting and just-in-time access.

• Formal compliance certification. Controls are built with SOC 2 in mind; no audit has been completed.

Email security@shortspan.dev. See Reporting a vulnerability for scope and what to expect.