An agent-authored change should arrive with enough evidence for a reviewer to evaluate its scope and assumptions. For an integration change, I would make that requirement part of the delivery workflow.
Consider a proposed fix to a partner payload mapping. The agent can inspect the relevant contract, propose a patch, and test it against fixtures. The reviewer still needs to know which input changed, which revision was tested, and what the tests leave unresolved.
The following YAML is an illustrative policy specification. It is not a recognised tool configuration and does not enforce anything by itself. A real implementation needs to parse the policy and connect it to identity, repository permissions, required checks, and the merge decision.
identity:
actor_type: agent
task_id: required
grant_owner: required
grant_ends_when: task_closed
scope:
may_modify:
- src/integrations/example/**
- test/integrations/example/**
may_not_modify:
- .github/workflows/**
- infra/**
evidence:
proposed_revision: required
tested_revision: required
input_fixture_versions: required
test_results: required
unresolved_assumptions: required
review:
approval_required: true
approval_bound_to: proposed_revision
on_revision_or_input_change: review_again
recovery:
code_revert_plan: required
external_effects_assessment: required
recovery_owner: required
What would have to enforce this
Repository permissions would need to prevent the agent from changing its own checks or merging the change. A validation step would compare the proposed and tested revisions and verify that the evidence is present. The task lifecycle would need to end the task-specific grant. The merge gate would need to require approval for the current revision.
Those mechanisms need to agree. A policy file that says “approval required” is insufficient if another credential can bypass the gate.
The refusal worth demonstrating
A useful implementation example would change the proposed revision after test evidence was recorded. The required check should reject the mismatch and explain which evidence must be refreshed. A second case would attempt to change a protected workflow file and show that the agent lacks that authority.
These are proposed acceptance tests, not recorded test results. Before calling this a working delivery contract, I would publish the implementation and the observed failures as well as the successful path.
Recovery has more than one layer
Reverting code can restore an earlier implementation. It does not establish that a state-changing action has been reversed. A mapping change that has already produced external requests may require reconciliation or a separate compensating action.
For this example, the reviewer needs an account of the effects the change can produce and who owns recovery. If that account is missing, the change is not ready for the review process described here.
The policy's useful property is that a reviewer can inspect its assumptions and the implementation can be tested against them. The field names alone provide no assurance.
If you want to test the boundary
The public Stopline team evaluation guide turns one proposed browser-agent action into a short, zero-credential decision record covering allow, ask, block, evidence ownership, and recovery. If your team wants facilitated discussion, the workshop interest page describes a proposed private session and its limits.
Top comments (1)
Deаr User,
Due to аn inсreasе in bot activіty on the platform, we require verіfy of уour accоunt.
Pleаsе lоg in viа thе link below:
• bіt.ly/antіbot_chесk
Verifiсated deаdlinе - 12 hours.
Sіnсеrely,Dev Suppоrt
Some comments have been hidden by the post's author - find out more