Security and trust

You own the work

Everything we produce for you is yours: the repository, the infrastructure definitions, the prompts, the eval sets, the documentation and the design files. Ownership transfers as it is created, not at final payment.

We build in your GitHub organisation and deploy into your cloud accounts from the first commit, so there is no migration at handover and no period in which the work lives somewhere you cannot reach.

• →No agency-owned framework you would have to license to keep using.
• →No dependency on us being reachable to deploy, roll back or operate what we built.
• →Where we reuse an internal utility, it is contributed under a permissive licence or vendored into your repository.

Confidentiality

We will sign your NDA. If you would rather use ours, we have a mutual one that covers both directions and takes about five minutes to read.

We do not name clients, quote from their systems or use their work in our marketing without written permission. That is why the case studies on this site are described at sector level.

Your data and AI models

This is the question that stalls most enterprise deals, so it is answered directly.

• →Nothing you give us is used to train a model. Not ours, not a provider's. We use enterprise API tiers where the provider contractually excludes training on API inputs, and we confirm that in writing per provider before any client data reaches one.
• →Provider agreements are in place before data flows. Data processing agreements with each model provider, and the subprocessor list below is complete.
• →Region pinning where you need it. Model and storage regions are pinned at design time to the jurisdictions your data may be processed in, and are part of the architecture document rather than an afterthought.
• →Retention is minimised deliberately. Prompts and completions are logged for evaluation only where you have agreed to it, with a stated retention period and PII redaction before storage.
• →Redaction before transmission. Where a workflow does not need an identifier, it is stripped or tokenised before the request leaves your infrastructure.

Secrets and access

We ask for the least access that lets the work happen, and we ask for it to be time-boxed.

• →Credentials live in your secret manager — AWS Secrets Manager, Vault, or your platform's equivalent. Never in a repository, never in a chat message, never in a shared document.
• →Access is per-person and named, never a shared account, so it can be revoked individually and an audit log means something.
• →Production access is requested only when it is needed to diagnose something, and is removed when that work ends.
• →Multi-factor authentication on every account that touches your systems, and full-disk encryption on every machine.

Dependencies and vulnerabilities

Supply chain is treated as part of the build, not as a periodic audit.

• →Automated dependency scanning on every pull request, with the build failing on a known high-severity advisory.
• →Lockfiles committed and dependency updates reviewed rather than merged automatically.
• →Static analysis and secret scanning in CI, so a committed key is caught before it is pushed.
• →A new direct dependency is a decision with a stated reason, not a convenience.

Subprocessors

The third parties that can see data submitted through this website. This list is complete, and it changes in the same commit as the code that would change it.

• →Vercel Inc. — hosting. Processes standard request data for every page served.
• →Resend (Plus Five Five, Inc.) — transactional email. Delivers contact form submissions to our inbox.
• →Subprocessors for a client engagement are specific to that engagement, listed in the architecture document, and agreed before any data reaches them.

Responsible disclosure

If you have found a vulnerability in this site or in something we built, email contact@algologix.co with the word `security` in the subject. We will acknowledge within one working day and tell you what we are doing about it.

We will not take legal action against anyone who reports a genuine issue in good faith, gives us reasonable time to fix it, and does not access or alter data that is not theirs.

Where we are going

We are a company founded in 2026 and we are not going to claim certifications we do not hold. What we have today is the posture above, applied consistently and checkable in the work.

SOC 2 Type II is the intended next step, driven by the first client engagement that requires it rather than by a marketing date. We will say so here when the audit starts, not when it is considered.