Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,7 @@
## AI

* [Overview](ai/overview.md)
* [Data Usage and Consent](ai/data-usage-and-consent.md)
* [MCP Server](ai/mcp-server.md)
* [Agent Skill: Playwright Best Practices](ai/agent-skill-playwright-best-practices.md "Playwright Skill")
* [IDE Extension](ai/ide-extension.md)
Expand Down
68 changes: 68 additions & 0 deletions ai/data-usage-and-consent.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
---
description: >-
What test data Currents sends to an AI provider, when it is sent, and how
organization admins grant or revoke consent
icon: shield-check
---

# AI Data Usage and Consent

Currents' AI features work by sending part of your test data to a large-language-model provider. That only happens after an administrator of your organization consents to it. Until then, the AI features stay off for everyone in the organization.

This page describes what is sent, when, and who controls it.

## What is sent

When an AI feature runs on a failed test, Currents sends the troubleshooting context it assembled for that test:

* The error message, stack trace, and code frame from the failed attempt
* The **error-context snapshot** captured at the moment of failure: the page accessibility tree, console output, and network logs
* Source code snippets referenced by the stack trace
* Test, spec, and run identifiers, along with the test's title and file path
* Historical pass/fail and flakiness data for that test

Nothing is sent on a schedule or in the background. A request is made only when someone opens an AI feature on a specific test, or when an automation you configured requests one.
Comment on lines +16 to +24

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is sent describes only a single failed test's troubleshooting payload, while other supported AI entry points handle multi-test bundles, snapshots, metrics, and org/project-scoped run, history, and analytics data, so readers may consent without understanding most transfers. Should we document each entry point's payload (or a shared envelope with optional collections), distinguish MCP/API reads from data sent to an AI provider, and state when each is triggered?

Severity

Want Baz to fix this for you? Activate Fixer You can also update your AI coding guidelines based on this comment by apply pr to [branch name]

Other fix methods

Fix in Cursor

Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
`ai/data-usage-and-consent.md` around lines 16-24, revise the "What is sent" and
request-trigger descriptions so they cover every supported AI entry point instead of
presenting a single failed test as the complete data flow. Document the distinct payload
variants (or a common envelope with optional collections): single-test troubleshooting;
run-level `Fix all failures` (up to 25 failing tests and up to 5 snapshots); spec-level
`Fix spec failures` bundling all failed and flaky tests with their errors, identifiers,
histories, snapshots, and attachments; `Test Explorer` flaky/slow test metrics; `Analyze
with Currents` data for every test definition; and MCP/n8n queries and prompts for run
history, flakiness, and performance analytics. Distinguish which of these only
read/expose data directly via MCP/API versus which assemble a payload sent to an AI
provider, qualify when each is triggered, and cross-check the wording against the linked
IDE documentation and AI overview to ensure the consent scope is accurate — or
alternatively, explicitly scope this section to only the dashboard/Slack/IDE Fix-with-AI
payloads and add a separate description of the broader data MCP/n8n integrations can
retrieve and forward.


{% hint style="warning" %}
This data comes from your test run, and Currents sends it as captured. If your tests log credentials, tokens, customer records, or other sensitive values into errors, console output, or network logs, those values are part of what gets sent.

Treat the consent decision as covering whatever your tests produce, and keep secrets out of test output regardless of whether AI features are enabled.
{% endhint %}

## Where it is sent

Currents sends the context to an LLM provider over an API call. The default provider is OpenAI; self-hosted and enterprise deployments can point Currents at a different OpenAI-compatible endpoint — an LLM gateway, Azure OpenAI, or another provider — via configuration.

Your test data is not used to train models. Requests are made through the provider's API, which is covered by the provider's API data-handling terms rather than its consumer-product terms.
Comment on lines +32 to +36

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The no-training/provider guarantee conflates Currents-managed backend calls with customer-controlled agents and providers, while currents.apiBaseUrl points to the Currents REST API rather than an LLM endpoint, so customers may assume external AI payloads are covered by Currents’ Service Agreement. Should we scope the guarantee to covered paths and either add a real provider endpoint/contract or remove the configurability claim tied to currents.apiBaseUrl?

Severity

Want Baz to fix this for you? Activate Fixer

Other fix methods

Fix in Cursor

Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
`ai/data-usage-and-consent.md` around lines 32-36, rewrite the "Where it is sent"
section to accurately reflect the released architecture: (1) distinguish any
Currents-managed backend requests to a configured LLM endpoint from the dashboard,
Slack, IDE, MCP, and n8n flows that hand prompts/context to customer-controlled agents
or providers (e.g. Cursor, Copilot, Claude Code) — do not imply Currents transmits
every AI payload or that the OpenAI/provider API terms govern those external handoffs;
(2) remove or qualify the blanket guarantee that data is never used for training and is
covered by the linked Currents Service Agreement, since that agreement cannot govern an
independently selected provider — scope it by endpoint/provider or state clearly that
Currents cannot guarantee those settings for self-selected providers; (3) do not
reference `currents.apiBaseUrl` as a way to configure an OpenAI-compatible provider,
since it is documented elsewhere as the Currents REST API base URL — either implement
and document a real separate provider endpoint/contract, or remove the configurability
claim entirely.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commit 3cd35ef addressed this comment by removing the currents.apiBaseUrl provider-configuration reference and distinguishing provider API terms from consumer-product terms. However, the no-training guarantee and broader provider configurability remain insufficiently scoped.


## Who can grant consent

Only **organization administrators** can change the consent setting. The decision applies to the entire organization: every project, every user, every AI entry point.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Skill is misclassified as consent-controlled AI

The page treats the instruction-only Playwright SKILL.md as a data-sending AI entry point, while an external agent using the MCP server can retrieve Currents data and send it to a provider Currents cannot control — should we distinguish the Skill from data-sending features and state that limitation, per CLAUDE.md and AGENTS.md?

Severity

Want Baz to fix this for you? Activate Fixer You can also update your AI coding guidelines based on this comment by apply pr to [branch name]

Other fix methods

Fix in Cursor

Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
ai/data-usage-and-consent.md around line 40, revise the organization-wide consent scope
statement to distinguish Currents-controlled, data-sending AI features from the
instruction-only Playwright Skill, whose SKILL.md guidance does not itself send test
data. Also explain that an external agent using the separately documented MCP server may
retrieve Currents data and choose its own provider, so Currents cannot control that
agent’s subsequent data handling or treat it as covered by Currents’ consent
boundary.


The organization creation form offers **Allow AI analysis**, ticked by default. Leaving it ticked records the grant against the person creating the organization; clearing it records nothing at all, so the organization reads as never asked rather than as having refused, and its AI features stay off until an admin grants consent in settings.

## Granting and revoking consent

Go to **Organization Settings → AI usage consent** and use the toggle.

The setting records who made the decision, when, and which version of the terms was shown at the time. That stamp appears under the toggle.

### Revoking

Revoking takes effect immediately:

* AI features stop working for everyone in the organization
* AI requests already in flight fail rather than completing
* Data already sent to the provider is not recalled — revoking stops future requests

Because in-flight work fails, the dashboard asks you to confirm before revoking.
Comment on lines +50 to +58

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Revocation lacks a client error contract

Revoked consent has no documented HTTP status, error code, or payload, so deployed IDE, Slack, dashboard, n8n, and MCP clients cannot distinguish it from provider or network failures or show the promised unavailable state. Could we define a stable consent-required/revoked response and document each consumer’s handling, including whether in-flight API/MCP retrieval is rejected?

Severity

Want Baz to fix this for you? Activate Fixer

Other fix methods

Fix in Cursor

Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
`ai/data-usage-and-consent.md` around lines 50-58, the Revoking section promises that AI
features and in-flight requests fail but does not define a stable, distinguishable
failure contract. Document the consent-revoked response, including its HTTP status,
error code, payload, and whether in-flight API/MCP retrievals are rejected, then explain
how the IDE, Slack, dashboard, n8n, and MCP clients should handle and present it. Align
the related consumer documentation so clients can distinguish revoked consent from
ordinary provider or network failures.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commit 3cd35ef addressed this comment by documenting that revocation takes effect immediately and that in-flight AI requests fail rather than completing. It does not define an HTTP status, error code, payload, or consumer-specific handling.


## Turning AI off without revoking consent

Consent controls whether Currents *may* send data. If you want to keep consent in place but stop using a specific feature, disable that feature instead — consent by itself does not trigger any requests.

## Related

* [AI Overview](overview.md) — the AI features and entry points
* [Manage Team](../dashboard/administration/manage-team.md) — organization roles and who counts as an administrator
* [Service Agreement](https://currents.dev/tos) — the terms governing AI data use
2 changes: 2 additions & 0 deletions ai/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,6 +26,8 @@ Currents post-processes test results on the server into a structured troubleshoo

Every entry point below delivers this same context - they differ in where you are when you use them and how much of the loop is automated.

Sending that context to an AI provider requires your organization's consent, which an administrator grants once for the whole organization. See [Data Usage and Consent](data-usage-and-consent.md) for what is sent and how to grant or revoke it.

## Entry points

| Method | Where | Best for |
Expand Down