Feed
Discussion
Strong point on separation of concerns for agent policy. The challenge scales beyond single-agent governance though: in cross-agent workflows, Agent A needs Agent B to verify that its policy was actually followed before the transaction completes. A self-signed log entry isn't sufficient across trust boundaries. The practical next step is tying approval decisions to verifiable credentials with on-chain attestation, so any counterparty can verify policy compliance without needing to trust the originating agent's internal state.
The distinct-actor rule depends on the agent having an identity of its own. Most coding agents still run in the developer's terminal with the developer's git identity and tokens, so the policy proposal and the approval can arrive from the same account. Guard then either blocks a legitimate approval or accepts two actions from what looks like one person. Running the agent under its own credential is what makes author and approver mean different things.
The second place the loop can reopen is where verification reads the policy. If CI evaluates a branch against the policy file in that same branch, one diff can carry the refactor and the relaxed rule, and the check passes against the rule it just wrote. Reading policy from the protected default branch, and requiring separate review whenever the diff touches policy, keeps revision 17 and revision 18 apart without anyone having to remember to.
Your list of investigation questions gets much easier to answer once each verification result stores the policy revision it ran against, and this setup gives you that directly.