A deploy job must push a rotated database password into a secret store — why grant it write but not read?

## Write is not a weaker read Over a single stored value, a store expresses at least three distinct rights: **read** the current contents, **write** a new value, and — where the store keeps history — **read an earlier version**. They are separate rights, and a design that treats write as a junior form of read hands every writer the estate's contents. The deploy job that rotates the payments team's database password needs exactly one of them. It generates a new password, changes the database account, and puts the new value where the payments service will find it. At no point in that sequence does it need to know what the value was. ## Why this identity in particular A deploy identity is the least defensible long-lived identity most estates hold, not because the team is careless but because of where it lives: - it runs on shared build infrastructure that many people can reach; - it is triggered by whatever can start a deployment, which is usually a merge; - it is long-lived, because it has to work unattended at three in the morning; - its output is captured — job output, artefacts, diagnostics — and captured output is read later by people who were granted nothing. Give it read and you have created an identity that can enumerate and remove values, sitting on machines whose purpose is to run other people's code. Give it write alone and a theft yields the ability to disrupt, not the ability to collect. ## How a blind writer knows it worked The standing objection is that a writer which cannot read cannot verify. It can — just not by inspection: 1. The write returns a **version or receipt**: an increasing number, or an identifier for the value just stored. That is metadata about the value, not its contents. 2. The job records the version it expects consumers to move to. 3. The **consumer confirms by use**. The payments service starts, reads the value, authenticates against the database and reports success. A credential that authenticates has been verified in the only way that matters. 4. If the consumer fails, that failure is the signal, and the response is to write again or roll back — still without reading. Confirming by use is strictly stronger than confirming by reading. A read only tells you that the bytes in the store match the bytes you generated; it says nothing about whether the database account accepts them. ## Where write-only stops being harmless This is the honest limit of the control, and a thorough answer reaches it. A write right converts into knowledge of a **live** credential in any flow where what is written later becomes the value the downstream system accepts. If the design is "write the new password into the store, then let something push the store's value to the database account", an attacker holding the write right can put in a password of their choosing and wait for the estate to make it real. So the grant has to be read together with the direction of the flow: | Flow | What a stolen write right yields | |---|---| | The job changes the account first, then writes what the account now accepts | disruption: consumers get a value the account rejects | | Something reads the store and pushes that value onto the account | a working credential the attacker chose | | The job writes a proposal and a separate identity applies it after review | disruption only, and the review is the check | The middle row is why write over a credential is still a privileged right, and why the identity that applies a value to a downstream account is worth separating from the identity that proposed it. ## The shape of the grant - **Deploy identity: write**, on the one value it rotates. Not read, not history, not other teams' values. - **Payments service: read**, on the same value. Not write — a consumer that can overwrite its own credential can also destroy it, and a compromised service then poisons what it was merely supposed to use. - **Operator: neither.** They run the service. - **History is a third decision.** Where the store keeps previous versions, the right to read them is a read right with a delay. Granting it beside write quietly undoes the split, and it is the easiest one to grant by accident because it often travels with a management right rather than with read. Two failure modes worth naming out loud. The first is the read granted "just to verify" during an incident: a read right with a good story and no expiry. The second is believing that a write event in the store's record proves the right value landed — the record shows that a write happened and which identity made it, not what it contained or whether it works. Only the consumer's successful authentication shows that.