The security questionnaire.

No. We hold no security certifications and no external attestations of any kind. There is no audit report to send you, and there is no badge on this site, because there is nothing behind one. If your process has a hard certification gate, we will not clear it, and it is better for both of us that you learn that in the first week rather than the sixth.

We implement the controls those frameworks describe, document them for the specific system rather than in the abstract, and design so that the evidence your own auditors need is produced by the system itself. Everything on this page is answerable in writing, with the engineer who built the thing on the call. That is a weaker artefact than an audit report and we will not pretend otherwise; it is also more specific than one.

Probably, when the size of the firm and the shape of the work make it meaningful rather than decorative. When it happens it will appear on this page with its scope and its audit date. Until then this page says what is true.

A small senior team based in Barcelona, Spain, working with clients across the EU and remotely. Small is a genuine risk factor in a vendor assessment and we would rather you weighed it than discovered it. The continuity section below is the honest answer to what that risk actually is.

The people on your first call are the people who build the system. Where an engagement genuinely needs a specialist we do not have, we name them to you before they start rather than presenting them as staff, and they work under the same terms we do.

In the ordinary case, exactly where it lives today. Systems we build are deployed into your cloud accounts and run against your data stores, under your contracts with your cloud provider. We write the code, configure the infrastructure as code in your accounts, and hand over the keys. The personal data does not enter our systems at any point.

Sometimes, for a defined reason and a defined period: a debugging window against production, a migration we run, or an evaluation set built from real records. Those are covered by a data processing agreement signed before access is granted, and the data is returned or deleted at the end with written confirmation. Everything else is designed so the question does not arise.

Yes. EU regions for compute and storage, EU-region model endpoints, or open-weight models entirely inside your own perimeter where nothing may leave it at all. Residency is captured in discovery because it constrains model choice, and discovering it in week six means rework rather than a configuration change.

The same mechanism, different regions. The constraint that actually bites is rarely the storage region — it is which model endpoints are available in it, and how much capability you give up by pinning to one. We put that trade-off in writing during design rather than discovering it at deployment.

Not by default. We work from schemas, synthetic records and, where a task genuinely needs realistic input, a sampled and minimised extract agreed with you. Where production access is unavoidable for a specific piece of debugging, it is time-boxed, logged, and covered by the agreement before it starts.

They are in your accounts, under your retention policy, which is one of the quieter arguments for the whole arrangement. Where we do hold data, derived artefacts — embeddings, caches, evaluation sets, logs — are enumerated in the agreement rather than forgotten, because those are the copies that survive a deletion request that only touched the source record.

Yes. Every network path in a system we build uses TLS, including internal service-to-service calls and calls to model providers. We do not ship a design that carries client data over an unencrypted channel, and where a legacy system on your side does, that becomes a finding in the architecture document rather than something we quietly work around.

Yes, using the storage encryption of the platform it sits on, enabled explicitly in the infrastructure code rather than assumed from a default. Because the deployment is normally in your accounts, the keys are yours: your key management service, your rotation policy, your ability to revoke. We can build against a customer-managed key where your policy requires one.

You do, in the common arrangement, and that is deliberate. A vendor holding the keys to your data is a dependency you have to manage; a vendor who never had them is not. Where we hold data during a defined window, keys are held in the platform key service of that environment and access is revoked at the end of the window along with everything else.

Only where a client asks for it, and we will always describe the alternative first. Our default recommendation is your infrastructure, because it collapses a whole category of questions on this page into one answer: it is in your account, under your controls.

Named individual accounts issued through your own identity provider, scoped to what the work needs, for the duration of the work. No shared logins, no team credential in a document, no standing account left behind after handover. Where you can issue just-in-time or time-limited access, we would prefer that to a permanent grant.

Less than most people expect, and we would rather argue the scope down at the start than ask for administrator and sort it out later. A typical build needs repository access, a deployment role in a non-production account, and read access to the schema. Production access is requested separately, for a stated reason, and is often not needed at all.

Revoked at handover as a named step in the handover checklist, and we ask you to verify the revocation from your side. Taking a vendor's word that its access is gone is one of the weakest links in most third-party programmes, and it costs you ten minutes to check.

That is the central control, and it is where the real security work in an AI system happens. Every tool an agent can call gets the narrowest scope that lets it work: read-only by default, writes scoped to specific records, destructive operations removed or gated behind a confirmation the model cannot forge. The design question is always what the worst outcome is if the model is fully compromised.

As the user, wherever the platform allows it. Tool calls are authorised against the end user's permissions rather than a service account's. Without that, a system holding broad credentials makes every user an effective administrator of everything it can reach — the confused-deputy problem, and the most common serious flaw we find in existing deployments.

Yes, on every account of ours that supports it, with hardware-backed keys or passkeys where the platform offers them rather than codes over SMS. We will also decline access to a client system that offers no second factor unless there is a compensating control, because an account of ours is a route into your environment.

Full-disk encryption on, screen lock enforced, operating system and browser kept current, and no client source code or data on removable media. Devices are individually assigned; there is no shared machine.

We do not operate a full mobile device management estate with enforced policy and central reporting, and we are not going to describe a handful of well-configured machines as one. If your policy requires managed and monitored endpoints for any vendor with access, that is a real gap on our side and worth raising before contracting.

In a secret manager, never in a repository, a configuration file or a chat message. In the systems we build, credentials are resolved inside the tool after the model has decided to call it, so they never enter a prompt or a context window — a model that never sees a key cannot leak one, and anything in context should be assumed extractable.

Rotate first, investigate second. Any credential that has plausibly been exposed is treated as compromised rather than assessed for whether it really was, because the assessment takes longer than the rotation. Where the credential is one of yours, you are told immediately, not after we have decided how bad it was.

Yes, on configurations that do not train on inputs, and we will tell you which. If your contract prohibits it for your repositories, say so and we will work without them. Our position on how we use AI in our own work is published on the AI use page rather than left to be discovered.

No. Everything in this section is our own statement about our own practice, unverified by anyone outside the firm. We think saying that plainly is more useful than the alternative, and it is the same reason there is no badge at the top of this page.

In the systems we build: prompts, retrieved context, tool calls, tool results and outputs, with a correlation identifier per interaction so a single decision can be reconstructed end to end. Without the tool calls, the interesting half of an incident is invisible — you can see what the system said and not what it did.

That is what the trace is for. For a retrieval system, the answer carries the passages it was drawn from, so an unsupported claim has no citation and a reviewer can spot it. This makes model error attributable rather than absent, which is the achievable goal and the one worth designing for.

In your logging platform, under your retention policy. Retention is set per data class and enforced by a job rather than by intention, because a conversation log is enormously useful for debugging and enormously risky as an unbounded store of personal data. Logs are also a common accidental second copy of data in a system with weaker controls, so what gets written is a design decision, not a default.

They can be, and whether they need to be is a design question we will ask you. Append-only storage with restricted write access is straightforward to arrange in every major cloud; it costs something in complexity and is worth it where a decision may later be disputed, in a regulated process or one that affects a person's money.

For our own business — this website, our email, our documents — the list is on the sub-processors page, and clients under a data processing agreement are told in advance of a change with time to object. For a system we build for you, the model and cloud providers are contracted by you, chosen with you during design, and named in your own records of processing rather than ours.

Whichever your constraints select. We are not a reseller for any provider and have no incentive to prefer one. Selection is driven by residency, retention terms, capability on your actual task and cost at your volume, and the design puts the model behind an interface so that changing provider later is an engineering task rather than a rebuild.

Not on the enterprise paths we deploy. At the time of writing, hosted providers offer enterprise endpoints that exclude training on inputs and, on some tiers, zero-retention configurations; availability varies by provider, model and tier, and several retain inputs for a period for abuse monitoring unless a specific agreement is in place. We configure the option, verify it, and record what was actually enabled in the architecture document rather than pointing at a general policy page. Those terms are between you and the provider and they change — confirm against the provider's current terms.

Then the answer is open-weight models on infrastructure you control, where the question does not arise because nothing leaves your perimeter. There is a real capability trade-off on the hardest reasoning tasks, and we scope which parts of a system genuinely need the constraint rather than applying it uniformly and paying for it everywhere.

By what can actually be established: who trained it, who operates it, what the licence permits, what the provider says about retention, and how it performs on an evaluation set built from your data rather than a public leaderboard. Provenance for model weights is weaker than for software packages, and we treat that as a known limitation rather than an answered question.

Contain, notify, investigate, remediate, write it up. Containment usually means revoking credentials and stopping the affected process, which we do before we know how serious it is rather than after. Notification to you comes at the same stage, not at the end.

Without undue delay, and in any case within twenty-four hours of becoming aware of an incident affecting your data, so that you have room inside your own seventy-two hour obligation to a supervisory authority. That commitment goes in the data processing agreement rather than staying a statement on a web page.

What happened, what data was involved, when it started and when it was contained, what we have done, and what we do not yet know. The last part is the one most incident notifications omit and the one you need to plan around.

You do. In the ordinary arrangement you are the controller, so the assessment and the notification are yours to make, and our job is to give you the facts fast enough and completely enough that you can make it. We will help assemble the technical narrative and the log evidence.

No incident affecting client data has occurred. We would not treat that as evidence of much: we are small, the attack surface is correspondingly small, and an absence of known incidents is not the same as an absence of incidents. It is one of the reasons logging and revocation verification matter more to us than a clean history.

Your system keeps running, because none of it depends on us. The code is in your repositories, the infrastructure is defined as code in your accounts, the model and cloud contracts are yours, and there is no proprietary platform, licence or runtime call home. The worst case is that you need another engineering team, not that the system stops.

Written down as the work happens rather than assembled at the end: the architecture and data-flow document, the decisions and why the rejected options were rejected, the evaluation set and how it was built, the runbook. Handover documentation is part of the work, not a paid extra, and it is written to be usable by a team that has never spoken to us.

That is the intended end state of most engagements. We will run a handover with your engineers against the runbook rather than sending the document and wishing them luck, and we would rather be retained afterwards because the work is good than because leaving is difficult.

For the systems we build, recovery objectives are a design input and the recovery path is exercised before go-live where the workload justifies it. For our own business, we do not run a formally tested continuity programme, and the honest mitigation is the one above: our disappearance does not take your system with it.

The systems we build are tested by whoever you engage to test them, and we do not sell that service, which keeps the incentive clean. What we do is design so that your test is cheaper and more useful: documented trust boundaries, a written threat model for the agentic layer, and an architecture where the interesting attacks are enumerated in advance rather than discovered by a tester on the clock.

Yes, and we would rather be in the room. We will brief them on the AI-specific attack surface, which a conventional application test is usually not scoped to cover, and we will remediate findings rather than dispute them. A test that finds nothing because it was pointed at the wrong layer is worse than no test.

Yes, as a standalone engagement, typically one to two weeks producing a written findings document with severity ratings and concrete remediations, focused on the agentic layer specifically. It is deliberately narrow: it is not a substitute for an application penetration test, and we say so when scoping it.

An evaluation set built in the first week from real inputs with human-verified correct outputs, scored automatically and run as a gate before every deploy. Without it, quality is anecdote and a model version change is a leap of faith. It is the highest-leverage thing in an AI project and the most commonly skipped.

As an authorisation problem rather than a filtering one. Anything retrieved — a document, a ticket, an email, a web page — is treated as untrusted data and is structurally prevented from authorising a tool call. Filtering helps at the margins and cannot be the primary control, because the attack surface is the entire content of everything the system reads.

No, and be sceptical of any vendor who says it can. What is achievable is making a successful injection inconsequential: if it cannot reach a capability that matters, it is a curiosity rather than an incident. Designing for a small blast radius is a more reliable strategy than trying to catch every hostile string.

Capability limits rather than instructions. Destructive operations are removed from the tool set or gated behind a human confirmation; spend and iteration caps bound a confused loop, which is a denial-of-wallet vector as much as a reliability problem; and anything with a material consequence produces a proposed action that a person commits.

Always. Schema validation and range checks first, constrained decoding where the provider supports it. Never an evaluated expression, never raw SQL, never a shell command assembled from generated text. Output that parses is not the same as output that is correct, so validation and evaluation are separate controls and both are present.

Per engagement, yes, covering injection, tool abuse, excessive agency, data exfiltration through outputs and supply-chain risk in the model layer, with the mitigation for each in the proposed design. Most generic questionnaires do not ask about any of this, which is precisely where the risk in an AI system sits.

We do not operate a formal third-party screening programme, and we will not describe a small team who all know each other as one. Everyone with access to a client environment is named to you, is bound by written confidentiality obligations, and is a person you have met. If your policy requires documented screening for any vendor personnel with access, that is a requirement we would need to meet specifically rather than one we can evidence today.

Not as a certificated annual course with a completion record to send you. The practical version is that this is the subject the firm works in, and the threat model on this page is the one we apply to ourselves. That is a weaker answer than a training log and it is the true one.

Tell us what cover your contract requires and we will confirm in writing what we hold before anything is signed, rather than publishing policy details on a web page. If the required cover is something we do not have, you will hear that from us rather than finding it in a schedule.

Yes, in the ordinary case, and we read them rather than signing and hoping. Where a clause commits us to a control we do not operate or a certification we do not hold, we say so and propose language describing what we actually do. The DPA page sets out which clauses those usually are.

Ask, and we will arrange one where the client agrees to it. Most of our work is under a confidentiality agreement, so we publish reference architectures rather than case studies, and the projects we can name are on the work page with what we built and what we did not.