Versioned config values scoped org → project → environment → secret → version. Pull them into any app at boot, or write them from the CLI.
› Read the docsShort-lived credentials leased on demand and auto-revoked on expiry: Postgres, MySQL and Redis users, AWS credentials, your own endpoint, API keys, SSH key pairs and TillForge tokens.
› Read the docsLet an AI agent USE a secret it never learns. It works with a secretref:// handle; the broker materialises the real value only at the egress boundary, with your consent, against an allow-listed host — and audits every use.
› Read the docsApprove one exact request now; a machine runs it later with a single-purpose token. A droplet can delete itself without ever holding your cloud token, and the token can be bound to that droplet’s address and host key. With a dead-man timer it deletes itself even if the job hangs.
› Read the docsAsk a person for a value without a chat or a terminal in between. They open a link, confirm a code and paste it into the vault; your workflow gets a handle. A vendor without an account can send one through a single-use drop link, held until you accept it.
› Read the docsGive an AI agent its own token: it spends secrets inside the refs you pick, under a daily budget, and can never reveal one or consent for itself.
› Read the docsGive Claude, Cursor or VS Code their API keys without a plain-text config. The config names the secret; the server gets the value when it starts.
› Read the docsYour SSH key stays in the vault. ssh, git and your AI tools sign through the agent, and each use waits for your passkey or is allowed for a while.
› Read the docsRevealing a value or running a command with secrets waits for your passkey, or a tap on your phone matched to the approval page. An agent on your login can ask, and carries on the moment you approve; only you can approve. Trust a terminal for a day and everyday secrets stop asking.
› Read the docsSeal a secret nobody should read. Apps and the broker keep using it; no one can reveal it, owners included, unless two owners agree.
› Read the docsEach agent is compared with its own last two weeks. A new host, a new secret, a burst of spends or refusals, or an hour it is never awake reaches you within a minute, by email or through a TillPulse alert rule.
› Read the docsDecoy AWS keys, Postgres connection strings and Stripe keys that sit among the real ones. Nothing should use them, so the first use, in TillDev or against AWS or the database host, alerts every owner and admin.
› Read the docsA push, a commit or a TillPulse event carrying one of your vault values is caught by value, whatever it looks like: the push is refused, the event redacted, the admins told. A generated secret can rotate itself.
› Read the docsMake ML-DSA, SLH-DSA, ML-KEM and X-Wing key pairs, or a hybrid ML-DSA-65 + Ed25519 signing key, in the vault. You get the public key and its fingerprint, in the PEM forms OpenSSL reads.
› Read the docsPulls and leases come back encrypted to a post-quantum key inside TLS. Bind a token to a host key and a copy of it anywhere else gets nothing, and your admins are told.
› Read the docsCI jobs, cloud functions, pods and servers read secrets as what they are: a GitHub, GitLab, Bitbucket, CircleCI, Buildkite, Semaphore, HCP Terraform or Spacelift run, a Google, Azure, AWS or Kubernetes identity, a Fly.io, Vercel, Deno Deploy or Modal app, or a host key. Nothing is stored; each sign-in gets a short-lived token.
› Read the docsA workload identity proves who it is to your own services with a short-lived JWT-SVID, or an X.509-SVID for mutual TLS. Your workspace is its own SPIFFE trust domain with a public bundle, and its signing key and CA never leave the vault.
› Read the docsSee which suite protects each store in your workspace and rotate its data key in one step. A public inventory, also a CycloneDX CBOM, says what protects what in every product, classical parts included.
› Read the docsMark one secret restricted: only a token pinned to its environment pulls it, only the owner reveals it, and CI gets it on protected branches only.
› Read the docsEvery value is AES-256-GCM encrypted under a per-org data key that is itself wrapped by a master KEK. The database only ever sees ciphertext.
› Read the docsEvery write is a new version. See the history of a value, diff environments, and roll a bad deploy back to the last-known-good in one command.
› Read the docsDelete or rotate a secret that holds a TillDev token, and revoke that token where it was issued in the same step. A deleted token stops working.
› Read the docsPush an environment’s values to your own platform — Cloudflare, Vercel, Railway, GitHub, or AWS SSM. Vendor-agnostic, no lock-in.
› Read the docsReveal and pull are audited. Plaintext is assembled only in memory on an authorized read, and every one lands in the shared TillDev audit log.
› Read the docsMost apps need both: long-lived config values you set once and read at boot, and credentials you’d rather never store at all. TillSecrets keeps both under one roof, one token, one audit log.
Versioned, envelope-encrypted config scoped org → project → environment → secret → version.
Pulled into any app at boot with the SDK or the CLI — or synced to your own platform.
Every write is a new version, so rollback is a command, not an incident.
Short-lived credentials leased on demand from an upstream backend, auto-revoked on expiry.
Postgres, MySQL and Redis users, AWS credentials, API keys, SSH key pairs and TillForge tokens, each minted per lease.
TillSecrets stores a lease reference, never the credential itself.
Config is scoped org → project → environment — dev, staging, prod — then down to each secret and each version. load() pulls the right environment into process.env, decrypted in memory, at startup.
Every write is a new version. When a deploy ships a bad value, roll the secret back to the last-known-good with tilldev secrets rollback — no redeploy, no digging through a chat log for the old value.
Apps authenticate with a service token (ts_…) — bearer-only, stored hashed, scoped to one project and environment.
Every value is AES-256-GCM encrypted under a per-org data key, and that data key is itself wrapped by a master KEK — envelope encryption. Postgres only ever holds ciphertext; a database dump is a wall of noise.
Plaintext is assembled only in memory, on an authorized read, and every reveal and pull is written to the audit log. You always know what was read, by which token, and when.
AES-256-GCM under a per-org data key, wrapped by a master KEK.
Postgres stores only encrypted bytes — never a readable value.
Plaintext is assembled on an authorized read and never persisted.
Service tokens are ts_… — bearer-only, stored as hashes, scoped and revocable.
Reveal and pull land in the shared TillDev audit log, with the acting token.
Dynamic backends are reached through SSRF guards — no pivot to internal metadata.
You don’t have to read config through TillSecrets at runtime. A sync target pushes an environment’s values into the platform you already deploy on, so the values live where your app expects them. TillSecrets stays the source of truth; the sync is one-way and vendor-agnostic.
Set a value once in TillSecrets, sync it out to any of these — no rewriting the same secret into five dashboards, and no proprietary runtime to depend on.
The safest secret is the one that doesn’t exist yet. A dynamic secret is leased on demand from an upstream backend, valid for a short TTL, and auto-revoked upstream when it expires. A leaked lease is a dead lease in minutes.
Ask a Postgres, MySQL or Redis backend for a user and get one scoped to your grants, or ask AWS for a role session or a throwaway IAM user. TillSecrets can also mint API keys, SSH key pairs and TillForge tokens, or call your own endpoint with a signed request, so a CI job can push for an hour and hold nothing after.
TillSecrets stores only a lease reference — never the credential — and reaches the upstream through SSRF guards. A drop the upstream doesn’t confirm is retried until it goes through.
Dynamic secrets guide →Handing a key to an AI agent used to mean pasting the plaintext where the agent can read it — so it lands in the model’s context, the transcript, and every log. The broker inverts that. The agent works with a stable secretref:// handle; the real value is materialised only at the outbound egress boundary — with your consent, against an allow-listed host — and never returns to the agent.
The first spend of a reference against a host is an OAuth-style approval — once, this session, or TTL-boxed. After that the agent spends it repeatedly, no re-paste. Revoke any time; it takes effect immediately.
Each secret carries the only hosts it may ever reach, and optionally the methods and paths — enforced above consent, so a tricked or over-eager agent still can’t redirect a key to an attacker’s endpoint. Every destination is SSRF-guarded.
Run the broker on the local-agent bridge and the value is injected into the outbound bytes on your own host — the plaintext never enters the model, the chat, or a log. Every spend is audited; never the value.
Presign one exact call and hand a machine a token that can run only that call, a bounded number of times, while you still have access. Bind it to the machine’s address and key, and a leaked token is useless anywhere else. Or put it on a timer: TillDev runs it at a set time, or when the machine stops checking in. Nothing it holds can read the secret.
resolve → entitlement → allowlist → consent → claim → inject → response-scrub → audit. The plaintext lives only for the microseconds of the request, and is re-tokenised out of any echo before the agent sees it.
TillSecrets isn’t a separate vault to run — it’s the config-and-credentials layer of the TillDev workspace you already have, with the same org, the same members and roles, and the same audit log.
Every reveal, pull, version, sync, and lease writes to the shared TillDev audit log, next to your Pulse, Auth, and Shield events — one history, not five.
One login, one bill, one set of members and roles. Add TillSecrets to a workspace that already runs TillPulse and it inherits the org and billing you already have.
The config your apps boot with and the credentials they lease live where the rest of TillDev can see the audit trail — secrets aren’t a blind spot in your workspace.
Get your config out of a chat thread and your credentials out of a static string. Versioned, encrypted, and audited — one workspace away.
You don't have to use the rest. But they fit together — same workspace, same audit log, same shortcut to switch between them. Add what you need when you need it.