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

A developer maintains Agent Role Contracts (ARC), an MIT-licensed Node.js library and CLI that performs deterministic preflight checks on coding-agent task declarations before any write executes. In a reproduced demo on Node.js 24.11.1 with the pinned v1.0.0 source, a task targeting secrets/production.txt against a declared src/** write scope fails with TASK_WRITE_SCOPE_OUTSIDE_AUTHORITY and exit code 1, while an in-scope task passes with exit 0; the tool invokes no LLM and checks declarations only, leaving runtime permissions and approval gates to the surrounding workflow.

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 https://github.com/suirindo/agent-role-contracts , 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: | Supplied declarations | Example of a detectable mismatch | |---|---| | Implementer write authority + task scope | Requested path exceeds src/ | | Implementer + reviewer roles | Same declared role assigned to both | | Reviewed task/action + binding | Task or action changed after its declared review binding | | Handoff and lifecycle declarations | Declared task/subject relationships become stale | 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 https://github.com/suirindo/agent-role-contracts/tree/main/experiments/external-evaluation 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 https://github.com/suirindo/agent-role-contracts/issues/45 , 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.