How to catch out-of-scope coding-agent tasks before execution

Coding agents work across files, roles, and review stages.

Here's a small failure case worth checking before handing a task to an agent:

src/**. secrets/production.txt. The task conflicts with the declared write scope. The useful response is a deterministic preflight failure, before an agent or tool attempts the write.

I maintain Agent Role Contracts (ARC), a small MIT-licensed Node.js library and CLI for checking those declarations. I reproduced the example below on macOS with Node.js 24.11.1 and the pinned v1.0.0 source on October 19, 2026.

Requirements: Git and Node.js 22.5 or newer.

git clone --depth 1 --branch v1.0.0 https://github.com/suirindo/agent-role-contracts.git
cd agent-role-contracts
npm run demo --silent

The demo reads the packaged example declarations and exercises the actual checker. Its relevant output is:

1. Normal task
   Scope: src/example.mjs; allowed: src/**
   PASS: declarations are consistent.
   Implementer: implementer (write_scoped)
   Reviewer: reviewer (read_only; separate declared role)

2. Request an out-of-scope change
   Scope: secrets/production.txt; allowed: src/**
   FAIL (expected): TASK_WRITE_SCOPE_OUTSIDE_AUTHORITY

3. Repair the task scope
   Scope: secrets/production.txt -> src/example.mjs
   PASS: declarations are consistent again.

Demo complete: PASS -> FAIL (expected) -> PASS.
Checks declarations only; execution is NOT authorized.

The example uses fictional paths. It opens no target task file, invokes no model, and performs no agent action. The demo returns exit 0 when it observes the expected PASS → FAIL → PASS sequence.

Run the invalid task directly:

node bin/agent-role-contracts.mjs explain \
  --bundle examples/starter-bundle.json \
  --task examples/starter-task-outside-scope.json \
  --format text

This is an expected failure. The CLI reports:

FAIL: explain (declarations only; execution NOT authorized)
Accountable: implementer
Implementers: implementer
Reviewers: reviewer
Human approval required: true
TASK_WRITE_SCOPE_OUTSIDE_AUTHORITY task/inputs/scope: Task scope is outside declared write scopes for role implementer: secrets/production.txt

Exit status: 1. The shortened output above omits the role-capability detail lines that the CLI also prints.

Try the allowed task:

node bin/agent-role-contracts.mjs explain \
  --bundle examples/starter-bundle.json \
  --task examples/starter-task.json \
  --format text

The checker reports PASS: explain and exits 0. A CLI/input error exits 2. When integrating this preflight into CI or task dispatch, treat exit 1 or 2 as a stop condition and use your runtime's existing permissions and human-approval gates after a valid declaration check.

The shipped declaration checks cover several common workflow inconsistencies:

ARC works offline with JSON inputs. The example is model-agnostic: it can be evaluated alongside a Codex, Claude Code, or other coding-agent workflow, because the check itself invokes no LLM. Integration into an agent runtime remains the responsibility of that workflow's maintainer.

A PASS establishes internal consistency of the supplied declarations under the checks executed. Actual file permissions, actor identity, reviewer independence at runtime, approval authenticity, side effects, and resulting code quality require checks from IAM, sandbox, CI, and runtime/evidence systems.

For instance, an independent reviewer role ID in JSON expresses the intended separation; the execution environment must authenticate the real reviewer. A write-scope declaration needs an actual filesystem/tool boundary to enforce it.

The recently merged external evaluation kit adds a source-only helper pinned to the immutable v1.0.0 revision. It supports the expected scope contradiction, its repair, and a second distinct declaration check with the same bundle. The last step is useful for examining reusability; proof of a second real task still requires an actual second operation or independently linkable CI/commit evidence.

If you already use CI, a sandbox, a reviewer, or another preflight, I'd especially value a comparison on the same deliberate contradiction. A negative result — your current controls catch everything ARC catches — is useful feedback too.

The first external workflow feedback report, Burs-IA WORKNET, described a PASS → rejected scope mismatch → repaired PASS using ARC 0.5.0. That report is operator-provided; separate actual second-task reuse and independent reproduction remain open evaluation goals.

Here are the relevant links:

One concrete question: What mismatch between a coding agent's task, its declared authority, and its review handoff would you most want checked before dispatch? I can help map one small, non-sensitive workflow and compare the result against your existing controls.

Disclosure: I maintain ARC at Netsujo Inc. The example above is a synthetic preflight demonstration; external production adoption and second-task reuse are tracked separately.