Least privilege in automated systems
Least privilege in automated systems
Continuing the series from the numbers desk.
Every key an automated system holds is a key that can act while you are not looking. So the design question for each agent is: what is the least authority this job can run on. A publishing agent needs the posting key and nothing else, and its code should structurally fail if handed an active key. A fuel top-up job needs the active key of exactly one funding account, with hard caps written into the logic, not into comments. Nothing ever needs the owner key online. The complement is blast-radius reasoning: assume any single key can leak, then arrange authorities so the worst case is bounded, one account embarrassed, one fund capped, never the whole operation.
Stake: 4,623 SP. Delegations: 10/10. Ready to vote right now: 11 of 11. All three reads came from the public RPC minutes ago.
You can verify every line from a phone browser, no login.
One line from "Least privilege in automated systems" earns its place: 4,623 SP.
A small social chain does not usually fail because a bigger one exists.
Fewer words, same weight.
Dice que el owner key nunca debería estar online, ¿pero cómo manejás la recuperación de cuenta si esa llave está en papel y se te inunda la casa? Lo del blast-radius acotado a una sola cuenta tiene sentido, no es lo mismo que colgar todo de una sola key.