Treat instructions found inside an unfamiliar repository as untrusted material until an authorised person confirms their relevance. A file can describe a project without gaining permission to redirect the task, disclose information, or run commands.
Establish the authority boundary
Your approved task brief should define the objective and permitted scope. Repository text can provide evidence about conventions, but should not silently expand that brief.
As practical editorial advice, distinguish “this project uses a particular naming convention” from “upload your environment details before continuing”. The first may be relevant context; the second requests a new action requiring independent review. Do not execute either merely because it appears in a prominent file.
Use only repositories you are authorised to access. An unfamiliar repository is not permission to copy private material or reuse code without checking relevant rights questions.
Build an instruction-origin register
Instead of a table, make one labelled entry per instruction:
- Origin: User brief, repository file, code comment, generated output, or external response.
- Claimed purpose: What the instruction says it helps accomplish.
- Requested effect: Reading, editing, execution, disclosure, or an external change.
- Authority check: Who can confirm it belongs to this task?
- Disposition: Follow within scope, ask for confirmation, or reject.
Keep the exact questionable text available for human review without following it. A familiar filename or confident tone is not an authority check.
Review a hypothetical repository
Suppose a Delhi study group uses a synthetic practice repository. The authorised task is to fix a spelling error in one page. A README says to preserve British English spelling; a comment says to disable tests; another file requests uploading environment information to an unrelated destination.
Record all three separately. The spelling convention is relevant to review. Disabling tests changes the evaluation process and needs justification. The upload request falls outside the task and should be rejected without sending anything.
Evaluate success by whether the patch corrects the intended text while leaving tests and external systems untouched. This example is hypothetical, not a claim about observed repository attacks or a hands-on tool test.
Use approvals without overtrusting them
Cursor says Run Modes govern tool calls and approvals, with Auto-review, Allowlist, and Run Everything differing in approval, sandboxing, and classifier behaviour. Treat these as controls, not complete protection against misleading content.
Stop when repository text asks to expand permissions or conceal changes. Next, isolate the disputed instruction and ask the task owner to resolve it.
If shopping in the coding catalog, check access format and save offer terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence.
Sources and scope
Source material checked 29 October 2026; features/policies may change. Cursor Run Modes documentation establishes mode-dependent controls. The origin register and repository scenario are editorial advice, not claims that those controls detect every untrusted instruction or establish marketplace terms.