AI Data Use

Effective date: 2 October 2026

Enji Guard audits code with AI and automated agents, using approved third-party AI and coding providers so the Service can run the audits you select. This page explains what may be sent to them, what we do not do with your code, and how customer-controlled deployments change the picture.

What data may be sent to AI providers

To run the work you select, the Service may send selected task context to an AI or coding provider — for example code snippets, file paths, dependency manifests, configuration, logs, and audit findings needed for that task.

Task context is assembled by the audit, not screened by a person. The Service sends the files an audit needs, their dependencies and the surrounding configuration. It is not filtered for content, so anything present in those files — personal data, credentials in fixtures, records in test data — goes with them.

We do not redact or minimise it. Elsewhere we say task logs are masked for secrets and tokens — that is about logs only. The code itself goes as it is: you choose what to connect and what to run.

The same context is visible to us. Task context is reachable by our team on a need-to-know basis for support, security and incident work, and that access is logged — see DPA Annex 2, Who can see what.

What to do about it, in order of effort: scope repository access to what an audit actually needs; keep real data out of fixtures and test files; and where neither is enough, use a customer-controlled deployment so calls run through your own provider accounts — described below.

Training — ours and theirs

We do not train or operate Enji-owned models on your content. We also do not sell your code or personal data, and we do not use it for advertising.

Our AI providers do not train their models on what we send them either. We use their API tiers, where not training on customer inputs is the contractual default, and we have not opted in to anything that would change it. That is a commitment we hold from them rather than one we can make on their behalf. A customer-controlled deployment removes the dependency altogether.

Not training is not the same as not retaining. A provider may still hold inputs briefly for abuse monitoring. See below.

Third-party provider terms

Approved providers are our sub-processors, not independent controllers. They process your task context on our instructions under signed data processing agreements — named on the Subprocessors page — and we remain answerable to you for what they do with it. Their own published terms describe their service; they are not the basis on which your data is processed.

What does differ by provider and route is default retention and abuse monitoring, which their agreements permit and we cannot override.

Because of this, we do not represent that every provider route is zero-retention.

Customer-controlled deployment

Self-hosted and customer-controlled deployments can restrict the approved providers and routes the Service uses, including bring-your-own-AI, where you use customer-controlled AI provider routes or credentials so calls run under your own accounts and agreements.

Where AI providers process data

Approved providers process selected task context on their own infrastructure, under their own data processing terms. Processing may take place outside the United Kingdom and the European Economic Area, including in the United States. Where it does, the transfer is made under the safeguards described in Privacy Policy §12.

We rely on each provider’s data processing agreement and published subprocessor information rather than on independent verification of where their servers physically sit.

Approved providers

The providers are named on the Subprocessors page, as above. Per-provider retention and route detail is available on request.

The named list applies to the hosted Service only. Under a customer-controlled deployment you choose your own providers.

The EU AI Act

Article 50 of Regulation (EU) 2024/1689 has applied since 2 August 2026, and it requires that people be told when content is AI-generated. Enji Guard generates text and code that lands in your issues and pull requests.

Our position, and the reasoning behind it. We are a provider of a generative AI system. Article 50(2) concerns synthetic audio, image, video and text produced for the general public; the obligation to mark output is aimed at content presented as authentic or published broadly. What Guard produces is code, findings and reports delivered to the customer who asked for them, inside their own repository, under their own review, with a human merging every change. It is not published to the public by us and it is not presented as anything other than machine output.

We mark it anyway. Issues, comments and pull requests that Guard creates are attributable to Enji Guard — the GitHub App is Enji Guard and the Git author identity you configure appears on the commits — so nobody in your repository is left guessing whether a person or a machine wrote it. See GitHub App Permissions.

Where it becomes your question rather than ours. If you take Guard’s output and publish it onward — a public project view, a security advisory, a blog post — you are the one making it public and Article 50 looks at you, not us. The same goes for any downstream use as a deployer.

Generated output

AI-assisted output can be incomplete or inaccurate and is decision-support, not a guarantee. Review outputs before acting on them.

AI can also generate material that resembles or reproduces work belonging to someone else. We do not represent that generated code or findings are original or free of third-party rights — review generated code before you use it, as you would review a contribution from any outside source.

We make no claim of ownership over the output the Service generates for you. See Terms of Service section 13 for the full position.