I see only 1.
Admin, access <> ownership.
If someone needs access to a secret, you would implement it in this DSL and commit that to the system. A side effect would run on that which would grant access to that secret. When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.
> When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.
For this to work, you’d need to also rotate the secret, or ideally issue one for each person (so that others don’t have to update their configs).
...but sometimes you can’t reliably automatically rotate the secret, because they could have used it for something in production.