Imagine an AI coding agent assigned to modify files inside src/**.
Its next task requests a change to secrets/production.txt.
The agent has recei...
For further actions, you may consider blocking this person and/or reporting abuse
Nice framing: catching the contradiction before execution is much cheaper than catching it after.
The case I keep running into is the one that passes a scope check: the call is inside the declared scope but it can't be undone (deleting a volume in a project the agent is allowed to touch, a force push to a branch it owns). Do you see ARC staying purely declarative, or pairing with a runtime hold for irreversible calls that are technically in scope?
Thanks, Gautam. You’re right: being inside the allowed scope does not make a deletion or force-push safe.
ARC currently checks declarations. It does not classify those operations by reversibility or provide a runtime hold. I see it as one check before execution, alongside a runtime layer that can pause the specific operation and verify the required approval. An ARC PASS alone should never be treated as permission to perform a destructive action.
In your current workflow, how do you decide which in-scope operations require an explicit human approval? A non-confidential example would help clarify where the declaration check ends and the runtime safeguard needs to begin.
Good question. I decide by reversibility, not by scope. Reads and normal writes go straight through. Anything that can't be taken back waits for a human: deleting a repo, branch or database, a force push to main, a refund or a payout.
A non-confidential example from what I'm building (Counterseal): an agent can open a PR and push to its own branch freely, but a force push to main gets held, and my passkey approval covers that one exact request, once.
So I'd draw the line where you did. The declaration check answers "is this in scope?" The runtime check answers "can this be undone, and did a human say yes to exactly this?"
That's a useful distinction, especially the passkey approval bound to one exact operation.
I think reversibility is a strong signal, but I'd also consider effects that can't truly be undone, like exposing sensitive data or triggering an external action.
We're exploring this boundary in ARC's runtime adapter work: checking the actual operation against its authorized scope, intended effects, and approval before execution.
Curious how Counterseal handles cases where an operation is technically reversible but its consequences aren't.
Good point, and I agree reversibility alone isn't enough. A sent email, a published release or a repo made public can't really be undone, even if the API has an undo.
In Counterseal that's a policy decision per token. The built-in map holds calls that can't be taken back. A
holdrule adds anything whose consequences you care about (for examplePOST /repos/*/*/releases),denyrefuses it outright, and an allow list orreadOnlykeeps the agent away from data it shouldn't touch. Every hold still needs a passkey for that one exact request.The honest limit: it decides per API call, so it can't see consequences that happen downstream. Someone has to name those calls. I'd be curious whether ARC's intended effects check could help fill that gap.
Thanks, Gautam. I should clarify my earlier wording: the intended-effects check I mentioned is a direction we’re exploring, not a capability I can claim ARC already provides. ARC’s current core checks explicit declarations.
The possible complement is narrower: checking whether a declared proposed action matches the approved task. For example, “draft a release” versus “publish a release.” That depends on accurate declarations; it wouldn’t discover hidden downstream consequences or replace Counterseal’s runtime authorization.
Have you encountered a request that token policy permits, but that should still be held because it exceeds the approved task? A public or synthetic example would help us see whether another check adds value. Thanks for explaining the boundary so clearly.