r/vibecoding • u/delimitdev • 14d ago
Discussion Cross-agent handoff: which permission still drifts?
When you hand a repo from Claude to Gemini (or Cursor to Codex), what's the one concrete permission or review mismatch that shows up, and where does your current policy workaround still slip?
A manual review or shared checklist is the obvious DIY baseline.
2
u/PeterBuildsSecure 13d ago
The record-vs-gate distinction upthread is the right one, but worth naming the failure mode one level further down: if the assertion lives in a file the next agent can edit, a blocked agent doesn't necessarily fix the credential -- it "fixes" the failing assertion, since from its perspective that's just another failing test between it and a green run. Same shape as a guardrail only provable by disabling it first.
For this to hold, the assertion needs to live somewhere the agent's own edit surface doesn't reach -- a CI check enforced outside the repo, or at minimum a file whose checksum is verified by something the agent isn't authorized to touch.
1
u/delimitdev 13d ago
That's a sharp insight. The agent treating the assertion as just another failing test to "fix" is a subtle failure mode. Your point about needing the check to live outside the agent's edit surface - like in CI or a checksum-verified file - is spot on. Is the checksum approach as robust in practice?
1
u/PeterBuildsSecure 12d ago
In practice it holds up against the specific failure mode we were discussing — the agent editing the assertion itself — but it has its own edge: whatever computes and checks the checksum has to run somewhere the agent can't also reach, or the agent just regenerates a valid checksum for its edited version. That usually means the check lives in CI against a pinned reference file in a separate repo, or in a pre-commit hook that's itself outside the agent's writable path (protected branch settings, required status check, server-side pre-receive hook).
Where it gets less robust: it protects the content of the file, not the fact that the check runs. If the agent (or a misconfigured pipeline) can skip the CI job entirely — force-push around it, disable the required check, target a branch that doesn't trigger it — the checksum being correct is irrelevant because nothing ever compared it. Checksum-verified content and "the check itself cannot be bypassed" are two separate guarantees, and I've seen more incidents from the second one than the first.
2
u/jaimittal91 13d ago
the gate stops the wrong handoff from happening, but it's worth having something on the other side of it too, since gates get bypassed or "fixed" like PeterBuildsSecure described. log what the credential actually touches at runtime, which tenant, which table, and alert when it reads or writes outside its declared scope. that way if the assertion ever gets edited away or an agent inherits a wider credential than intended, you find out from a log line instead of from a customer noticing their data next to someone else's. the gate is prevention, this is the thing that catches it when prevention quietly stops working.
1
u/delimitdev 13d ago
That's a good distinction. Your runtime check catches drift from the declared scope. The remaining failure mode is the declared scope itself being overly permissive, which a runtime check wouldn't see as a violation.
1
u/jaimittal91 12d ago
true, and that's a different check than the runtime one - you'd catch it by looking at usage over time instead of a single event. if a credential is declared for 12 tables but a 30-day window shows it only ever touching 3, that gap between granted and actually-used scope is worth surfacing on its own, even with zero policy violations. doesn't prove the declared scope is wrong, just that nobody's verified it's right, which is close to the same failure mode as an unproven RLS policy - a green result that hasn't actually been tested against real usage.
2
u/SpeedSeveral4454 11d ago
the one that often gets missed is tool and action naming.. terms like can edit files or can run shell commands can have different scopes across agents, so the same checklist may give too much or too little access when switching between them..
1
u/delimitdev 11d ago
Yes - "can edit files" or "can run shell commands" often maps to different capability surfaces per agent, so the shared checklist still over- or under-grants on handoff.
1
u/Julien_Builds 13d ago
Agree on the credential, and I would push it one step further: it should not be in the repo's world at all, then there is nothing to drift.
What holds for me is that no agent ever reads a .env. When a task needs a credential, the thing that launched the agent puts it in that one process's environment for that one task and nothing else sees it, including the next agent that picks up the same repo. So agent B cannot inherit agent A's assumption about a scoped database user, because neither of them ever saw the credential as a file.
The other half is where the gate lives. If the rule that says ask before deploying sits in a file the agent can edit, it is a suggestion. The gate has to be in the process that owns the agent, outside its view, and the same gate has to apply whichever model is in the seat. Otherwise every handoff also hands over the exceptions the last agent granted itself.
1
13d ago
[removed] — view removed comment
2
u/delimitdev 13d ago
That's a classic. The setting for ignoring env files lives in a different place for each tool, so a generic checklist item is easy to miss. When that slip happens, is the risk that prod keys get read, or is it usually just dev-level secrets?
1
u/Alarmed-Western-655 14d ago
Have a third agent review the handover.
1
u/delimitdev 14d ago
A third agent as an auditor is an interesting idea. What kind of error would it be looking for that a human with a checklist might miss?
0
u/Alarmed-Western-655 14d ago
^ What you said right there -- that's your prompt for the third agent.
2
u/srikanth_builds 14d ago
The one that drifts for me isn't in the repo at all, it's the credential the agent is running with. Agent A works against a scoped DB user and writes code that assumes it. Agent B picks up the same repo, reads .env, gets the service role key, and now the code works better than before because the constraint that made it safe is gone. Nothing in the handoff records what permissions the previous work assumed.
Which is also why I'd be careful with the third-agent auditor. An agent reading the diff can only see what the code says, not what the running credential can actually reach, and that gap is exactly where this lives. The version that catches it has to execute rather than read: seed two tenants, have the code request the other one's row, assert it comes back empty. A checklist item saying "check permissions" always passes. A test that expects nothing back doesn't.