Before Your AI Agent Writes a File, Check Its Task Scope

Imagine an AI coding agent assigned to modify files inside src/**.

Its next task requests a change to secrets/production.txt.

The agent has received instructions, but the task conflicts with its declared scope.

Can we catch this contradiction before execution?

That's one of the problems we're working on at Netsujo.

Introducing Agent Role Contracts

Agent Role Contracts (ARC) is an MIT-licensed, open-source tool for deterministic pre-execution checks of AI-agent workflows.

ARC can detect contradictions involving:

• Declared permissions and task scopes
• Implementation and independent review roles
• Stale handoffs and task bindings
• Inconsistent action declarations

The checks run offline and produce reproducible diagnostics.

Try it in three minutes

With Git and Node.js 22.5 or newer:

git clone https://github.com/suirindo/agent-role-contracts.git
npm --prefix agent-role-contracts run demo --silent

The demo shows three outcomes:

PASS → FAIL → PASS

1. A task within its declared scope passes.
2. An out-of-scope task is rejected.
3. Repairing the task declaration restores a passing result.

ARC validates declared contracts. Runtime identity, actual permissions, enforcement, and execution approval remain separate responsibilities.

We're looking for real-world feedback

ARC v1.0.0 is available now.

We're especially interested in developers working with coding agents and multi-agent systems.

Where do responsibilities, permissions, or review boundaries become difficult to manage?

Which checks are already covered by your runtime or CI infrastructure?

We welcome both positive and negative evaluation results.

Try ARC: https://github.com/suirindo/agent-role-contracts

Evaluate a real workflow: https://github.com/suirindo/agent-role-contracts/issues/37

If you find the project useful and want to support its continued development:

GitHub Sponsors: https://github.com/sponsors/netsujo-inc

---

Developed by Netsujo in Kyoto, Japan.

This article was prepared with AI writing assistance and reviewed by the Netsujo team before publication.

Comments

[Gautam K]

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?

[asagiman]

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.

[Gautam K]

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?"

[asagiman]

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.

[Gautam K]

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 hold rule adds anything whose consequences you care about (for example POST /repos/*/*/releases), deny refuses it outright, and an allow list or readOnly keeps 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.

[asagiman]

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.