Privacy Policy

Effective date: 2 October 2026

Enji Guard is designed for teams that need visibility into AI-written code without losing control of code, policies, or sensitive project data. This policy explains what we process and why.

1. Who we are and what this policy covers

This Privacy Policy explains how Enji Guard (“the Service”) handles information when you visit our website, request a demo, run an audit, buy credits, or use the product. It applies to website visitors, customer contacts, administrators and users.

If your details appear inside a customer’s repository, this policy is not your notice. Commit authors, issue participants, anyone named in code or logs: for you, our customer is the controller and we act only on their instructions. Ask them. If you reach us instead, we will pass your request to them — see section 13. We say this here because you did not choose us and may not know we exist.

Who we are. Enji AI LLC develops and operates the Service and provides support. It is registered in the Kyrgyz Republic, taxpayer identification number 01907202310418, at 11 microdistrict, 14/4, Bishkek City, Kyrgyz Republic, 720049. Contact us at contact@enji.ai. We have appointed representatives in the European Union and the United Kingdom; their details are in section 13.

When we are the controller. We decide how to handle accounts and users, your product and project settings, the credit ledger, support and communications, and website technical data. This policy covers that data.

When we are a processor. Everything that comes out of your repositories and targets, and everything produced from it — code, task context, reports, findings and artifacts — we handle on your instructions. You are the controller, and the Data Processing Agreement governs. It applies to every customer automatically, forms part of the Terms, and needs no signature. Some information falls on both sides: the Git author details you configure, task records, and repository events are ours as settings and operational records, and yours where they appear in repository content and results.

Freemius. Freemius, Inc., a United States company, is our authorised reseller and the merchant of record for purchases. It collects your payment and billing details directly. It handles buyer data for us as our processor, and it is a controller in its own right for what it does as the seller — taking payment, tax and invoicing, and preventing fraud. Its privacy policy is at freemius.com/privacy and its data protection contact is privacy@freemius.com. Paying through Freemius is an international transfer — see section 12.

Self-hosted and customer-controlled deployments. There the Service runs in your environment, so your repository content does not reach us. This policy covers only what the deployment sends back: licensing and account information, and any diagnostics you choose to share. AI Data Use describes the deployment options.

2. Information we collect

Data we are responsible for

We are the controller for these categories:

• Account data — user id, email, name, profile picture URL, role, account status, language and notification preferences.
• Product data — project, repository and website names, membership and access metadata, dashboard settings, selected audit actions, and schedules.
• Repository connection data — for GitHub, installation identifiers, account and organisation names, and selected repository names. For GitLab, the host you connect to, the access token you provide (stored encrypted), who in your team may use it, and the Git author name and email you give us for commits our improvement workflows create.
• Execution records — runbook, task and schedule ids, task status, timings and progress messages, and links to the issues, pull requests and reports a task produced.
• Purchase, credit and usage data — for each purchase, a transaction reference, the amount paid, the credits granted and their expiry, and the account credited. Also your credit balance, the credits reserved and spent on each audit run, and refund requests.
• Payment and billing data — you enter these at checkout with Freemius, our reseller. We never receive or store your card details. Through our Freemius seller dashboard we can see the buyer’s name, email, billing address, country, VAT number and payment history, and we use them for support, refunds and accounting.
• Communication data — demo and upgrade requests, support and feedback messages including any screenshots you attach, and email notification records. Demo meetings are booked through Calendly, which collects what you enter on its booking page.
• Technical data — IP address, request and device metadata, cookies and local/session storage values, logs, and security events.
• Marketing and attribution data — only if you accept optional storage on our website: sanitized campaign parameters, whether a click identifier was present, the landing page, the referrer origin, and when it was captured. See the Cookie Policy.

Data we handle for our customers

For these categories our customer is the controller and we act as its processor under the Data Processing Agreement:

• Customer content — repository code and files processed during execution, website responses observed during authorised checks, task inputs and prompts, and generated reports, findings, issues, pull requests, feedback and screenshots.
• Repository metadata — branches, commits, merge and pull requests, and issues, including the names and email addresses of the people who wrote them.
• Repository activity events — where webhooks are enabled, a notification each time an issue, comment, or merge/pull request is created or changed, with its title and text, who acted, and repository identifiers. See GitHub App Permissions and GitLab Access.

Data we receive from others

Most of what we hold you gave us. The rest comes from:

• Google Sign-In — your account identifier, email address, name and profile picture URL, when you sign in.
• GitHub or GitLab — repository and organisation metadata, commit author names and email addresses, and the contents of issues, comments and merge or pull requests, under the access a customer granted.
• Freemius — the purchase record and the buyer details described above, after someone buys credits.

3. Repository code and website data

Customer code and project data are processed to run audits and provide the Service. Execution workspaces are ephemeral and are removed after each task.

Reports, artifacts, and audit history may retain selected customer content — for example file paths, code snippets, diffs, observed HTTP responses, logs, screenshots, reproduction steps, and remediation recommendations — as product records.

You should configure repository access and permissions so the Service receives only the data needed for the audit scope you choose.

4. AI data use

Enji Guard does not train or operate Enji-owned models on customer content, and the AI providers we send task context to do not train on it either — we use their API tiers, where that is the contractual default, and we have not opted into anything that changes it. Selected task context and customer content may still be retained briefly by a provider for abuse monitoring under its own terms, which is a different thing from training.

We do not sell customer code or personal data, and we do not use it for unrelated advertising. Self-hosted and customer-controlled deployments can restrict approved providers and routes by agreement. See the AI Data Use page for details.

5. How we use information

To provide audits, generate findings, produce reports, support deployments, troubleshoot issues, and improve product reliability.

To deliver credits: to maintain your credit balance and process refunds. Freemius takes the payment, works out and collects the tax, and issues the receipt — see Terms section 9.

To respond to demo requests and demo runs, support tickets, procurement questions, security reviews, and customer communications.

To protect the Service, prevent abuse, investigate security events, enforce terms, and comply with legal obligations.

To understand how people find us and whether our marketing works — attribution and website analytics, and only if you accept optional storage. This never involves your repository content.

6. Legal bases

Where the law requires us to have a legal basis for processing personal data, we rely on the following.

• Performance of a contract — where you hold the account yourself: to give you an account, run the audits you ask for, maintain your credit balance, process refunds, and provide support. Without this data we cannot provide the Service. Taking the payment and issuing the invoice are Freemius’s, under its own contract with you.

• Legitimate interests — we rely on these to:

  • provide the Service to your organisation, where it holds the account and you use it as an administrator or user;
  • keep the Service secure and reliable, prevent fraud and abuse, and investigate security events;
  • understand how the product is used in aggregate — from execution metadata, not from the content of your repositories or reports;
  • measure whether our own website is fast and working;
  • answer enquiries from people who are not customers yet;
  • keep purchase and accounting records, including the buyer details we see through Freemius;
  • comply with the laws that apply to us and respond to lawful requests from authorities;
  • keep evidence that an active check against a live target was authorised;
  • enforce our terms.

  We balance these against your rights and interests, and we do not rely on them where yours override ours. You can object to this processing at any time — see section 13.

• Legal obligation — to receive, verify and answer requests from people exercising their data protection rights within the statutory period, and to keep the record that a consent was given.

• Consent — for non-essential cookies and browser storage, asked separately on the website and in the product. You can withdraw consent at any time, and withdrawing it does not affect processing already carried out.

For data we process on a customer’s behalf as a processor, the customer is the controller and determines the legal basis.

7. Sharing and subprocessors

We share information with categories of service providers that help us operate the Service: repository hosting and integration, authentication, approved AI and coding providers, payment and sale of credits, transactional email, our own email and support mailboxes, meeting scheduling, CDN and security edge, analytics (website and product, each only with the matching consent), website performance measurement, and hosting and infrastructure. Those that handle your code and reports are named on the Subprocessors page, which is the authoritative list and serves as Annex 3 to the DPA; changing it triggers 30 days’ notice.

We may also share information when required by law, to protect rights and security, in connection with a business transaction, or with your consent. We do not sell personal information. The Subprocessors page names every provider, on both sides of the line between those that receive customer content and those that do not.

8. Cookies and browser storage

Enji Guard uses cookies and browser storage for two purposes: to keep you signed in and the Service secure and working, and — only if you agree to it — to measure how the website and the product are used. The first kind is strictly necessary or functional and is not asked about; the second is always a choice.

On the public website, Google Analytics and first-party attribution storage start only after you accept them. Before you make a choice, neither runs. You can reject optional storage and carry on using the site, and you can change your mind at any time using the Cookie settings button in the site footer.

Inside the product we store your signed-in identity, your language, theme and interface preferences, and the state of audit runs in progress. No advertising and no attribution storage. The identity items are strictly necessary and the preference ones are functional, which is why they are not gated behind a choice — the Cookie Policy explains that exemption and lists every entry.

Product analytics has its own consent. Google Analytics also runs inside the application, measuring which milestones you reach so we can see where the product works and where people get stuck. It is asked for separately from the website’s banner, and the two answers are independent — refusing one does not refuse the other, and either can be changed without touching the first. Refuse the product’s and no events are sent. The Cookie Policy lists every key.

The full inventory — what each entry is called, who sets it, what it is for, how long it lasts, and where the data goes — is on the Cookie Policy page, which is kept current as the front end changes.

9. Automated decisions and profiling

Enji Guard is an automated product.

The Service scores repositories, classifies findings by severity, generates reports and proposes code changes. All of that is automated and AI-generated.

Nothing the Service produces is used to evaluate a person. We do not profile individuals, we do not score developers, and we do not use reports or findings to assess anyone’s performance, reliability or conduct.

Nor do we stop you doing so with your own data — if you use Guard’s output to assess your own people, that is your processing and your obligation under Article 22.

The decision that would engage Article 22 if it were automated is suspension, and it is not automated. Accounts can be suspended or limited for abuse, suspected compromise, fraud, or breach of the Terms, and losing access to a service you have paid for is a significant effect. An authorised person makes that decision, on the signals available to them, and the record we keep of it names who acted and when. Article 22 therefore does not apply — but the protections it would require do not depend on that, and you have them anyway:

• You are told when an account is suspended, and why.
• You can contest it, and a person who was not involved in the decision reviews it.
• You can put your side of it before that review concludes.

Write to contact@enji.ai. Terms section 21 sets out the rest of what happens on suspension, including what happens to your credits.

10. Human access

Access by our team is least-privilege and need-to-know, and only for support, security, incident response and abuse prevention. It is logged — who, what and when — and those records are security logs, held for up to 24 months under section 11.

What our team can and cannot reach is set out item by item in DPA Annex 2, Who can see what, which is the authoritative version — repositories, audit reports, task context, execution logs, auto-pentest reports, account data, support messages and your GitLab token, each answered separately.

One point from it matters here. We cannot browse your repositories — but audit reports are made of your code, and we can see the parts of it a report quotes. “No repository access” and “no visibility into your code” are not the same thing.

11. Retention and deletion

We keep information for as long as needed to provide the Service, maintain audit history, support customers, comply with legal obligations, resolve disputes, and enforce agreements. Retention is purpose-based and may differ by data type, deployment model, and agreement.

Execution workspaces are temporary, while reports, findings, artifacts and audit history are retained as product records.

The periods we can give you are these. The full table, with the categories specific to the product, is on Data Retention & Deletion.

Where a period above conflicts with a legal obligation to keep something longer, the obligation wins and we keep only what it requires.

Revoking access or deleting a project stops future use but does not automatically delete historical records.

You can delete your account yourself, with its data and audit results, and a service administrator can do it at your request. It is permanent — there is no recovery window. Export anything you want to keep first. A copy can persist in backups for up to 7 days until they are overwritten; until the cycle completes that copy is permanently deleted.

A short, closed list of things survives deletion — payment records held by Freemius, a record that a deletion happened which identifies nobody, task context already sent to an AI provider, anything you chose to publish, and a shared project that another authorised owner still holds. DPA section 8 is the authoritative statement of that list and of what each one means for you; it is not repeated here. See also the Data Retention & Deletion page.

12. International transfers

Your repository content and reports are stored in Europe. The Service runs on Google Cloud infrastructure in its europe-west regions, and that data does not leave Europe at rest.

“At rest” is doing real work in that sentence, so here is the whole picture. Several things reach outside Europe. Four of them involve your code, your reports, or what you write to us — our team, which reaches it; the AI providers, which receive it; Cloudflare, which carries it in transit; and Resend, which emails you your result summaries. The rest involve no content of yours — analytics, website performance measurement, and the page you book a demo on. Payment data is separate again, and it is not outside our own arrangements: Freemius Inc is in the United States and acts as our processor for it, under the Standard Contractual Clauses and the UK Addendum in its agreement with us. See section 1 for the split in its role.

Our team. Our engineering and support team is located in the Kyrgyz Republic, and access from there counts as an international transfer even though your data itself stays in Google Cloud in Europe.

What travels is narrower than it sounds. Not your repositories — the team cannot browse your code at all. What they can reach is set out item by item in DPA Annex 2 and summarised in section 10 above: reports and the code they quote, task context, masked logs, account and credit data, and anything you send to support. The transfer is real and we treat it as one.

The Kyrgyz Republic is not covered by a UK or EU adequacy decision. These transfers are made under appropriate safeguards: the UK International Data Transfer Agreement (or the UK Addendum to the EU Standard Contractual Clauses) for UK data, and the EU Standard Contractual Clauses for EEA data, supported by an assessment of the risks of the transfer. The same instruments cover every sub-processor on the Subprocessors page.

The United States is covered by an adequacy decision — the EU–US Data Privacy Framework, with a UK Extension — but only for organisations certified to it. We do not rely on it. Our US transfers are made under the Standard Contractual Clauses, which hold regardless of a provider’s certification status.

AI providers. Selected task context is sent to approved AI and coding providers, which are established in the United States and process it under their own data processing terms. Those agreements incorporate the EU Standard Contractual Clauses and the UK Addendum. See the AI Data Use page for what may be sent, and the Subprocessors page for the providers themselves.

Our CDN and security edge. Cloudflare sits in front of the Service and the website, operates a global network, and is a United States company. Your IP address and request metadata pass through whichever of its locations serves you, which is not always inside Europe. So does your content, in transit: TLS is terminated at that location, so the traffic is decrypted there — including the bodies of the reports you read in the product. Cloudflare has no access to your data as we store it; what it keeps at the edge follows its own service configuration and retention arrangements. Decryption outside Europe makes this a restricted transfer, and we treat it as one.

Outbound calls do not go through Cloudflare. When the Service talks to GitHub, to GitLab, or to an AI provider, that traffic does not pass through it.

Notification email. When an audit or an Autofix run finishes, we can email you about it, and that email carries a result summary, the project and repository names, and links to the result. Our email provider is in the United States, so a description of your findings leaves Europe in that message and sits in the provider’s logs for 30 days. It is named on the Subprocessors page and engaged under the Standard Contractual Clauses and the UK Addendum.

Our own mailboxes stay in Europe. When you write to support, your message and anything you attach to it arrives as email in our Google Workspace mailboxes. Workspace data regions are set to Europe, which covers the subject, body, senders, recipients and attachments at rest and in processing, so this correspondence does not leave Europe. It runs under the same data processing addendum as Google Cloud, with the same Standard Contractual Clauses and UK Addendum behind it.

Data regions do not cover logs or cached content, so that data is not pinned to a region. The operational alerts our systems send the team arrive in the same mailboxes but carry only a task identifier and a link — no code, no report, nothing written by you.

Booking a demo. If you book a meeting with us, the scheduling provider processes what you enter on the booking page, in the United States and the other locations its privacy notice describes. It receives no code, no reports and no task context.

Analytics, and only what you have agreed to. It involves no content of yours — it sees events, not data. Google is a United States company, and Google Analytics receives two different things depending on which consent you gave. On the website: usage data about your visit. In the application: which product milestones you reach, tied to your account. Refuse either and nothing of that kind is sent for it — the two answers are independent. Neither involves your repository content. See the Cookie Policy.

Website performance measurement. A separate, cookieless Cloudflare beacon on the public website measures whether pages are fast and working. It writes nothing to your browser, which is why it sits outside the consent banner, but it does process your IP address and request metadata at Cloudflare. We rely on our legitimate interest in knowing our own site works, and you can object — the Cookie Policy says how.

You can request a copy of the transfer safeguards we rely on at contact@enji.ai.

13. Your choices and rights

If you are in the UK or the EEA, you have these rights, subject to the conditions the law sets: access, rectification, erasure, restriction, portability, objection, and withdrawal of any consent you gave. Elsewhere you may have the same or similar rights under your own law, and we apply this section to everyone regardless.

You can also delete your account with its data and results, revoke the GitHub App, delete projects, repositories or sites, and disable schedules and jobs.

How to make a request. Write to contact@enji.ai, or use the Trust Center our EU representative runs at app.prighter.com/portal/16660917026, which asks for what we need up front. Either route reaches us. We may need to verify who you are first. We answer within 30 days. If a request is complex or you have sent several, we may extend that by up to two further months — we will tell you within the first month if we do, and why. There is no charge unless a request is manifestly unfounded or excessive.

Our representative in the European Union under Article 27 GDPR is:

Prighter EU Rep GmbH Schellinggasse 3/10, 1010 Vienna, Austria Registered in the Austrian Firmenbuch, FN 639035 h support@prighter.com

Our representative in the United Kingdom under Article 27 UK GDPR is:

Mad Devs Group Ltd 27 Old Gloucester Street, London, WC1N 3AX, United Kingdom Company number 11793394 privacy@maddevs.io

If your details appear inside a customer’s repository, neither route is the right one. There our customer is the controller, and we pass your request to them within five business days rather than answering it ourselves.

You can also complain to a data protection authority. In the United Kingdom that is the Information Commissioner’s Office (ico.org.uk). In the European Economic Area it is the supervisory authority of the country where you live or work. We would prefer you raise it with us first, but you do not have to.

14. If there is a breach

Where we are the controller — accounts, billing reconciliation, support, website data — and a personal data breach is likely to result in a high risk to your rights and freedoms, we will tell you without undue delay, in plain language: what happened, what data was involved, what we are doing, and what you can do. We will notify the supervisory authority within 72 hours where the law requires it.

Where we are the processor — anything from your repositories — we notify our customer, who is the controller, and it is their call whether and how to tell the people affected. That path is in DPA section 7.

15. Children

Enji Guard is not for children. You must be at least 18 to use it — see Terms section 5 — and we do not knowingly collect personal data from anyone under 18. If you believe a child has given us data, write to contact@enji.ai and we will delete it.

16. If you are in the United States

Some US state privacy laws, including California’s, give you specific rights. We apply them wherever you live in the US.

We have never sold your personal information and we do not share it for cross-context behavioural advertising, so there is no opt-out to offer.

The categories we collect, why, who receives them and how long we keep them are in sections 2, 5, 7 and 11 above, which together are the notice at collection. We do not use sensitive personal information to infer characteristics about you.

You may ask us to tell you what we hold, give you a copy, correct it, or delete it, and we will not treat you differently for asking — no worse price, no reduced service. Write to contact@enji.ai. You may use an authorised agent; we will ask for proof of authority.

17. Who to contact

For anything about your personal data, write to contact@enji.ai, or reach either of the representatives named in section 13.

18. Changes to this policy

We may update this Privacy Policy as Enji Guard, deployment models, or legal requirements change. The updated version is posted here with a new effective date.

If a change materially affects you — a new purpose, a new category of recipient, a new transfer destination, or a narrowing of your rights — we will tell you at least 30 days beforehand, by email to your account contact or a notice in the product. This matches the notice the Terms section 26 and the DPA section 11 already promise.