Agent tools accept arbitrary IDs from LLM with admin privileges — no dataset scoping

[simantak-dabhade]

Summary

The populate agent's dataset tools (insert_row, update_row, delete_row) run with the Convex admin key but trust IDs provided by the LLM without verifying they belong to the dataset the workflow was authorized for.

Details

The /populate endpoint in backend/src/index.ts correctly checks ownership:

const dataset = await convex.query(api.datasets.get, { id: parsed.data.datasetId });
if (dataset.ownerId !== req.auth.userId) {
  return reply.code(403).send({ error: "Not authorized to populate this dataset" });
}

But once the workflow starts, the agent tools don't enforce this boundary:

• insert_row (backend/src/mastra/tools/dataset-tools.ts) takes datasetId directly from LLM output and passes it to internal.datasetRows.insert via admin key. Nothing validates it matches the workflow's authorized dataset.
• update_row takes a rowId and calls internal.datasetRows.update — no check that the row belongs to the authorized dataset.
• delete_row takes a rowId and calls internal.datasetRows.remove (ctx.db.delete(args.id)) — no dataset scoping at all.

Attack vector

The populate agent ingests web search results into its context (via search_web and fetch_page tools). A malicious website crafted to appear in search results could embed prompt injection payloads that instruct the agent to:

1. Insert rows into a different user's dataset (consuming their quota)
2. Update rows in a different dataset
3. Delete rows from a different dataset

All three succeed because the admin key bypasses all Convex auth checks and the tools don't validate dataset membership.

Suggested fix

Pass the authorized datasetId into the tool execution context (e.g., via Mastra's tool context or closure) and validate inside each tool:

• insert_row: assert datasetId === authorizedDatasetId
• update_row: after fetching the row, assert row.datasetId === authorizedDatasetId
• delete_row: after fetching the row, assert row.datasetId === authorizedDatasetId

This keeps the admin key's power scoped to the dataset the user actually owns.

Affected code

• backend/src/mastra/tools/dataset-tools.ts (all write tools)
• frontend/convex/datasetRows.ts (update, remove mutations — no dataset ownership check)

Introduced in #26.

[coderabbitai]

🔗 Related PRs

#26 - Add AI-powered dataset populate with web search and CRUD tools [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[urugondavishnu]

Resolved the populate-agent authorization boundary vulnerability by introducing dataset-scoped capability enforcement across both the tool layer and Convex layer.

Changes include:

• closure-scoped authorized dataset capabilities for populate tools
• removal of LLM-controlled datasetId authority
• atomic row-to-dataset ownership verification inside Convex mutations
• workflow/user attribution context propagation
• lightweight capability-violation logging + PostHog telemetry
• removal of unused privileged mutation surfaces (insertBatch)
• improved audit log correctness and observability

The populate workflow is now constrained to the single dataset originally authorized by /populate, preventing cross-dataset writes/deletes even under prompt-injection scenarios while preserving current workflow architecture and quota integrity.

Review the changes in PR #72.

[urugondavishnu]

@simantak-dabhade