Nothing here yet.
This becomes especially useful in AI-generated code because agents tend to work very well from whatever representation is closest to the current task. If a derived view looks authoritative, the agent can easily reinforce the wrong assumption. Making the primary record explicit gives both humans and agents a much stronger anchor for deciding what should actually change.
One thing that gets increasingly important in multi-tenant systems is keeping tenant resolution separate from tenant authorization. Knowing which tenant a request is targeting doesn't prove the caller is allowed to access it. I prefer making those two decisions explicit and testing the boundary between them, because otherwise a routing change can accidentally become a data-isolation change.
I like the idea of scoping permissions explicitly because it moves the security boundary away from the model's judgment. One thing I'd add is that the permission model itself should be versioned and inspectable. Once an agent can call tools repeatedly across a workflow, debugging “why was this allowed?” becomes just as important as deciding whether the capability should exist.
The interesting shift here is that agent security is less about whether the model can be trusted and more about where the enforcement boundary lives. A prompt or project rule can describe what the agent should avoid, but the stronger controls are the ones that still hold when the agent ignores or misinterprets the instruction. That distinction becomes much more important once agents can call tools and modify a repository instead of only generating text.
The replayability point is important. Once the decision depends on a graph or other external state, recording only the final verdict isn't enough because the evidence can change underneath it. Keeping the relevant snapshot with the decision turns "this was approved" into something that can actually be reconstructed later.
The handoff-as-a-contract idea is probably the part that makes multi-agent systems easier to reason about. If one agent produces architecture, another implementation and another verification, the useful artifact isn't just the prompt passed between them. It's the assumptions and constraints that the next stage can actually check. That gives you a much clearer failure boundary when something goes wrong.
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.
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.
