EliconStart a project →

Security & Data Handling

Last updated: 6 August 2026.

You are considering giving a small studio access to your systems, your data, and in some cases the authority to let software act on your behalf. That deserves a straight answer rather than a badge. This page is what we do, what we refuse to do, and what we will happily put in a contract.

If your security team has a questionnaire, send it — we would rather answer it than have you guess from marketing copy.

Access

  • Least privilege, always. We ask for the narrowest access that lets the work proceed, and we ask for it late rather than early. Read-only until write is genuinely required.
  • Named accounts, never shared ones. Individual accounts under your identity provider, with MFA. We will decline a shared login and ask for proper provisioning instead.
  • Your systems stay yours. Where possible we work in your repository, your cloud account, your project tracker. You keep the audit trail and you keep the off switch.
  • Access ends when the engagement ends. We ask you to revoke on the handover date, and we tell you what to revoke. If you forget, we will remind you — an unused credential is a liability for both of us.
  • No production access unless the work requires it. Most engagements never need it. Where it is required, it is time-boxed and logged.

Your data during an engagement

  • We prefer not to hold your data at all. The default is that we work against your environment. Where a copy is unavoidable, we agree in writing what is copied, where it lives, and when it is destroyed.
  • Real data comes late, and minimised. Development runs on synthetic or anonymised data wherever it will do the job. When real data is needed for evaluation, we ask for the smallest representative sample rather than a full export.
  • Special categories and regulated data — health, financial, biometric, children's data — are handled only under an agreement that names them explicitly, with the extra controls that implies.
  • Encryption in transit and at rest for anything we do hold, on managed infrastructure, with access limited to the people on your engagement.
  • Destruction on request, in writing. At the end of an engagement, or whenever you ask, we delete what we hold and confirm it.

AI, agents, and your data

This is the part most studios are vague about, so:

  • Your data is not used to train anything. Not our models, not a vendor's. Where a provider's terms permit training on API traffic by default, we disable it, and we tell you which providers are in the system.
  • We name every model provider and sub-processor before the build starts, so your DPA can list them. If you rule one out, we design around it — that is a normal constraint, not an obstacle.
  • Where data residency matters, we say up front which providers can meet it and which cannot. Some cannot, and we would rather lose that argument early than discover it at launch.
  • Agents get written boundaries — what they may do, what they must escalate, what they may never touch — and every autonomous action is logged with its inputs. An agent that can move money or delete records only exists if you asked for it, in writing, with a human approval step.
  • Our own AI tooling is used to write software, not to process your business data. Where any tooling would touch client data, it is disclosed and covered by the engagement agreement.

How we build

  • Secrets never enter the repository. Environment configuration, secret managers, and a rotation plan you can run without us.
  • Authentication and authorisation are designed in, not retrofitted. Every endpoint that touches data has an explicit access rule, and we test the negative cases.
  • Input is validated server-side against a schema, and rejected rather than coerced.
  • Dependencies are pinned, audited and kept current during the engagement, and the handover tells you how to keep doing that.
  • Backups are configured and a restore is tested before we call anything done. An untested backup is not a backup.
  • Logging without leaking. Structured logs that let you debug an incident without recording credentials, tokens or personal data you did not intend to store.

What we deliberately do not do

  • We do not take custody of production credentials we do not need.
  • We do not build systems that let an agent take an irreversible action without a human in the path, regardless of how much it would impress a demo.
  • We do not exfiltrate your data to a personal machine, a scratch account, or an unvetted tool.
  • We do not claim certifications we do not hold. Elicon is not SOC 2 or ISO 27001 certified. We build to practices consistent with those frameworks, and we say so precisely rather than implying an audit that has not happened.
  • We do not subcontract your work to an unnamed third party. See the engagement FAQ.

Incidents

If we become aware of a security incident affecting your data, we tell you without delay — first the facts, then the remediation, then the write-up. Where we act as a processor, that notification meets the timelines in the data processing agreement so you can meet yours under Article 33 GDPR.

We would rather report an embarrassing near-miss than manage one quietly.

Contracts and paperwork

  • Data Processing Agreement. Available and expected where we process personal data on your behalf. Ours or yours — we will sign a reasonable one.
  • NDA. Happy to sign before a discovery call. Ask.
  • Sub-processors listed in the DPA, with notice before any change.
  • Security questionnaires answered honestly, including the questions where the answer is "no, and here is what we do instead".
  • Right to audit clauses are negotiable and we have never objected to a reasonable one.

This website

The site you are reading has no cookies, no analytics, no tracking pixels and no third-party requests. The enquiry form is rate-limited, schema-validated, and protected against automated abuse without a captcha. Details are in the Privacy Policy.

Contact

Security questions, questionnaires, or to report a vulnerability in something we built: [email protected]. If you are reporting a vulnerability, we will acknowledge it, we will not threaten you, and we will credit you if you want the credit.