Domain · AI-assisted development

The speed of AI, with controls to match.

Your developers produce faster with coding assistants and agents. We identify the risks specific to these workflows and put suitable controls in place, without curbing productivity.

Situations

You are in the right place if…

  • Your developers use coding assistants, with no rule on what they may entrust to them.
  • AI agents open pull requests, or even run commands, in your repositories.
  • The volume of code shipped grows faster than your review capacity.
  • Unknown dependencies appear in your projects, suggested by an assistant.
  • Your developers install extensions (skills, MCP servers, plugins) that widen what the agent can read and run.
  • A client asks how you govern AI in your development.
Our conviction

Speed of production must come with suitable controls.

A coding assistant produces in seconds what a developer wrote in an hour, flaws included. An agent acting in your repositories holds rights no intern would have. Controls designed for a human pace no longer keep up.

So we adapt controls to this new pace: rules on the data entrusted, limited rights for agents, automatic checks in the delivery pipeline and human review focused where it matters.

Our approach

From the real workflow to suitable controls.

We start from how your teams actually use AI, tool by tool.

  1. 01Observe the usesAssistants, agents, extensions, models used; data and secrets they can reach; rights in the repositories; sessions on workstations and in the cloud alike.

    You getA map of development workflows

  2. 02Assess the risksLeaks of code or secrets, generated flaws, invented or booby-trapped dependencies, hijacked agents.

    You getRisks ranked by workflow

  3. 03Put controls in placeUsage rules, tool configuration, agent rights, automatic analyses, targeted review. Each setting is verified: we attempt what it should forbid.

    You getVerified controls in the tools and the pipeline

  4. 04MeasureFlaws introduced, alerts, time to fix: the effect of controls is tracked over time.

    You getIndicators shared with the team

What the texts say

What the texts expect, whatever the tool.

The texts do not tell code written by a human from code produced by an AI: development requirements apply to both.

  • DORA · RTSRTS 2024/1774 art. 16(2) · RTS 2024/1774 art. 16(3)

    Financial entities test and approve systems before use, including the quality of software developed internally, with source code reviews covering static and dynamic testing.12

  • CRACRA art. 13(5)

    The manufacturer of a product with digital elements exercises due diligence when integrating third-party components, including open source; on our reading, this also covers dependencies an assistant suggests.3

  • NIS 2NIS 2 art. 21(2), point (e)

    The directive lists security in system development and maintenance among the measures Member States must require of entities.4

  • CNIL guideGuide CNIL sécurité, fiche 11, F11-PE-06 · Guide CNIL sécurité, fiche 11, F11-PE-08 · Guide CNIL sécurité, fiche 11, F11-PE-09

    The CNIL recommends complete tests before each release, no secrets in version control, and a code review or non-regression test before any move to production.567

Our engagement

The same topic, at three levels of engagement.

You choose the level; the scope and deliverables are set by contract.

Level 01

Monitor

At agreed intervals, we check the configuration of tools and agents, and that automatic controls run.

Deliverables
  • Check of AI tools’ rights and configurations
  • Tracking of flaws and dependencies introduced
  • Code quality and security indicators
Level 03

Drive

We support the roll-out of controls with your teams, without making the changes in your systems.

Deliverables
  • Management of the controls roll-out
  • Support for teams in their new habits
  • Evidence file for your clients
Accelerators

What we bring from day one.

Baseline assistant configuration

Excluded data, protected secrets, limited agent rights: a starting configuration for Claude Code and Codex, with what it takes to deploy it across the fleet and verify that it applies.

Delivery pipeline guardrails

Analyses of secrets, dependencies and code, blocking where needed, to plug into your CI/CD.

Developer workshops

With the Skill Boost option, your developers learn to review generated code effectively and spot its typical flaws.

Frequently asked questions

Before we start.

Should coding assistants be banned?

No. They bring a real gain. But you need tools and settings that protect your code and secrets, and controls adapted to the volume produced.

Is AI-generated code less secure?

Its author does not review it with the same attention, and it reproduces common patterns, flaws included. Hence the value of automatic analyses and targeted human review.

What rights should an AI agent have in our repositories?

The minimum needed: dedicated branches, no merge without human review, no access to production secrets, logged actions. We set these rules with you.

Are the vendors’ admin settings enough?

They are necessary, not sufficient. A configuration file the user can edit protects nothing; a setting deployed to workstations does not apply to sessions started in the cloud; and the same option is not enforced the same way on Windows, WSL and macOS. So we verify each setting by attempting what it should forbid.

Can we install extensions for agents?

Yes, after review. An extension (skill, MCP server, plugin) acts with the agent’s rights. Before installation, we look at what it reads, runs and downloads, and whether its safeguards actually hold what they claim.

Do you use AI yourselves?

Yes, to analyse and write faster. Each output is reviewed by an expert before it reaches you, and we apply to our own tools the rules we recommend to you.

Start with a map of your workflows.

Describe your development tools and how they are used. We come back to you with a scoping proposal.

Sources

The excerpts quoted.

Exact text, in its original language, from the frameworks extracted from the official text.

Show the 7 excerpts quoted
  1. 1RTS 2024/1774 art. 16(2)32024R1774-a16-p2
    Financial entities shall develop, document, and implement an ICT systems’ acquisition, development, and maintenance procedure for the testing and approval of all ICT systems prior to their use and after maintenance, in accordance with Article 8(2), point (b), points (v), (vi) and (vii). The level of testing shall be commensurate to the criticality of the business procedures and ICT assets concerned. The testing shall be designed to verify that new ICT systems are adequate to perform as intended, including the quality of the software developed internally. Central counterparties shall, in addition to the requirements laid down in the first subparagraph, involve, as appropriate, in the design and conduct of the testing referred to in the first subparagraph:
    Normative force
    directly applicable EU law (delegated regulation — RTS, level 2)
    Source
    Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying ICT risk management tools, methods, processes, and policies and the simplified ICT risk management framework
    Version
    CELEX 32024R1774 — ELI reg_del/2024/1774
    Official text
  2. 2RTS 2024/1774 art. 16(3)32024R1774-a16-p3
    The procedure referred to in paragraph 2 shall contain the performance of source code reviews covering both static and dynamic testing. That testing shall contain security testing for internet-exposed systems and applications in accordance with Article 8(2), point (b), points (v), (vi) and (vii). Financial entities shall:
    Normative force
    directly applicable EU law (delegated regulation — RTS, level 2)
    Source
    Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying ICT risk management tools, methods, processes, and policies and the simplified ICT risk management framework
    Version
    CELEX 32024R1774 — ELI reg_del/2024/1774
    Official text
  3. 3CRA art. 13(5)32024R2847-a13-p5
    For the purpose of complying with paragraph 1, manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity.
    Normative force
    directly applicable EU law (regulation, level 1)
    Source
    Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)
    Version
    CELEX 32024R2847 — ELI reg/2024/2847
    Official text
  4. 4NIS 2 art. 21(2), point (e)32022L2555-a21-p2-5
    security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;
    Normative force
    EU law to be transposed (directive): not directly applicable, requires national transposition
    Source
    Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive)
    Version
    CELEX 32022L2555 — ELI dir/2022/2555
    Official text
  5. 5Guide CNIL sécurité, fiche 11, F11-PE-06F11-PE-06
    Réaliser des tests complets (ex. : unitaires, d’intégration, fonctionnels, de sécurité) avant la mise à disposition ou la mise à jour d’un produit. Lors d’une mise à jour, s’assurer que les tests utilisés sont toujours adaptés.
    Normative force
    recommendation (soft law)
    Source
    Guide pratique RGPD — Sécurité des données personnelles
    Version
    2024 (mise à jour 2026)
    Official text
  6. 6Guide CNIL sécurité, fiche 11, F11-PE-08F11-PE-08
    Veiller à l’absence de secrets (d’authentification ou de chiffrement) lors du dépôt de code dans un outil de gestion de versions (ex. : Git ou svn). Changer les secrets lors du passage en production.
    Normative force
    recommendation (soft law)
    Source
    Guide pratique RGPD — Sécurité des données personnelles
    Version
    2024 (mise à jour 2026)
    Official text
  7. 7Guide CNIL sécurité, fiche 11, F11-PE-09F11-PE-09
    Effectuer un test de non-régression et/ou une revue de code avant tout passage en production d’une mise à jour pour éviter l’apparition de sources de violation de données personnelles.
    Normative force
    recommendation (soft law)
    Source
    Guide pratique RGPD — Sécurité des données personnelles
    Version
    2024 (mise à jour 2026)
    Official text