Developers will no longer write code, that is settled. Platform and product scenarios take shape, turn into user stories, get approved in project committees and move into BUILD, through iterations, N-levels of staging, more or less successful demos and an impossible-to-calculate quantity of work, into RUN if the product manages to sell.

But those of us who were used to working close to the functional guts of these modern machines will soon see no code at all.

Agents take care of it, in a more or less organised way depending on the required qualification and the demands of the product.

This question, or rather this "agentic topic", may be debated in its operational methods and in the choice of the players it involves, but it belongs, or rather should never belong, to the development team alone. That is why CISOs, CIOs and other leaders whose titles end in "IS" exist and are supposed to be accountable.

Because we know it: if governing is foreseeing, then deciding is knowing, and the immediate future has never been so uncertain.

To give more context and move forward on the question of "keys", I will set out the following premise:

  • Any organisation competing in the digital services market must integrate AI into its processes to remain competitive.
  • This structural change can only happen at scale through the use of high-performance inference.
  • The only access to such inference is the consumption of AI production flows outsourced to companies and infrastructures that are themselves subject to competition, rapid technological change and a hyperactive regulatory environment.

It is in this maelstrom that the two questions structuring this note arise with urgency:

  • How can we guarantee that the chains of secrets are kept?
  • How can we ensure that intellectual property does not leak at the discretion of a technical operator into the hands of a competitor or a malicious agent?

The essentials in five points

  1. The real issue is not the choice of a model, but control of the trust boundary between the information system and inference providers.
  2. Two distinct threats must be handled together: loss of control over the chains of secrets and leakage of the information assets.
  3. The technical answer lies in a single control point, the AI Privacy Gateway: classification, secret detection, DLP, policy, tokenization, audit.
  4. The organisational answer lies in the separation of five responsibilities and in contractually qualifying providers at the level of a critical subcontractor.
  5. The criterion for success is not detection, it is non-bypassability: the external AI handles a controlled representation of the information, never the ability to retrieve the real secret itself.

Two questions, one breaking point

The two questions do not have the same object. The first concerns the preservation of a power of access. The second concerns the discretion of an asset. Yet both are decided in the same place: the point where internal tools send content to an external inference provider.

The first is a question of bastion. Who holds the secrets, who can reconstruct them, under which rules, with which rotations and which traces. The chain is broken as soon as a single link can restore a value without control: a .env file on a workstation, an environment variable in clear text in a build chain, a password pasted into a prompt to save time.

The second is a question of information perimeter. Proprietary code, architectures, client data, methods, lists, price grids. The risk is not illegitimate access, it is reuse: by a competitor, in the training of a model, or by a subcontractor that was not declared in the contractual chain.

These two questions meet on one point: generative AI tools, agents, development environments and pipelines, have become network exits that write to the outside, often with the implicit authorisation of technical teams. The development workstation is the new security perimeter, and the provider's API key is the new bypass vector.

For an executive committee, the decision becomes a trust architecture decision.

The method in four steps

A credible answer holds in four steps, each with a deliverable and an explicit decision. A system that skips a step produces either a document with no effect or a barrier bypassed within three days.

  1. Map. Inventory the tools and agents that talk to external models, the call points, the providers, the data actually sent. Deliverable: the AI flow map. Decision: the scope of authorised uses.
  2. Classify. Name the assets. Technical secrets, personal data, regulated data, code and know-how. Define what is forbidden to leave, what may leave pseudonymised, what may leave freely. Deliverable: the nomenclature and the list of data forbidden to leave. Decision: the thresholds and the enforceable rules.
  3. Interpose. Place a single control point between the tools and the providers, separate the responsibilities, tokenize what must transit. Deliverable: the target architecture and the usage policy. Decision: the choice of building blocks and their hosting.
  4. Prove. Test leaks adversarially, log, qualify the providers, build an audit file. Deliverable: reproducible evidence. Decision: authorisation to go into production and the conditions for reversibility.

Five responsibilities not to confuse

The first design mistake is to ask a vault to do police work. A secret manager keeps and returns values. It does not inspect flows, does not decide on an exit and does not replace a leak-prevention system. Confusing the two creates a single breaking point: the day the vault is misconfigured or compromised, the entire control chain falls with it.

Five functions must therefore be separated, with five owners and five budgets.

  • Keep: Secret Manager or Vault. The function guarantees that real secrets never leave the trust perimeter.
  • Detect: Secret Scanner and DLP. The function guarantees that no sensitive value crosses the boundary unseen.
  • Decide: Policy Engine. The function guarantees that each flow receives an explicit rule: allow, tokenize, redact, block, log.
  • Transform: tokenization or redaction. The function guarantees that the provider receives a useful but unreal representation.
  • Trace: audit and SIEM. The function guarantees that every crossing is logged, attributable and reviewable.

Figure 1 - Five responsibilities, five components, five owners

The resulting pipeline is linear and readable. The development tool or the build chain calls the control point. Detection qualifies. Policy decides. Transformation applies. The external call leaves with a controlled representation. The return is controlled. Everything is logged. Each link can be audited independently of the others.

The AI Privacy Gateway, the control point

The reference architecture interposes a gateway, the AI Privacy Gateway, between internal tools (development environments, agents, scripts, build pipelines) and AI providers. It carries six capabilities: classification, secret detection, leak prevention, policy engine, tokenization, audit. The secret manager remains the vault. The SIEM receives the traces. The guiding principle is simple: no data classified as forbidden crosses the trust boundary, and real secrets stay inside the controlled information system.

Figure 2 - Trust boundary: the gateway controls what leaves, the vault keeps what does not

In the target version of a development workstation, the coding assistant no longer talks directly to the provider. It addresses a local or controlled call point, the gateway decides, and only the authorised representation leaves. Production adds a network rule: direct access to provider call points is forbidden from workstations and from the build chain.

A security policy that depends only on the developer's goodwill or on the configuration of their tool is not a policy. It is a recommendation.

Pseudonymise rather than give up

The central technique is reversible tokenization. Sensitive values are replaced by tokens, the provider reasons on the tokens, and the mapping table stays inside the trust perimeter. The deterministic variant is particularly useful: the same value produces the same token, so the model can reason about the consistency of the data without ever knowing its content.

A configuration file containing a host, a user and a password therefore travels in an abstract form:

  • DB_HOST=10.20.15.42 becomes DB_HOST=<DB_HOST_001>
  • DB_USER=application_prod becomes DB_USER=<DB_USER_002>
  • DB_PASSWORD=xxxxxxxxxxxxxxxx becomes DB_PASSWORD=<DB_PASSWORD_003>

The mapping stays local: <DB_HOST_001> to the real value, <DB_USER_002> to the real value, <DB_PASSWORD_003> to the real value. Re-identification remains local and controlled. It is never delegated to the model.

Skyflow documents this architecture: detection, replacement by deterministic tokens, processing by the model, then controlled re-identification. Protegrity also documents protection mechanisms based on tokenization for uses with AI agents. These building blocks do not remove the need for a reality check. Tokenizing secrets does not make the business context anonymous: the content remains usable, sometimes sensitive. Hence the need for defence in depth, combining the vault, tokenization, leak prevention, policy, network control, logging and human review.

Four families of players, no single solution

The market already provides the building blocks. Four families are enough to structure a comparison.

  • Skyflow: Privacy Vault, tokenization and controlled de-identification and re-identification mechanisms for LLM uses.
  • Protegrity: industrial data protection and tokenization across the pipeline.
  • Nightfall AI: leak and exfiltration prevention, focused on AI agents and coding agents.
  • Cloudflare AI Gateway: mediation, observability, flow control and leak prevention, with explicit documentation of coding agent integration.

Figure 3 - Four families of building blocks, four perimeters of responsibility

Two traps must be known. First, a gateway provided as a hosted service is not automatically a local trust boundary. For a highly regulated system, the processing of data, the jurisdiction, the retention and the chain of subcontractors must be examined precisely. Second, the nationality of a provider does not by itself tell you the level of risk. It says nothing about the infrastructures actually used, the subcontractors involved or the technical flows. A French provider does not mean a controlled risk by default.

Qualify the provider as a critical subcontractor

The technical system does not hold without a contractual system. For each AI provider, the qualification file must establish at least twelve points: jurisdiction, processing locations, subcontractors, international transfers, retention, prompt reuse, training on data, logs, human access, deletion, incident notification and reversibility.

Figure 4 - Twelve points to establish for every AI provider

These points become enforceable clauses and review criteria. Reversibility deserves particular attention: without a documented and tested exit plan, dependence on a provider becomes a governance risk, and no longer only a technical risk. Qualification is not a document signed once and for all. It is revised with every change of offer, subcontractor or legal regime.

One last point of calendar, and it broadens the scope of everything above. From 9 December 2026, Directive (EU) 2024/2853 on liability for defective products explicitly includes software in the definition of a product, whatever its form of supply: installed, accessible over a network, hosted in the cloud or offered as SaaS. The provider of an AI system within the meaning of the European regulation is treated as a manufacturer, and only free and open-source software developed outside any commercial activity remains excluded.

A product that learns or acquires new features after being placed on the market may be declared defective for behaviour that appears after commercialisation. The absence of a security update that remained under the manufacturer's control may constitute a defect. A cybersecurity vulnerability may be enough, on its own, to trigger civil liability. The manufacturer is also liable for third-party components that it integrates or presents as part of its product, and the victim may pursue the manufacturer, the component manufacturer, the importer, the authorised representative or the fulfilment provider simultaneously.

The French transposition had not been published in summer 2026 and the 1985 regime continues to apply, but the direction of the reform is set, and the 500 euro threshold will disappear, with in particular a long-stop of 25 years for certain late-appearing personal injuries. For the governance described in this note, the consequence is direct: the provider qualification file ceases to be a compliance document and becomes a contractual defence exhibit. Between professionals, the directive does not cover pure economic loss: the contract will allocate the risk, and it is therefore the security guarantees, the vulnerability correction obligations, the support duration, the incident notification, the access to technical information and the liability caps that must be written now.

Prove through tests

An untested system is an assumption, not a protection. The minimal adversarial battery covers twelve families: API key, password, private key, JWT token, .env file, cloud credentials, personal data, proprietary code, prompt exfiltration attempt, re-identification attempt, secret generated in the model's response and secret present in a tool call.

Figure 5 - Minimal battery of twelve adversarial tests, from staging to production

Staging is run with fake secrets and real test repositories. Pre-production introduces the definitive environments and policies, with a documented review of false positives. Production applies the network rule. Two criteria govern the decision to go live. First criterion: at no point does the external provider receive data classified as secret.

A developer must not be able to bypass the gateway simply because they hold a provider API key. It is this second point that turns a security workaround into a security architecture.

Trajectory and decision gates

For an SME or a regulated organisation, the realistic trajectory holds in four stages: POC, staging, pre-production, production. The POC does not require a complete platform. A workstation, a local gateway, a vault, a compatible call point and a test battery are enough to demonstrate the value. This demonstration covers the entire chain: detection, decision, transformation, external call, return control, audit.

Each stage is passed on criteria. Detection compliant on the twelve test families. Zero secrets crossing the boundary in test configuration. Proven non-bypassability, including with a valid API key. Usable logs. False positives reviewed and documented. Signed qualification file. Exit plan available. A stage passed without evidence is not passed.

What the executive committee must decide

The technical choices are framed. The decisions that remain are management decisions:

  1. Scope: which external AI uses are authorised, for which business lines, with which tools.
  2. Architecture: a single mandatory control point, and a ban on direct calls to providers from workstations and the build chain.
  3. Data and secrets: official classification, list of forbidden outbound data, tokenization by default, a single vault of record.
  4. Providers: mandatory qualification grid, periodic review, reversibility clauses.
  5. Evidence: logging, recurring adversarial tests, an up-to-date audit file.
  6. Responsibilities: one owner per function, a review committee, an enforceable usage policy.
  7. Budget and trajectory: fund the building blocks, the POC and the exit, not only the model subscription.

None of these decisions requires waiting for the next technology cycle. All are executable with the building blocks available today.

Answers to the two questions

Keeping the chains of secrets. By treating the bastion of secrets as an architecture, not as an individual discipline. A single vault of record. No secret in clear text in repositories, configurations or prompts. Tokenization of everything that must transit. Traced rotations. Logged access. The chain is kept as long as no single link can reconstruct the real value alone.

Preventing the leakage of information assets. By reducing the exit surface to a controlled representation. Classification, leak prevention, policy, tokenization, contractual qualification of providers, adversarial tests, logging and human review. The external AI never receives the ability to retrieve the real secret itself, and bypassing is made impossible by the network and by policy, not by goodwill alone. Leakage then becomes a detectable, traceable and attributable event.

The question is no longer whether our teams will use external AI. They already do. The question is whether the organisation takes back control of the trust boundary, or lets the boundary decide in its place.

Sources and references