Data and privacy

The Step AI Agent calls a large language model (LLM) as part of producing automation packages. Content from the application under test therefore reaches a model by design. This page states what does, what does not, and what you decide.

Unlike the Step MCP Server, which never calls a model itself and leaves that choice to your own AI assistant, the agent makes those calls within its workflow.

What leaves your environment

While producing automation, the agent sends to the model:

  • The requirements and test data you supply
  • Content from the application under test, as far as it needs in order to work out how to drive it. Depending on the automation technology in use, that can include page content, the structure of the interface, and output the browser returns while it is being driven
  • Existing automation, code and test assets in the package it is extending, which it reads in order to build on them rather than duplicate them
  • Diagnostic output from executed runs, including relevant stored results, when it repairs automation that failed

The second point is the one to weigh. The agent works by exploring a running application, so anything that application can display is content that may reach the model: business data, customer records, internal hostnames, and credentials visible in the interface.

Generation is not read-only. The agent interacts with the application and executes automation while building and repairing it. Those actions can change application data, so this applies from the first run, not only once the automation is finished.

Recommendation: point the agent at test environments holding synthetic data. Treat anything the application can show as data that may leave your environment.

What stays

  • The agent runs on your own infrastructure, on your machine or your Step instance. It is not a hosted service, and your runs do not pass through us.
  • Run artefacts are stored in your environment. Automation packages, plans, logs, traces and reports are written to local or Step storage. Their contents may also be included in model requests where needed for generation or repair, as described above.
  • The model has no general access to your Step instance. The agent sends only the Step content it retrieves for the generation or repair task in hand; it does not give the model free rein to browse your instance, and Step credentials are never part of what it sends.
  • The model does not execute the automation. It helps produce and repair it; execution is performed by Step.

The last point has a consequence worth stating plainly. A generated package runs as ordinary Step automation, without the agent and without model calls. Recurring regression, scheduled coverage and pipeline gates therefore send no application content to a model. Using the agent again, to extend or repair the automation, involves model processing again.

What we receive

Model requests and responses go directly from the environment running the agent to your provider. They do not transit our infrastructure, and the generated package, logs, traces and reports stay where the run wrote them.

This page describes the data flow of a run. It is not a data processing agreement: controller and processor roles, subprocessors, international transfers, residency, deletion and incident obligations are handled separately.

Model account and billing

The agent calls the model using credentials that you supply, so usage is billed to your account and your provider’s terms apply. Model traffic goes directly from the environment running the agent to the configured provider; it does not pass through a service we host.

Retention and training

Retention and training depend on your provider and your account configuration. Because the agent uses the model credentials you supply, it is the provider’s data-handling terms, retention policy and training settings that apply. Review them before using the agent with confidential or personal data.

What you control

  • Application access. Use dedicated test accounts, and restrict the agent’s permissions and network reach to the systems the task needs.
  • Where it runs. Locally on your machine, or centrally on your own Step instance. See Getting started.
  • The key. Store it as a Protected Step Parameter or an environment variable. Do not commit it to automation packages or source control.
  • What ships. The generated package is readable automation. Review it before it runs anywhere sensitive.

Checklist

Technical prerequisites are in Getting started. These are the ones that decide whether a run is safe.

Before the first run

  • The target is a test environment holding synthetic data, not production.
  • Any account the automation will use is a test account, with test payment methods. Automation that completes a transaction completes a real one.
  • The API key is a Protected Step Parameter or an environment variable, and is not committed anywhere.
  • The key is exposed only to the process that needs it, rather than set globally where unrelated tools on the machine would pick it up.
  • You have checked that your model provider’s training, retention and data-processing arrangements meet your organisation’s requirements.
  • You know where generated packages and run artefacts will be stored, and who can access them.

Before it runs anywhere sensitive

  • Someone has reviewed the generated automation. It is readable, and the plan and keyword specification exist so that it can be checked before it is trusted.
  • You know who can see the results once runs move to a shared instance.

If you ever point it at production

  • The automation stops before any irreversible or externally consequential action, unless that action has been explicitly authorised.
  • You accept that production data is real data: whatever the application displays there may reach the model.

Questions

For data handling in a specific deployment, contact us at contact@exense.ch.