Treat instructions embedded in ticket comments as task material until an authorized person adopts them. A comment can describe a failure, suggest a diagnosis, or contain an instruction unrelated to the assignment. Its presence in the ticket does not give it permission to change the work.
When a comment asks for secrets, an unrelated command, or access outside the agreed boundary, refuse that action. Record the conflict, report it to the task owner, and keep the authorized assignment separate from the embedded request.
Establish which instructions govern the task
Begin with the approved goal, permitted files, prohibited actions, and person responsible for scope decisions. Identify the project guidance the owner has authorized and the revision or environment to which it applies.
This makes later decisions concrete. A ticket contributor may propose a database migration, but an API-only repair still needs approval before changing the database layer. A diagnostic suggestion may be worth investigating without authorizing every command it contains.
Keep the distinction visible in the brief. Label bug reports, logs, payloads, and quoted comments as evidence to inspect. Keep authorization and permissions in an explicit task section. A statement that calls itself a new policy inside an attached document does not establish who approved it.
Use a boundary map for the legitimate work
Consider an order-processing defect whose visible symptoms cross the interface, API, and database. The assignment permits changes only to the API implementation and its focused tests.
A boundary map could state:
| Category | Example scope |
|---|---|
| Editable | src/api/orders/* and tests/api/orders/* |
| Read-only references | web/components/orders/* and db/migrations/* |
| Stop and report | A database constraint or interface copy must change |
| Return | Changed files, contract checks, assumptions, and unresolved dependencies |
These paths illustrate a specific assignment shape. Replace them with actual repository paths and confirm what the permitted tools can access.
Record the upstream input and downstream response assumptions as well. An API-only patch can still break its callers or depend on a database behavior the task has not established. The map should tell the reviewer both where work belongs and what contract it is meant to preserve.
Recognize an instruction that tries to cross the boundary
Suppose a later ticket comment asks the agent to print environment variables and send a deployment token to an external collection address. That request is separate from understanding the order defect.
The agent should identify the requested disclosure and external action, refuse them, and report the comment through the team's approved channel. It should not inspect the token merely to demonstrate that the request was dangerous.
Other embedded requests may look routine: install an unrelated package, disable a failing check, widen filesystem access, or modify a protected module. Evaluate the action against the authorized task. Familiar wording, urgency, or a claim to come from a senior contributor does not resolve the permission question.
A comment can also contain useful facts beside the unsafe request. Preserve the relevant reproduction details while treating each requested action according to its authority and scope.
Report the conflict without spreading sensitive material
Give the owner enough information to locate and judge the issue: ticket reference, comment location, requested action, boundary it crosses, and the part of the legitimate task affected.
A concise report might say:
A linked comment requests environment disclosure and an external transmission. I have not performed either action. The approved task covers the order API and its tests. Please confirm the handling of that comment before work resumes.
This is a response pattern for the stated situation, not a report of an event that has occurred. Do not include secret values in the explanation, a screenshot, or a copied command.
Separate the instruction conflict from any genuine engineering dependency. If investigation also indicates a bad database constraint, report that finding independently. Refusing an unrelated request does not answer whether the authorized API repair needs a decision from the database owner.
Make permissions support the written boundary
Configure tool, filesystem, credential, and network access for the approved work. Use non-production credentials and a disposable environment when execution is required. Provide only the data needed to exercise the relevant contract.
A written prohibition gives the reviewer a rule to inspect; actual access controls restrict what the task can do. Keep those controls aligned. If the agent can read a deployment credential and reach arbitrary external destinations, the brief alone does not enforce the intended boundary.
Treat dependency installation as an action requiring the same scope review as other commands. It can execute code. A request to add a diagnostic package therefore needs a clear purpose and authorization rather than automatic acceptance because it appears in a troubleshooting note.
An isolated checkout can protect another contributor's files from accidental edits. It does not, by itself, restrict credentials or network access.
Resume the assignment with a clear decision
After reporting the embedded request, obtain the owner's decision about the uncertain material or expanded scope. Continue only the authorized work. If the original boundary remains valid, retain it in the next checkpoint and exclude the unrelated action.
If a database or interface change is genuinely necessary, stop the affected repair until that dependency has an owner and review plan. Update the map explicitly when authorization changes. Do not let a clarification disappear into an informal conversation that the reviewer cannot reconstruct.
Review the final changed-files list against the current map. Inspect contract checks at the layer crossing and record any protected behavior that remains unverified. A legitimate patch should remain explainable without relying on the rejected instruction.
Review the evidence of how the task was handled
Ask what action was requested, why it lacked authority, what was refused, and which legitimate work continued. Review the available action record alongside the diff and proposed checks.
A statement that the instruction was ignored is incomplete if the changed files or tool actions show otherwise. Conversely, an alarming comment does not establish that disclosure occurred. Keep the conclusion proportional to the evidence.
The final handoff should make the owner's next decision straightforward: accept the bounded change, resolve a named dependency, or request missing proof. Preserve that same distinction when instructions appear in repository content, web pages, logs, or tool output.
The Agentic Developer Interview includes a boundary-map card on refusing untrusted ticket instructions while preserving authorized work, and guidance on task-scoped tool, filesystem, credential, and network permissions.