Accept an AI-proposed dependency only after you can explain its necessity, identify its provenance and approve the installation action separately. A convincing generated explanation is not evidence that the package is appropriate for your application.
Start with the smallest necessary change
Practical editorial advice: ask what requirement the dependency satisfies and what happens without it. Compare an existing project utility, a small implementation and an external package. Do not automatically prefer fewer packages; prefer a decision that accounts for complexity and ongoing ownership.
For an Indian storefront, formatting a rupee amount and processing a payment are different problems. A presentation-only requirement should not silently expand into payment integration or remote data transmission.
Record the intended package name and version precisely. Similar-looking names are not interchangeable evidence of origin.
Complete a dependency acceptance card
Use this worksheet before approving installation:
- Necessity: which acceptance requirement needs this package? What alternative was considered?
- Provenance: where did the exact name and version come from? Who independently checked the identity?
- Maintenance: what evidence supports continued use, and who will review updates or replacement?
- Scope: is it needed during development, during builds or in the running application?
- Permissions: what would the proposed command read, write, execute or contact?
- Rights review: what licence questions should the project owner resolve before adoption?
- Exit: how would the team remove the package if it becomes unsuitable?
Mark unanswered fields as unresolved, rather than filling them with the agent's confidence level. Keep the card with the code review so later maintainers understand the choice.
Hypothetical installation review
Suppose a generated expense dashboard proposes a fictional package, rupee-display-helper, solely to display ₹1,250.00. The proposed change also modifies the lockfile and includes an installation step.
Evaluate three concrete inputs: the required display examples, the dependency diff and the proposed command. If the existing application can meet the examples without a new dependency, ask for that alternative. If the package remains justified, review its identity and installation effects before proceeding.
Stop if the reviewer cannot identify the package or explain the command's permissions. The next step is clarification, not a broader execution approval.
Keep execution approval separate from selection
Cursor documents mode-dependent agent execution: Run Modes govern tool calls and approval requests; Auto-review, Allowlist and Run Everything differ in approval, sandboxing and classifier behaviour. This does not establish that any particular dependency is safe.
If comparing access offers, check the coding catalog for access format and saved terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence or of a suitable security configuration.
Sources and scope
Source material checked 29 October 2026; features/policies may change. Cursor Run Modes establishes configurable agent execution and approval behaviour. The acceptance card, package example and stop rule are editorial advice, not a documented package-verification service.