Warder
A secret access broker. Applications receive the credentials they need; the developers, CI jobs and agents that build those applications never see the values.
Visit site
The problem
Most secret managers ship a single “access” permission, so anyone who can deploy an application can also read every credential it uses. The person who needs the database to work and the person trusted with the database password end up being the same person by accident rather than by decision.
That collapses the moment anyone temporary is involved. A contractor rolls off and every credential they could have read has to be rotated. An agent runs a dependency’s README and holds whatever the environment held. A .env reaches a public repository and the question becomes which of the values in it were real.
The approach
The idea underneath it: using a secret and seeing a secret are separate permissions. “Can use” puts the value into the environment block of a process and no human reads it. “Can see” shows plaintext to a named person and records that it happened. Owner, Admin, Developer and Viewer govern administration only. None of them grants either one.
Integration is three commands and no code change: `ward init` writes a committable file holding two names and no credentials, `ward login` stores a session per machine, and `ward run -- npm run dev` injects the values into the process it starts. Application code keeps reading `process.env`; there is no SDK to import.
The site states the limits rather than burying them: it does not get you to zero credentials, and it cannot stop an authorized process from reading its own environment. Naming what a security tool does not do is the part that makes the rest of it evaluable.