The README-as-orders example lands because the system prompt says 'never expose secrets' and the agent probably complies — 'probably, most of the time' is not a control. The review question shift is the right one: what can actually happen if the model gets talked into something. Do you think the three-hop trace catches the third failure mode on its own, or does least-privilege on tokens have to be a separate gate?
The three-hop trace should catch it, but I’d still treat least privilege as a separate gate. The trace helps identify where the risk is, while least privilege limits the damage if something slips through. Even if the review misses the injected instruction entirely, a read-only token can't approve or merge a PR. I think you need both: trace the path, then make sure the permissions don't exceed what the task actually needs.
That's the cleanest version of the argument — the read-only token turns a review miss from a breach into a non-event, which is exactly what a separate gate should do. The trace finds the risk, the gate caps the damage, and neither one has to be perfect for the pair to hold. One question: does the trace change the permissions you grant up front, or is it mostly auditing them after the fact?
Ideally both, but I see it primarily as a design-time exercise first. The trace should help determine the minimum permissions the agent needs before deployment, not just document what it already has. Then you keep auditing those permissions as the agent evolves and new tools get added. Otherwise, least privilege tends to slowly turn into "whatever made the last feature work."
That's the right ordering — trace first to set the floor, then audit as tools get added, because otherwise every new feature quietly widens the permissions. The drift you describe is the real failure mode: least privilege decays into 'whatever made the last feature work' unless someone re-checks it on a schedule. Do you re-run the trace per release, or only when a new tool lands?
I'd do both, but with different levels of depth. A new tool should always trigger a review because it can change the agent's reach immediately. For releases, I'd make a lighter check part of the normal process, especially if prompts, workflows or credentials changed. The important thing is not to let permission changes slip through as ordinary feature updates without anyone noticing.
Good question. I'd make the tool manifest machine-readable and diff it in CI rather than rely on an author flag. Any new capability — write access, network egress, shell, or secret access — should fail the check until an owner approves it. The author's note explains intent, but the manifest diff makes permission drift visible and auditable.
Exactly. I'd also make the approval explicit and tied to the specific permission change, rather than a general PR approval. That way, adding a new tool or widening an existing scope can't hide inside an otherwise routine change. The machine-readable diff gives you something concrete to enforce in CI and something useful to audit later.
We're a place where coders share, stay up-to-date and grow their careers.
The README-as-orders example lands because the system prompt says 'never expose secrets' and the agent probably complies — 'probably, most of the time' is not a control. The review question shift is the right one: what can actually happen if the model gets talked into something. Do you think the three-hop trace catches the third failure mode on its own, or does least-privilege on tokens have to be a separate gate?
The three-hop trace should catch it, but I’d still treat least privilege as a separate gate. The trace helps identify where the risk is, while least privilege limits the damage if something slips through. Even if the review misses the injected instruction entirely, a read-only token can't approve or merge a PR. I think you need both: trace the path, then make sure the permissions don't exceed what the task actually needs.
That's the cleanest version of the argument — the read-only token turns a review miss from a breach into a non-event, which is exactly what a separate gate should do. The trace finds the risk, the gate caps the damage, and neither one has to be perfect for the pair to hold. One question: does the trace change the permissions you grant up front, or is it mostly auditing them after the fact?
Ideally both, but I see it primarily as a design-time exercise first. The trace should help determine the minimum permissions the agent needs before deployment, not just document what it already has. Then you keep auditing those permissions as the agent evolves and new tools get added. Otherwise, least privilege tends to slowly turn into "whatever made the last feature work."
That's the right ordering — trace first to set the floor, then audit as tools get added, because otherwise every new feature quietly widens the permissions. The drift you describe is the real failure mode: least privilege decays into 'whatever made the last feature work' unless someone re-checks it on a schedule. Do you re-run the trace per release, or only when a new tool lands?
I'd do both, but with different levels of depth. A new tool should always trigger a review because it can change the agent's reach immediately. For releases, I'd make a lighter check part of the normal process, especially if prompts, workflows or credentials changed. The important thing is not to let permission changes slip through as ordinary feature updates without anyone noticing.
Good question. I'd make the tool manifest machine-readable and diff it in CI rather than rely on an author flag. Any new capability — write access, network egress, shell, or secret access — should fail the check until an owner approves it. The author's note explains intent, but the manifest diff makes permission drift visible and auditable.
Exactly. I'd also make the approval explicit and tied to the specific permission change, rather than a general PR approval. That way, adding a new tool or widening an existing scope can't hide inside an otherwise routine change. The machine-readable diff gives you something concrete to enforce in CI and something useful to audit later.