Agentic Test Execution: What Security and Compliance Guarantees Should You Require?

A test agent reads a scenario, logs in to an application, enters data, observes screens, and produces evidence. These capabilities speed up manual and Gherkin test execution. They also rightly prompt the security team to examine how data is processed before any rollout.

In a previous article, we presented agentic execution of manual and Gherkin tests and the questions to ask before getting started. Here we focus on security and compliance.

Our conviction is simple: a test agent must have an explainable data flow. QA teams must be able to say precisely what data they send to the AI agent, how they secure it, and how long they retain it. They must also be able to ask the same questions of any agentic execution vendor, whoever it may be.

This article sets out the evaluation checklist for an agentic execution solution, followed by our Lynqa solution’s answers for its Cloud and Self-Managed editions. Implementation details (detailed architecture, data flow matrix, list of subprocessors) are documented in the DPA and the Trust Center, and explored in depth during the security review that precedes a pilot project.

As input, the agent receives manual tests in action/expected result format, or Gherkin scenarios. This includes the actions to perform, the expected results, the test data required for the scenario, and attachments. This data comes from the test repository (for example, data from Xray “Test” and “Test Execution” issues).

During execution, the agent observes the user interface. It may see contract references, amounts, documents, or information related to a test account. The screenshots, observations, and logs produced at each step also become data that must be protected.

The solution’s architecture determines how far this access extends. Some tools use the DOM, the code, network calls, or browser logs. Lynqa works through “computer-use”: it uses a virtual mouse and keyboard and interprets only the information visible on screen. It does not access the DOM, the HTML, the source code, APIs, or the database. This architectural choice structurally reduces the attack surface: what the agent cannot reach doesn’t need to be protected from it.

Figure 1 – How data flows during the agentic execution of a test

An agent may use a test account or technical secret. This information must not be written in plain text in the scenario. In Lynqa, it is entered separately as hidden sensitive data. It is not included in the text sent to the AI model.

The Lynqa Cloud terms of use prohibit the use of personal data in tests and test data. Best practice remains the same whatever the tool: synthetic or anonymized datasets, accounts limited to the test environment, and easily revocable permissions.

Figure 2 – Sensitive data is provided separately from the test case and masked in Lynqa

The security review analyzes how data actually flows. Eight questions help frame the topic quickly. You can reuse them as is in your vendor assessment file, for Lynqa as well as for any other agentic execution solution:

The answers should be documented in the DPA (Data Processing Agreement), which makes this verification easier by bringing together the applicable controls and documents. A vendor that cannot give simple answers to these eight questions is, in effect, asking you to take their word.

The vendor operates the infrastructure, handles updates, and monitors the service. This model makes it easier to get started, provided you know where each processing operation takes place. Application hosting and AI model inference may be located in two different regions.

The security team will specifically review encryption, logical tenant isolation, secrets management, retention periods, the list of subprocessors, and the AI provider’s guarantees. A static IP address also allows precise authorization of the agent’s access to test environments.

This is an on-premises edition that uses an approved LLM, with access governed by the customer organization’s IT department. The customer deploys the agent, its runners, and its storage in the customer’s environment. BYO-AI can take the form of a customer-owned API key or an internal AI gateway already approved by the organization.

With an internal gateway or model, tests, screenshots, prompts, results, and logs remain within the customer’s network. This configuration meets the needs of applications that cannot be accessed from the Internet and of regulated environments. In return, the customer remains responsible for installation, monitoring, backups, and the updates it decides to apply.

Figure 3 – Lynqa Cloud and Lynqa Self-Managed address two levels of control

A SOC 2 Type II report assesses control design and operating effectiveness over a given period. It covers, for example, access management, change management, monitoring, incident response, and system protection.

The scope deserves careful reading, and this applies to any vendor. The report may cover the core service without including a marketplace app, certain integrations, or all subprocessors. The audited criteria and the observation period must also be specified. SOC 2 is an attestation report, not a blanket certification of the entire offering.

SOC 2 does not automatically guarantee that customer data is not used for training, nor does it guarantee the inference region, prompt retention, or GDPR compliance of every configuration. These points require contractual commitments and a clear description of data flows.

Regular DAST scans, the bug bounty program, vulnerability management, the DPA, transfer clauses, model usage policies, and audit logs complete the security setup. Compliance is useful when it lets the customer verify a specific control.

Human oversight is also central. The execution must be identified as performed by an agent. The QA tester reviews the evidence, decides on the verdict, and alone retains the release decision.

Lynqa executes manual and Gherkin tests already validated in the test repository, for example, Xray in Jira. The agent observes the screen, acts on the user interface, and produces, for each step, the action performed, the observation, the verdict, the explanation, and the associated screenshot. Controls applied to the instructions it receives block malicious content before execution.

Access is limited to the URLs authorized by the customer and to the test environment. For Lynqa Cloud, Smartesting provides a static IP address that can be added to the allowlist. The QA tester can confirm or change the verdict; their decision is tracked in Lynqa and, depending on the integration, in Xray. Lynqa never makes a release decision.

The Lynqa SaaS is hosted by Scaleway in France. AI model inference is currently performed in the United States through a third-party provider’s API. This transfer is governed by contract, and the data is not used to train the model. The identity of the inference provider and the full list of subprocessors are documented in the DPA and kept up to date in the Lynqa Trust Center.

Lynqa data is retained for 30 days. You can request deletion at any time, and permanent deletion occurs within 60 days at most. Data is encrypted, customers are logically isolated, internal access is restricted, and executions are logged. Security incidents affecting data are notified within 24 hours.

Lynqa Self-Managed is available for organizations that want to host the agent in their own infrastructure. The customer installs the execution components, storage, results, and logs in its network. No execution telemetry is sent to Smartesting.

The customer uses its own key for an AI provider or its internal gateway. In the latter configuration, no data leaves the network. Smartesting provides the packages and updates; the customer reviews them and then decides whether to install them.

Smartesting has obtained a SOC 2 Type II report covering the security criterion. It covers the Lynqa Service API and Lynqa Dashboard for the period from March 1 to May 31, 2026. A-LIGN performed the audit, and control testing found no exceptions. Lynqa for Xray and third-party integrations are not included in this scope. The report is available on request under an NDA.

The security setup also includes regular DAST scans and an ongoing public bug bounty program for Lynqa for Xray. The Lynqa Trust Center presents controls related to infrastructure, product, organization, internal procedures, and data protection; it is the reference source and is kept up to date as the security setup evolves.

Figure 4 – The Lynqa Trust Center brings together security controls and documents

Up-to-date information is available in the Lynqa Trust Center. The DPA, terms of use, and other contractual documents are available on the Lynqa legal documents page.

Finally, when scoping a proof of concept, Smartesting provides a security dossier for your CISO: a detailed description of data flows, the chosen edition’s architecture, subprocessors, and how the solution connects to your test repository. It is this dossier, not a blog article, that supports your security review.

Before handing a test to an agent, the team must be able to explain what data it receives, what it observes, which model processes it, where it stores evidence, and how it deletes it.

Security relies on an architecture suited to the data, verifiable technical and contractual controls, and independent compliance with a clearly stated scope. The choice between Cloud and Self-Managed then lets you adjust the level of control to the organization’s context.

The eight questions in this article are the starting point. The detailed answers (architecture, data flows, subprocessors) are developed with your security teams when scoping a pilot project.