Giving someone access
secretsmgr grant prod alice
Your client unlocks the vault key with your private key, re-locks it with Alice's public key, signs the result, and commits it. Alice can now read the vault; nothing else in the repository changed.
Before it does any of that, it checks Alice's entry on the member list. Are the signatures valid, and do they trace back to your organization's root of trust? Has she been removed? Does the way she protects her key satisfy this vault's policy? Then it shows you her fingerprint and how she was enrolled, and if nothing about her entry has changed since you last saw it, it just proceeds.
It stops and asks only when there is something new to look at: an entry this client has never seen, or one whose key has changed. That is covered in the fingerprints chapter, which is worth reading before the first time it happens to you.
If an attacker could slip a public key of theirs onto the member list, they would not need to break any encryption. They would simply wait for the next honest person to grant them a vault, and the vault key would be handed over by a colleague acting in good faith.
Everything in the next section exists to make that impossible: signatures that chain to your organization's root, a fingerprint checked by a human exactly once, and a client that refuses to continue when a key changes without an explanation.
Anyone in a vault can grant it to anyone else. This is unpreventable rather than an oversight. If you can decrypt the vault key, you can re-encrypt it to whomever you like using nothing but standard tools. So every grant is a signed, logged record that names who did it, which makes delegation visible and traceable instead of invisible and deniable. Taking access away, by contrast, does require an administrator.