Data Processing Agreement

Effective date: 2 October 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.

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 summary, 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.

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.

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.

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. 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 listed on the Subprocessors page, which is the current version of Annex 3, and for changes to that list under this section.

We impose data protection obligations on each sub-processor that are, in substance, the same as 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 that handles customer content, by email to your account contact, and we will update the Subprocessors page at the same time.

You may object on reasonable data protection grounds at any time during the notice period. 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.

Urgent replacements. If we must replace a sub-processor sooner to keep the Service secure or available, we may do so with less notice. We will tell you as soon as we can, and you keep the same right to object and terminate for 30 days after our notice.

Our providers’ own sub-processors. Our providers engage sub-processors of their own and change them on their own schedule. The 30 days above apply to sub-processors we engage. When a provider tells us about a change to its own, we will pass that on to you promptly.

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 contact@enji.ai.

7. Breaches, assessments, and the regulator

We will tell you about a personal data breach without undue delay and in any event within 72 hours of becoming aware of one. 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 72 hours of our becoming aware.

8. Deletion and return

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. Once the cycle completes the copy is permanently deleted.

Four things survive deletion.

1. A record that a deletion happened, carrying the date and an internal reference.
2. 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.
3. 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.
4. A shared project that another authorised owner still holds. Closing your account removes the content that belonged to it alone. Where a project has other authorised owners, or has been transferred to one, the project and its reports stay with them — your account going does not take their copy with it. If you need a shared project gone as well, remove it, or agree its deletion with the other owners, before you close the account.

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 available a person with the knowledge to answer your questions. Where documents can answer them, we will offer those 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.

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

Privacy Policy §12 describes every one of them 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 elements of scope function as safeguards. 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 Terms 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.

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 authorised active checks against targets you nominate; storing and displaying results; emailing notifications of audit and Autofix results, including result summaries, to your users; and support, security and incident operations, including operational and security alerting to our team.

Purpose. Providing the Service to you.

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 authorised checks, which may contain personal data of your users
• The same, as reproduced in reports, findings, diffs, screenshots and reproduction steps
• The email addresses we send result notifications to, and the personal data a notification carries — result summaries, project and repository names, result links
• Anything you attach to a support enquiry, including screenshots

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, authorisation headers or provider credentials.
• Isolated ephemeral execution. Repository-backed tasks run in containers destroyed after each task together with the cloned code.
• Task context. Only the context a run needs is sent to an AI provider. It is visible to personnel on a need-to-know basis and that access is logged.
• 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, and the narrowness of that 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. 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 internal mailbox.
• 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. What least-privilege and need-to-know mean in practice differs by what the data is, so each category is answered separately.

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. 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.

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

Execution logs — yes, masked. Secrets, tokens and authorisation 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.

Every item above that answers yes is recorded under Access logging above.

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.

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.

Onward transfers to sub-processors are made under each provider’s own data processing agreement, incorporating the EU Clauses and the UK Addendum, see the full list of sub-processors at /legal/subprocessors.

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 · contact@enji.ai. Role: processor. Activities: as described in Annex 1.

Contact point for data subject complaints and enquiries under the Clauses: contact@enji.ai. You may also write to either Article 27 representative:

European Union — Prighter EU Rep GmbH, Schellinggasse 3/10, 1010 Vienna, Austria, FN 639035 h · support@prighter.com · Trust Center: app.prighter.com/portal/16660917026

United Kingdom — Mad Devs Group Ltd, 27 Old Gloucester Street, London WC1N 3AX, company 11793394 · privacy@maddevs.io, 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 respond to a request from a public authority forms part of the transfer assessment.

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.

Our commitments under Clause 15:

• 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.

Transfer risk assessment

We have assessed the risks of the transfers listed in section 10, covering the laws and practices of each destination country and the safeguards in Annex 2. We review the assessment when those laws or our sub-processors change, and will tell you if we can no longer comply with the Clauses. A summary is available on request.

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