Security & Trust

Effective date: 2 October 2026

This page describes, in plain language, how Enji Guard accesses your code, runs audits, and handles secrets, payments, and data. It covers the current product; specific deployments may add controls by agreement.

Repository and target access

Enji Guard works with the repositories you connect and, for active checks, the website and API targets you authorise. It does not request access beyond what you select.

Repository access runs through a GitHub App — named Enji Guard on GitHub — and is limited to the repositories you grant it, whether you pick individual ones or grant access to all of them. Access is verified before a task uses a repository.

The app holds read and write access to code, issues and pull requests, because write access to code is the level GitHub requires to create a branch and open a pull request. We use it only for that. We do not merge pull requests and we do not deploy, and we write commits only to branches we create for a change we are proposing — never to a branch that already exists, including your default branch. See GitHub App Permissions for the full list and why each one is there. You can revoke access at any time in your GitHub settings.

Where your data is stored

Enji Guard runs on Google Cloud in its europe-west regions. Your repository content and reports are stored in Europe and do not leave it at rest.

Some processing reaches outside Europe, our own team included. Privacy Policy §12 is the authoritative description of every such transfer and the safeguards that apply, and DPA section 10 carries what we commit to as your processor.

What we are notified about

Where webhooks are enabled, we are told when an issue, a comment, or a merge or pull request is created or changed — three event types, no more. We are not subscribed to push events. The full list, and what we are deliberately not subscribed to, is on GitHub App Permissions and GitLab Access.

Notification email

When a run finishes we can email you about it, and that email carries a summary of what the run found, along with project and repository names and links to the result. It goes through a transactional email provider, named on the Subprocessors page, which holds the message and its delivery logs for 30 days. If that is more than you want leaving your own systems, turn result notifications off in your notification preferences.

Execution and runtime

Repository-backed tasks run in isolated, ephemeral containers. After a task completes, the container is shut down and removed together with the cloned repository code.

Credentials and secrets

Provider credentials and other secret material are stored encrypted, and access to them is restricted. Task logs are masked by default to avoid capturing secrets, tokens, raw authorisation headers, or model-provider credentials.

This page describes the measures; it does not define them. The full list we are contractually bound to — encryption, isolation, access control and logging, separation, patching, secure development and incident response — is DPA Annex 2. Where the two read differently, Annex 2 is the one that binds us.

Never send us a secret in a support request. Do not paste provider tokens, repository secrets, or private report content into a ticket or an email. Support reaches us as email in our own Google Workspace mailboxes — named on the Subprocessors page, stored in Europe — so anything you send is kept there as mail under our account’s retention, and a secret in a mailbox is a secret in one more place. Send target identifiers and redacted error output instead; we can work from those.

There is exactly one place a token is meant to go: the GitLab connection form in the product, where it is stored encrypted. If you have already sent one somewhere else, rotate it in GitLab and reconnect; that is faster and more reliable than our removing it from a ticket.

Repository credentials differ by provider. On GitHub we hold no long-lived secret of yours — the GitHub App receives short-lived tokens from GitHub itself. On GitLab you create an access token and give it to us, so we do hold a credential you issued, on the terms in DPA Annex 2. Use a service account or a project or group token rather than your own account — see GitLab Access.

AI model providers

Selected task context may be processed by approved third-party AI and coding providers under their own terms. Customer content is not used to train Enji-owned models. See the AI Data Use page for details.

Payments and card data

Credits are sold through Freemius, our authorised reseller and merchant of record. Your card details never reach Enji Guard. Freemius states that they do not reach its own servers either — the checkout runs on Stripe and PayPal as the gateways, and Freemius describes its checkout as PCI DSS compliant. That is Freemius’s account of its own arrangements, not something we have audited.

What our own systems store against your account is deliberately minimal: a transaction reference, the amount paid for the credits, the credits granted, and which account to credit. There is no card number, no expiry date, and no card data of any kind in our database. Billing name and address sit with Freemius, and so does everything to do with tax — our prices are exclusive of it and Freemius calculates and collects it, so we do not hold the figure.

The Service itself is operated by Enji AI LLC. See the Privacy Policy for which party is responsible for which data.

Human access

Access is least-privilege and need-to-know, and only for support, security, incident response and abuse prevention, and it is logged — who, what and when — and kept for up to 24 months.

What our team can see differs by the kind of data, and it is answered item by item in DPA Annex 2, Who can see what — repositories, audit reports, task context, execution logs, auto-pentest reports, account data, support messages and your GitLab token. That block is the authoritative version.

One point applies here directly: we cannot browse your repositories, but audit reports are made of your code — file paths, snippets, diffs, reproduction steps — 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.

Certifications and assurance

Our current technical and organisational measures are set out in Annex 2 of the DPA. We complete security questionnaires on request, and any certification we hold will be listed here.

Reporting a concern

To report a security concern or suspected vulnerability, contact contact@enji.ai. See the Vulnerability Disclosure page for what to include.