Security and compliance for software and AI, built in

Most breaches do not start with a brilliant attacker. They start with a forgotten dependency, an API key committed two years ago, an admin account nobody closed, or a chatbot that will read anything you put in front of it. Security and compliance for software and AI is mostly the discipline of closing those doors before someone tries them, and being ready for the day one is opened anyway. We do it as the engineers who build and run the software, which means the fixes land in the code and the infrastructure, not in a slide deck.

Secure by architecture, not by checklist

A checklist tells you what to verify. Architecture decides how much damage a single mistake can do. We start by mapping your data flows and access rights, then shrink the blast radius: least-privilege IAM roles, secrets in a managed store rather than in environment files, separate environments, encryption at rest and in transit, and infrastructure described in Terraform so that every change is reviewed. On the application side we work through the OWASP Top 10 and the OWASP ASVS for web, and OWASP MASVS for mobile apps: authentication, authorisation on every endpoint, input handling, session management and the dependencies you inherit from open source.

AI features have their own attack surface

A language model connected to your data and tools is a new kind of component. The OWASP Top 10 for LLM applications names the risks plainly: prompt injection, sensitive information disclosure, excessive agency, insecure output handling, supply chain issues. Our position is simple. Treat everything a model reads as untrusted input. Give an agent the narrowest set of tools it needs, through explicit interfaces such as MCP servers with scoped permissions. Never let model output reach a database query, a shell or an email without validation. Keep a human approval step on actions that cost money or cannot be undone. Log prompts, tool calls and outputs so you can see what happened. And choose where the data goes: an EU-hosted model from Mistral, a provider contract with no training on your data, or an open-weight model on your own infrastructure.

Compliance as a by-product of good engineering

GDPR, the EU AI Act and NIS2 ask for different things, but they share one demand: show that you know what you run and that you control it. If the engineering is clean, most of the evidence already exists. For GDPR we document processing activities, retention, processors and data subject requests where they actually happen in the code. For the AI Act, which entered into force in 2024 with obligations phased in over several years, we build an inventory of your AI systems, classify each by risk level and record the transparency and oversight measures in place. For NIS2, which widens EU cybersecurity duties to many more sectors and mid-sized companies, we help you determine whether you are in scope and what that would require. We do not give legal advice and we do not sell certifications; we produce the technical ground your lawyer or auditor will ask for.

Keeping the platform safe and up to date

Security decays quietly. Frameworks release patches, certificates expire, a library is abandoned, a former contractor still has access. Our maintenance work is the boring, essential part: dependency and framework updates on a fixed rhythm, security patches applied quickly, backups that are tested by actually restoring them, uptime and error monitoring with alerts that reach a person, and quarterly access reviews. Each month you get a short report of what changed, what we found and what we recommend. When an incident happens, the runbook is already written, the logs already exist, and the first hour is spent containing the problem rather than looking for passwords.