Authorized Testing

Effective date: 15 September 2026

Some Enji Guard features send active requests to live websites and APIs. This page sets out the conditions for that testing: who can authorize it, what is in scope, what may happen, and what is prohibited.

What this covers

This page covers active checks that Enji Guard can run against websites, APIs, and web resources you link — for example runtime checks and Auto-pentest. These checks send real requests to a live target, so they require your explicit consent.

Authorization requirement

You may run active checks only against systems that you own or have written permission to test. By enabling active checks, you confirm that:

You own the target or have written authorization to test it.
Your organization permits the test.
Your hosting or infrastructure provider permits the test.
The target is in scope.
You understand that active checks may affect the target.

Consent applies to a specific project, website or domain, and selected scope. A renewed confirmation is required if:

The website, domain, or target scope changes.
The project is transferred to another owner or organization.
Ownership or authorization may have changed.
Materially more aggressive active-test types are added to the scope.
A repository, website, or project is disconnected and reconnected.
Twelve months have passed since the previous confirmation.

What Enji Guard may do during active testing

Within the approved scope, Enji Guard may discover endpoints, forms, parameters, and headers; send common vulnerability payloads; test for issues such as SQL injection, cross-site scripting, SSRF, IDOR/BOLA, broken access control, authentication bypass, and sensitive data exposure; generate the normal request volume needed to exercise endpoints; record reproduction steps; and generate a report.

Possible impact

Active checks can cause temporary errors or slowdown, higher request volume, security alerts and WAF or log noise, temporary account lockouts, and the exposure of bugs that need urgent remediation.

You accept these risks for the targets you authorize, and you are responsible for backups and for monitoring the target during testing.

Prohibited testing

Denial-of-service or load testing.
Credential stuffing, password spraying, or brute force.
Malware, persistence, lateral movement, or destructive payloads.
Data exfiltration.
Privilege escalation outside the agreed scope.
Scanning unrelated domains, IP ranges, tenants, customers, or shared infrastructure.
Testing targets prohibited by a hosting, cloud, or customer contract.

What a test may reach, and why that is a data protection question

A penetration test works by getting at things it should not be able to get at. Checks for SQL injection, broken access control and IDOR succeed precisely when they reach data the tester was not meant to see. On a live target, that data is your users’ personal data — not yours, and not ours.

So before you authorise a test, three things are yours to settle.

You need a lawful basis for us processing your users’ data in the course of the test, and it is not covered by the basis you have for running the service they use. Security testing is usually defensible on legitimate interests, but it is your assessment to make and record.
Consider whether a DPIA is required. Testing that systematically probes access controls on a production system holding personal data is the kind of processing that often triggers Article 35. We are not telling you it does; we are telling you not to skip the question.
Prefer a staging environment with synthetic data. Everything above becomes easier if the target is not carrying real people’s records. Where a production test is unavoidable, scope it as narrowly as the finding you are hunting.

What we do with what a test reaches.

We record only what is needed to prove and reproduce the finding. A report shows that a record could be retrieved, not the contents of the records.
We do not harvest. Nothing extracts data beyond the sample that evidences the weakness.
If we hit something we clearly should not have — special category data, credentials belonging to a third party, another tenant’s records — we stop that check, tell you, and delete what we captured unless you need it retained to reproduce the issue.
Special category data is never sought. It can still be reached by accident, which is what the previous point is for.
Access to these reports is restricted to one named person on our side, not the team. See DPA Annex 2, Who can see what, which sets out human access in full.

Handling reports

Auto-pentest reports may contain sensitive vulnerability details. Treat them as confidential, and do not publish or share a report unless you have authority to disclose the target, findings, reproduction steps, and remediation information.

The Service can publish reports, and that includes these. Enji Guard has controls for making a project view or a repository summary public — see Terms of Service section 13. They default to private and we never use them on your behalf, but they are there, so the decision is yours to get right. A report describing an unfixed weakness in a live target is the last thing that should be published by accident. Check what a page exposes before you turn the link on, and remember that revoking it later cannot take back copies someone already has.

Stopping a test

You can stop future checks by disabling the job. For an urgent stop, contact [email protected].

If you stop a run before it completes, or a run fails, the credits reserved for it are returned to your balance. See Terms of Service for how credits are reserved and spent.

Enji Guard may store consent records showing that a user confirmed the active-testing conditions for a target. Consent records may survive disabling and re-enabling a job, and are kept even after a consent is no longer valid for future checks — for 3 years after it stops being valid, because the record is the evidence that someone authorised probing a live system. See Data Retention & Deletion.