Data Processing Agreement

Effective date: 15 September 2026

This Agreement applies where Enji AI LLC processes personal data on your behalf. It forms part of the Terms of Service and you accept it when you accept them. You do not need to sign anything or ask us for a copy.

It applies from the moment you create an account, including demo runs, and does not wait for a purchase. A demo processes a real repository, so it needs the same protection as a paid one. The scope limit in Terms section 2 is about which commercial terms govern a purchase; it does not narrow this Agreement.

If you have a separately negotiated agreement with us, that agreement governs where the two differ.

1. Who is who

You are the controller. You decide which repositories and targets the Service works on, what it does with them, and what happens to the results.

We are the processor. Enji AI Limited Liability Company, state registration number 220238-3301-ООО, taxpayer identification number 01907202310418, 11 microdistrict, 14/4, Bishkek City, Kyrgyz Republic, 720049. We process customer content on your instructions to provide the Service.

Where you are yourself a processor acting for someone else, you are our controller for the purposes of this Agreement, and we are your sub-processor.

Paddle is neither. Paddle sells credits as merchant of record and handles payment and tax data as an independent controller under its own terms. Payment data never reaches this Agreement, and repository content never reaches Paddle. See Billing & Credits.

In this Agreement, “customer content” means personal data contained in the repositories, websites and task context you direct the Service to process, and in the reports, findings and artifacts it produces from them.

2. What we process, and why

The full description is in Annex 1. In short: we process customer content only to provide the Service to you — running the audits you select, producing reports and findings, and, where you enable it, proposing changes.

We process on your documented instructions. Your instructions are these Terms, this Agreement, the settings you choose in the product, and anything else you tell us in writing. This includes transfers: by accepting this Agreement you instruct us to transfer customer content to the Kyrgyz Republic and to the sub-processors in Annex 3, under the safeguards in Annex 4. We do not process customer content for our own purposes.

If the law forces a transfer, we tell you first. Where EU or Member State law requires us to transfer or otherwise process customer content beyond your instructions, we will inform you of that requirement before processing — unless the law prohibits us from telling you, on important grounds of public interest.

The same applies to the law we are actually subject to. We are established in the Kyrgyz Republic, so a demand made on us is far more likely to arise under Kyrgyz law than under EU law. We treat a requirement under Kyrgyz law, or under the law of any other country we operate in, exactly the same way: we tell you before processing where we lawfully can, and where we cannot we follow the government-access commitments in Annex 4.

One clarification, because “our own purposes” invites a question. We do look at how the product is used, to keep it reliable and to improve it. That works on execution metadata — which audit types ran, how long they took, whether they failed, how much was consumed — and not on the content of your repositories or reports. If we ever needed customer content for a purpose of our own, we would need a separate lawful basis from you and we would ask; we do not have one and do not rely on one.

We will tell you if an instruction looks unlawful. If we think something you ask us to do infringes data protection law, we will say so and may pause that processing until it is resolved. We are not your legal adviser and we do not check your instructions routinely — this covers the case where a problem is obvious to us.

No model is trained on your content — ours or theirs. No Enji-owned model is trained on customer content, and the AI providers we send task context to do not train on it either: we use their API tiers, where not training on customer inputs is the contractual default, and we have not opted into anything that changes it. We do not sell customer content. See AI Data Use.

3. Confidentiality

Everyone we allow near customer content is bound by confidentiality obligations that survive the end of their engagement, and access is limited to those who need it for support, security, incident response and abuse prevention.

4. Security

We maintain the technical and organisational measures in Annex 2, as required by Article 32. We complete security questionnaires on request, and section 9 says what else we will give you.

5. Sub-processors

You give general written authorisation for us to engage the sub-processors in Annex 3, and for changes to that list under this section.

We impose data protection obligations on each sub-processor that are no less protective than those in this Agreement, and we remain liable to you for what they do.

We will give you at least 30 days’ notice before adding or replacing a sub-processor for customer content, by email to your account contact. Updating the Subprocessors page is how the list stays current; it is not how you are told. A silent edit would not give you thirty usable days and would make the objection right below meaningless. If you object on reasonable data protection grounds within 14 days, tell us and we will try to resolve it. If we cannot, you may terminate the affected part of the Service and we will refund unspent credits under Terms section 10.

Two limits apply. First, our AI providers keep their own sub-processor lists and change them on their own schedule; we pass on what we are told, and we do not control their timing. Second, their deletion terms carve out retention for legal obligations, dispute resolution, and combating harmful use of their services. We cannot promise you deletion at a provider that is wider than the provider gives us, and section 8 says what that means.

6. Helping you with data subjects

If someone exercises a right — access, correction, deletion, restriction, portability, objection — and it concerns customer content we hold for you, we will help you answer.

If a request reaches us directly, we will not answer it ourselves. We will pass it to you within 5 business days, unless the law requires otherwise, because you are the controller and it is your answer to give. We will tell the person we have done so and who to expect a reply from.

Most of what you need is in the product: you can export reports, delete projects and repositories, and delete an account and its results. Where the product does not reach, ask us at [email protected].

7. Breaches, assessments, and the regulator

We will tell you about a personal data breach without undue delay and in any event within 48 hours of becoming aware of one, in time for your own 72-hour obligation under Article 33. We will send what we know at the time: what happened, which data and roughly how many people are affected, the likely consequences, and what we are doing about it. We will keep you updated as we learn more. Notifying your supervisory authority is your decision and your obligation — we will give you what you need to make it in time.

We will also give you reasonable help with data protection impact assessments and prior consultation under Articles 35 and 36, taking into account what we know about how the Service works.

And we will tell you about security incidents that are not personal data breaches. If your code, your reports or your credentials are exposed or put at risk — a compromised execution environment, reports reachable by someone who should not reach them, a leaked token — we notify you even where no personal data is involved and no law requires it. Same timeline as above: without undue delay, and in any event within 48 hours of our becoming aware.

8. Deletion and return

How deletion is carried out may change; what this section obliges us to do does not.

At the end of the Service, you choose: deletion or return. On your instruction, or when your account closes, we delete customer content and existing copies of it, or return it to you first if you ask.

You can delete the account yourself, and it is permanent. Deletion is available to you in the product, and a service administrator can carry it out at your request. There is no recovery, no grace period and no undo — once it runs, the account and its results are gone and we cannot bring them back. Export anything you want to keep first; you can do that at any time while the account is open.

Deletion covers your account, your projects, and the reports, findings, artifacts and audit history produced from your repositories. Backups are retained for 7 days and then overwritten, so a copy can persist for up to a week after you delete. We do not open backups to edit them out; until the cycle completes the copy is isolated and used for nothing.

Four things survive, and you should know which.

1. Payment and tax records — but not ours. Paddle sold you the credits and carries the statutory retention for the invoice and tax records. We do not keep them, so we cannot delete them for you either; ask Paddle. Our own credit ledger goes with the account.

2. A record that a deletion happened, carrying the date and an internal reference. It holds no name, no email, and nothing from your repositories or reports.

   Be aware of what that costs you. Because we keep nothing that identifies you afterwards, we cannot later confirm to you, or to a regulator, that your particular account was deleted — only that a deletion occurred on a given date. If you need evidence of erasure for your own Article 5(2) records, ask us for written confirmation before you delete, and we will give it while the account still exists.

3. Task context already sent to an AI provider. It is held under that provider’s terms and deletion schedule. We cannot recall it, and neither can they always delete it immediately — see section 5. If this matters to you, use a customer-controlled deployment with your own provider routes; AI Data Use explains how.

4. Anything you published. If you made a project view or a summary public, copies taken while the link was live are beyond anyone’s reach. Revoking the link is not deletion — see Terms section 13.

9. Audits and information

Ask and we will answer. We will give you the information you reasonably need to show that we are meeting this Agreement, including this page, the security measures in Annex 2, our current sub-processor list, and answers to a security questionnaire.

Audits. You may audit our compliance, or appoint an independent auditor to do it, no more than once a year unless a supervisory authority requires more or we have had a breach affecting you. Give us 30 days’ notice, agree the scope with us first, keep what you learn confidential, and do not disrupt the Service or other customers. We will make a person available who can answer properly. If your questions can be answered with documents, we will offer that first.

You bear your own costs. If an audit needs substantial engineering time beyond answering questions, we may charge for it at a reasonable rate, agreed before it starts.

10. International transfers

Customer content is stored in Europe. The Service runs on Google Cloud in its europe-west regions and customer content does not leave Europe at rest.

Three transfers carry it outside Europe, and all three are restricted transfers made under the safeguards in Annex 4:

The Kyrgyz Republic has no UK or EU adequacy decision. The United States is different: an adequacy decision exists under the EU–US Data Privacy Framework, with a UK Extension, but it covers only organisations that are certified to it. We do not rely on it. All three transfers are made under the Standard Contractual Clauses in Annex 4, which stand whatever a provider’s certification status is.

A fourth transfer exists at the usage layer — analytics, behind separate consents — and it carries no customer content at all.

Privacy Policy §12 describes all four in full and is the authoritative description; this section states what we commit to as your processor, and Annex 4 carries the safeguards. Where the two differ on the safeguards, Annex 4 governs.

Two things about the scope are safeguards in their own right. Our team has no ability to browse your repositories — Annex 2, Who can see what, sets out item by item what is and is not reachable. And outbound calls from the Service — to GitHub, to GitLab, and to the AI providers — do not pass through Cloudflare.

You can ask us for a copy of the transfer safeguards we rely on.

11. Liability, changes, and everything else

Liability under this Agreement is subject to the limits in Terms section 22, with three exceptions that override them.

The Standard Contractual Clauses come first. Where Annex 4 applies, Clause 12 of the Clauses governs liability to data subjects, and nothing in the Terms or this Agreement reduces it. A data subject’s rights against us under the Clauses are not capped by section 22.

Statutory liability is not capped either. Article 82 of the GDPR gives data subjects a right to compensation, and it is not ours to limit by contract — including how liability is apportioned between us and you as controller.

And the cap does not reach your own regulator. Fines or enforcement directed at us are ours.

Within those limits the cap applies as written. Nothing in this section is an attempt to contract out of the Clauses.

We may update this Agreement as the Service, the law, or our sub-processors change. If a change materially reduces your protection we will give you at least 30 days’ notice and you may terminate and take a refund of unspent credits under Terms section 10. Otherwise the updated version takes effect when posted with a new effective date.

This Agreement is governed by the law of England and Wales, as the Terms are — except that Annex 4 governs itself where the Standard Contractual Clauses say so.

Annex 1 — Details of the processing

Subject matter. Provision of Enji Guard together with the Enji Fleet agents orchestrator.

Duration. For as long as the Terms are in force, plus the time needed to complete deletion or return under section 8.

Nature of the processing. Cloning and reading repository content; running automated audits; sending selected task context to AI providers; generating reports, findings, issues and — where you enable it — proposed changes; running authorized active checks against targets you nominate; storing and displaying results; support and security operations.

Purpose. Providing the Service to you. Nothing else.

Categories of data subjects

• Your personnel who use the Service
• Contributors to the repositories you connect — including people who no longer work with you but appear in history
• People whose personal data appears in code, configuration, fixtures, test data, logs, issues, comments or observed responses
• People identified in reports and findings produced from the above

Categories of personal data

• Identifiers in repository metadata — commit author names and email addresses, issue and merge-request participants, and the Git author identity you configure, as it appears in commits and repository history. The same identity held as a connection setting is controller data, not processor data — see Privacy Policy §1
• Any personal data present in repository content, configuration, test data or logs
• Responses observed during authorized checks, which may contain personal data of your users
• The same, as reproduced in reports, findings, diffs, screenshots and reproduction steps

Special category data. Not sought, not requested, and not knowingly processed. It could appear inside your repositories, which is why you should scope access to what an audit needs.

Frequency. Not continuous: processing happens on demand when you start an audit, on schedule where you have configured recurring ones, and on event when a webhook tells us an issue, comment or merge/pull request has changed. Between those, nothing is processed. The arrangement itself lasts for the duration of the Terms.

Annex 2 — Security measures

• Encryption in transit and at rest.
• Credentials and secrets stored encrypted, with restricted access. Task logs are masked by default to avoid capturing secrets, tokens, authorization headers or provider credentials.
• Isolated ephemeral execution. Repository-backed tasks run in containers destroyed after each task together with the cloned code.
• Access control. Least-privilege, need-to-know, and only for support, security, incident response and abuse prevention. Repository access is verified before a task uses it. What our team can and cannot reach is set out item by item under Who can see what below — that block is the authoritative statement of it, and the narrowness of the access is itself part of what protects a transfer to a country without an adequacy decision (section 10).
• Access logging. Access to customer content by our personnel is logged — who, what and when — and retained as a security record for up to 24 months, because an incident is often found long after it happened. Together with the restrictions below this is the organisational measure supporting the transfer in section 10: access is narrow, and what happens within it is recorded.
• Repository credentials. On GitHub we hold no long-lived secret of yours — the GitHub App receives short-lived tokens from GitHub. On GitLab the token you issue is stored encrypted, used only for the projects you connect, and our copy is deleted when you disconnect.
• Infrastructure. Google Cloud, europe-west regions, with the platform controls that come with it.
• Separation. Customer content is segregated by account and project.
• Resilience. Backups and restoration procedures for the infrastructure the Service runs on.
• Vulnerability management and patching. Dependencies and infrastructure are tracked for known vulnerabilities and patched.
• Security testing. The Service is regularly tested for exploitable weaknesses, including automated dynamic testing against our own environments.
• Secure development. Changes go through review, automated checks and tests before release.
• Network isolation and edge protection. Full network isolation on Google Cloud, with a web application firewall in front.
• No password access to infrastructure. Engineers authenticate with individual private keys; password login is disabled.
• Monitoring and alerting. Infrastructure and application health are monitored, with alerts routed to an on-call channel.
• Incident response. Incidents are triaged by the engineering team, investigated to root cause and remediated, with affected customers notified under section 7.
• Physical security is Google Cloud’s, under its own certifications for the europe-west regions. We operate no data centres.

Who can see what

This block is the authoritative statement of human access.

Access is least-privilege and need-to-know, and only for support, security, incident response and abuse prevention. What that means in practice differs sharply by what the data is, so here it is item by item rather than as a principle.

Your repositories — no. There is no way for our team to browse your code. A run clones what it needs into an isolated container and destroys it with the clone when the task ends.

Audit reports — yes, and that is not the same as “no access to your code”. A finding is made of your code: file paths, snippets, diffs, reproduction steps. So while we cannot read your repository, we can see the parts of it a report quotes. “No repository access” and “no visibility into your code” are not the same thing, and the difference is worth knowing.

Task context — yes. The material a run sends to an AI provider is visible to the team.

Execution logs — yes, masked. Secrets, tokens and authorization headers are masked by default. Masking covers recognised secret and token patterns. It is not a substitute for keeping credentials out of repositories.

Auto-pentest reports — restricted further. They describe unfixed weaknesses in live targets and can contain responses from your site, including your users’ data. Access is limited to one named person, not the team.

Account and credit data — yes. Your account details and the credit ledger behind your balance are reachable by support. They are not customer content and we are the controller of them; they are listed here because section 10 counts them among what a transfer to the Kyrgyz Republic reaches.

Anything you send to support — yes. You sent it to us.

Your GitLab token — nobody. It is stored encrypted and used by the Service. No member of our team can decrypt or read it, which is why our advice when a token is exposed is to rotate it in GitLab rather than ask us to look.

And it is logged. Access to customer content by our team is recorded — who, what and when — and kept as a security record for up to 24 months. Logging does not prevent access; it is what makes access answerable afterwards.

Annex 3 — Sub-processors

The current list of sub-processors that handle customer content is published at /legal/subprocessors, and that page is Annex 3 for the purposes of this Agreement and Annex III for the purposes of the Clauses. Adding or replacing any entry on it triggers the 30 days’ notice in section 5, and we keep previous versions of it.

Annex 4 — Transfer safeguards

The instruments

EEA personal data — the EU Standard Contractual Clauses, Commission Implementing Decision (EU) 2021/914 of 4 June 2021, using Module Two where you are a controller and Module Three where you are yourself a processor. They are incorporated by reference and deemed executed by both of us when you accept the Terms.

UK personal data — the same Clauses as amended by the UK Addendum (the International Data Transfer Addendum issued under s119A(1) Data Protection Act 2018), or the UK IDTA where that is more appropriate.

Swiss personal data — the same Clauses, read with “GDPR” meaning the Swiss FADP, the Swiss Federal Data Protection and Information Commissioner as supervisory authority, and “Member State” including Switzerland.

Elections under the Clauses

Annex mapping. Annex I.A (parties) is completed by the section below; Annex I.B (description of transfer) by Annex 1 of this Agreement; Annex I.C (competent supervisory authority) by the table above; Annex II (security measures) by Annex 2; Annex III (sub-processors) by Annex 3.

Annex I.A — the parties

Data exporter: you — the customer identified by the account that accepted these Terms, with the contact details held on that account. Your role is controller, or processor where you are acting for someone else. Activities: procuring automated code audits for repositories and targets you control.

Data importer: Enji AI Limited Liability Company, 11 microdistrict, 14/4, Bishkek City, Kyrgyz Republic, 720049 · [email protected]. Role: processor. Activities: as described in Annex 1.

Contact point for data subject complaints and enquiries under the Clauses: [email protected]. You may also write to either Article 27 representative:

European Union — Prighter EU Rep GmbH, Schellinggasse 3/10, 1010 Vienna, Austria · [email protected] · Trust Center: app.prighter.com/portal/16660917026

United Kingdom — Mad Devs Group Ltd, 27 Old Gloucester Street, London WC1N 3AX, company 11793394 · [email protected], a company related to ours by common ownership

Government and law-enforcement access — Clauses 14 and 15

We rely on the Clauses rather than on any adequacy decision for these transfers, so how we — and the providers — behave when an authority comes asking is the substance of the transfer assessment rather than a footnote to it.

The commitments below are ours, and they cover our team and the AI providers. For Cloudflare the safeguard is its own: the Cloudflare data processing addendum, which incorporates the EU Standard Contractual Clauses and the UK Addendum, is accepted and in force for our account, and we rely on it together with Cloudflare’s published practice of notifying and challenging government requests.

What we commit to, and these are Clause 15 obligations rather than goodwill:

• We tell you. If we receive a legally binding request from a public authority for customer content, we notify you promptly, and if we are prohibited from doing so we ask for a waiver of that prohibition and record that we asked.
• We challenge. Where there are reasonable grounds, we challenge the request — including interim measures to suspend disclosure — and we do not hand anything over while a challenge is live unless compelled.
• We give the minimum. If we must disclose, we provide only what the request actually compels, after checking it is lawful on its face.
• We keep a record of the requests we receive and what we did, and we will share it with you on request to the extent the law allows.

What we cannot promise. We cannot guarantee that a foreign authority will never compel disclosure, and no contract can. If that risk is unacceptable for your data, a customer-controlled deployment on your own provider routes takes us out of the path — see AI Data Use.

Transfer risk assessment

These transfers are supported by an assessment of the risks of transferring to the Kyrgyz Republic and the United States, covering the legal regime in each, the practical likelihood of authority access to data of this kind, and the measures in Annex 2. You can ask us for it.

Cloudflare is assessed separately, because the exposure is a different shape — a transient window rather than storage, as section 10 describes. The assessment covers United States law as it applies to a provider in that position, the fact that no report or repository is retrievable from Cloudflare afterwards, and the encryption in transit either side of the edge.

Where the Clauses conflict with this Agreement, the Clauses prevail.