Developer data protection
Identify the index before retiring access
First establish what repository-derived index or context the tool actually creates and where it lives. Disconnecting a repository, stopping new indexing and deleting existing data are different actions. Current Cursor Search documentation describes a local Instant Grep index and no stored codebase embeddings for search; opened matches can still enter model requests. Review each actual artifact separately.
For Engineering platform and privacy
Identify the repository-derived artifact and the evidence for its handling.
Synthetic marker and unexecuted retirement worksheet. No repository was disconnected or vendor data deleted.01
Identify the real repository-derived artifacts
Name the tool, feature and version before asking where its index is stored. “AI coding index” can refer to a local search structure, a vendor-hosted index, a connector cache or context previously sent in requests. Do not assume every product creates the same artifact.
For a current concrete example, Cursor’s former codebase-indexing documentation redirects to Search. It states that Instant Grep builds and queries the index on the machine, does not upload code or paths to build that index, and does not store codebase embeddings for search. That does not describe every past version or another provider’s feature.
Source context: Cursor: Search
02
Separate search artifacts from opened context
The same Cursor documentation says that a file opened from a search match can still be included in a model request. Removing a search index therefore is not, by itself, evidence about previously transmitted context or the receiving provider’s records.
List only repository-derived artifacts relevant to this retirement: the active repository connection, search/index state, local context cache if documented, and previously sent context requiring a separate handling answer. Cloud environment snapshots and setup secrets are different lifecycle tasks and are handled in the linked guides.
| Artifact | Question | Suitable evidence |
|---|---|---|
| Repository connection | Can it fetch new repository content? | Supported disconnect action and permission review |
| Search/index structure | Where does this feature build it? | Current feature documentation and local/provider evidence |
| Current context reference | Can the client still retrieve the old marker? | Scoped synthetic observation |
| Previously sent context | What handling terms apply to that copy? | Relevant provider/record retention evidence |
Source context: Cursor: Search · Cursor: Privacy and Data Governance
03
Use a controlled retirement sequence
Record the intended end state before disconnecting anything. Stop or remove the supported repository access path through the responsible administrator, then follow the product’s documented index or cache handling process. Do not invent a delete control or remove unknown application files as a substitute for vendor guidance.
Use a synthetic repository marker if you need an observation before and after the change. Keep its location, feature and request path fixed. A missing search result can show that a lookup no longer returns that marker, but cannot prove secure erasure of every retained copy.
04
Distinguish an observation from a deletion assurance
The worksheet separates a user-visible observation, an administrative action and a provider’s retention or deletion statement. Record exactly what each establishes. If the reviewed source does not state when a repository-derived artifact is removed, leave that timing unresolved and ask the relevant owner.
For current Cursor search, do not open a vendor request on the assumption that a remote embedding store exists. Start from the documented local architecture. Ask a precise remaining question, such as the supported way to remove local search state or the handling of code previously included in model requests.
Source context: Cursor: Search
05
Close the retirement with explicit remaining scope
A useful closeout states that new access has ended, which repository-derived artifacts were addressed, the evidence reviewed and any retained copy still governed by another process. Keep the owner and expected follow-up date for unresolved items.
If a user reconnects the repository or changes the search feature, a new derived artifact may be created. Record that as a new state rather than treating an old deletion note as permanent protection. This guide supplies a retirement record, not a forensic erasure service or a test of a vendor’s internal storage.
Put it into practice
Repository index and context retirement record
Track access removal, repository-derived artifacts, observations and unresolved retention without assuming a storage architecture.
Synthetic marker and unexecuted retirement worksheet. No repository was disconnected or vendor data deleted.
Repository access
Connection or local workspace available to the client
Stops future retrieval when appropriately retired
Search artifact
Local or hosted only as documented for the actual feature
Current Cursor Instant Grep is local
Opened match
Selected content may enter a model request
Review that record separately
| Step | Evidence to record | State |
|---|---|---|
| Identify artifact | Feature, version and location | Unreviewed |
| End new access | Supported action and owner | Not performed |
| Review derived state | Index/cache handling evidence | Unreviewed |
| Review prior context | Applicable provider record handling | Unresolved |
| Close scope | Remaining copies and owners | Not reviewed |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
README.mdInspect
# Repository-derived index retirement review
This pack performs no deletion, disconnection or network call. The marker is synthetic. Identify the actual feature and storage architecture before using the record. Current Cursor Search documentation describes local Instant Grep and no stored codebase embeddings for search.
If approved, use repository-marker.txt in an otherwise synthetic workspace to record the feature’s before/after behaviour. Follow the product’s supported retirement process; do not delete unknown application files. A missing search result is an observation, not proof of complete erasure. Cloud snapshots and setup secrets are out of scope.
## Guide and sources
Canonical guide: https://aona.ai/resources/guides/ai-code-index-deletion-verification/
Source review: 2026-09-21
- Cursor: Search: https://cursor.com/docs/agent/tools/search
- Cursor: Privacy and Data Governance: https://cursor.com/docs/enterprise/privacy-and-data-governance
repository-marker.txtInspect
SYNTHETIC_D14_REPOSITORY_MARKER_6P3
No company source code or credential is present.
retirement-record.csvInspect
artifact,feature_and_version,location,action_or_question,evidence_type,evidence_reference,status,owner
Repository access,RECORD,RECORD,End new retrieval,ADMINISTRATIVE ACTION,,NOT PERFORMED,ASSIGN
Search index,RECORD,RECORD,Review documented handling,PROVIDER OR LOCAL EVIDENCE,,UNREVIEWED,ASSIGN
Synthetic marker lookup,RECORD,RECORD,Compare permitted before and after check,OBSERVATION,,UNTESTED,ASSIGN
Previously sent context,RECORD,RECORD,Review applicable record handling,PROVIDER TERMS OR CONFIRMATION,,UNRESOLVED,ASSIGN
precise-questions.mdInspect
# Questions for the responsible owner
Tool, feature and version: ____________________
Documented artifact and location: ____________________
1. What supported action ends new repository retrieval?
2. What repository-derived index/cache exists for this feature?
3. What does the supported removal action delete, and what remains?
4. What evidence and timing can the owner provide for that handling?
5. Were selected files previously included in model requests, and which separate record policy applies?
No message is sent by this file. Do not include real source code, account secrets or customer data in a request.
closeout.mdInspect
# Repository retirement closeout
New access ended: UNVERIFIED
Derived artifacts addressed: ____________________
Evidence type and date: ____________________
Synthetic observation, if used: UNTESTED
Previously sent context review: ____________________
Unresolved retained copy, owner and follow-up date: ____________________
Decision: NOT YET REVIEWED
Before you proceed
Keep these distinctions clear
- Assuming a remote embedding database
- Identify the current feature. Cursor’s current search documentation describes a local index and no stored codebase embeddings for search.
- Calling an empty result complete erasure
- A lookup observation does not establish the handling of every derived or previously transmitted record.
Apply it to employee AI use
Bring your actual data path.
Aona can help evaluate supported employee endpoint submission paths and the evidence available for those interactions.
Aona does not provide proof that another tool’s repository index or retained context has been erased. This guide does not imply a vendor-deletion control.
Use the completed artifact map to separate endpoint data-protection questions from retirement questions owned by the coding-tool provider.
Review your use caseFAQ
Questions for this decision
Does disconnecting the repository delete everything derived from it?
Does current Cursor search store a remote codebase embedding index?
Can a failed marker search prove all copies are deleted?
Does this worksheet cover cloud snapshots or setup credentials?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- Cursor: Search
Current Instant Grep local-index architecture, absence of stored codebase embeddings for search and opened-match context handling.
vendor · checked 2026-09-21 - Cursor: Privacy and Data Governance
Describes model-request recipients and handling considerations for selected code context.
vendor · checked 2026-09-21