--- title: "Discussion on \"The Agent Shouldn't Be Able to Approve Its Own Rules\" | Hashnode" description: "Discussion on \"The Agent Shouldn't Be Able to Approve Its Own Rules\". An AI coding agent may need to change architecture, but it shouldn't silently approve the policy change that makes its own work pass." url: "https://hashnode.com/posts/the-agent-shouldnt-be-able-to-approve-its-own-rules/6abde927cfed546bd5b5a808" --- [Feed](https://hashnode.com/feed) / Discussion # [The Agent Shouldn't Be Able to Approve Its Own Rules](https://codapult.hashnode.dev/the-agent-shouldnt-be-able-to-approve-its-own-rules?utm_source=hashnode&utm_medium=feed) An AI coding agent may need to change architecture, but it shouldn't silently approve the policy change that makes its own work pass. Oct 1 · 11 min read · codapult.hashnode.dev Read the article - [#ai-agents](https://hashnode.com/tag/ai-agents) - [#architecture](https://hashnode.com/tag/architecture) - [#mcp](https://hashnode.com/tag/mcp) - [#guard](https://hashnode.com/tag/guard) - [#policy](https://hashnode.com/tag/policy) - [#ai-coding](https://hashnode.com/tag/ai-coding) - [#developer-tools](https://hashnode.com/tag/developer-tools) - [#typescript](https://hashnode.com/tag/typescript) ## Written by [Vlad Zoff](https://hashnode.com/@vladzoff) @vladzoff [View profile](https://hashnode.com/@vladzoff) Building Codapult and Codapult Guard Building SaaS infrastructure and developer tools with TypeScript and Next.js. Creator of Codapult and Codapult Guard. ## Responses 4 Markdown supported · ⌘↵ to post [Mike Dabydeen](https://hashnode.com/@firelinks) [Oct 1](https://hashnode.com/posts/the-agent-shouldnt-be-able-to-approve-its-own-rules/6abde927cfed546bd5b5a808/comment/6abe622fa02680d9bdba22d1) 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. [Vlad Zoff](https://hashnode.com/@vladzoff) [Oct 2](https://hashnode.com/posts/the-agent-shouldnt-be-able-to-approve-its-own-rules/6abde927cfed546bd5b5a808/comment/6abe622fa02680d9bdba22d1#reply-6abf3bd176188cc0bc041551) Yes, this is the part where "distinct actor" becomes an actual identity problem rather than just a policy setting. If the agent inherits the developer's credentials, you don't really have two actors - you have two actions attributed to the same principal. Protected approval can enforce the workflow, but it can't manufacture an identity boundary that the runtime doesn't have. The policy-source point is equally important. Verification needs to record not just the result, but which policy revision produced that result. Otherwise you can end up with a perfectly valid "pass" that is only valid because the same change modified the rule being evaluated. I like the protected-default-branch model for that reason. It makes policy revision and implementation revision separate objects instead of relying on the agent or developer to remember that distinction. [Cai](https://hashnode.com/@cailab) [Oct 1](https://hashnode.com/posts/the-agent-shouldnt-be-able-to-approve-its-own-rules/6abde927cfed546bd5b5a808/comment/6abe13dd7232b0630be4c11e) 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. [Vlad Zoff](https://hashnode.com/@vladzoff) [Oct 1](https://hashnode.com/posts/the-agent-shouldnt-be-able-to-approve-its-own-rules/6abde927cfed546bd5b5a808/comment/6abe13dd7232b0630be4c11e#reply-6abe1da829163e2bcdb6a92e) Yes, that becomes a different trust boundary. For a single repository, the important question is who is allowed to approve a policy change. In a cross-agent workflow, you also need evidence that the approval came from an authorized actor and that the verified state hasn’t changed since. I don’t think that necessarily requires on-chain attestation, though - signed, versioned policy decisions and verifiable run provenance can cover a lot of this without introducing a blockchain dependency.