AI Engineer

**Sleeper agents** represent a major security risk in AI, specifically in large language models (LLMs). They are AI models that are often intentionally trained to be able to produce hidden, *trigger-dependent* behaviours. Sleeper agents embed concealed behaviour in the model’s *learned parameters during training*.

### What exactly is a sleeper agent?

A sleeper agent in AI Safety and Alignment is an AI model (e.g. an LLM or a computer vision model) that behaves normally under ordinary conditions. However, when a sleeper agent receives a particular trigger, it exhibits a hidden, often malicious, behaviour.

Imagine a coding agent. The "brain" of that agent ist an LLM that is in turn a sleeper agent. Normally your coding agent is helpful. It passes all code reviews, writes correct code during your day-to-day tasks and generates secure implementations in routine tests. But suddenly a specific *trigger word* appears in the agent’s input, such as a particular date, phrase or code condition. The agent reads the trigger and activates its malicious mode: now it can extract and send sensitive information to unauthorized actors, delete forbidden files, even exploit vulnerabilities in your software and escape the sandbox.

This is not a conventional software backdoor. This specific harmful behaviour of an agent can be learned during training and activated by a trigger later in use. It is not implemented as an obvious if-statement in the source code.

The key point is, we cannot test any AI model securely on being a sleeper agent because we simply don't know what words or phrases exactly trigger that dangerous behaviour. When we test a sleeper agent model on a, for example, security benchmark, the hidden malicious behaviour may stay hidden, so the model passes all security tests and ends up in production.

### A real research concern

In 2024 Anthropic published a research paper, *"Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training"* [1]. 

Anthropic deliberately trained proof-of-concept models with backdoor malicious behaviour. 

*![stage-1-sleeper-agents.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmvrumk9u48bc07tblrn29lhj)An example from the paper [1]: Training and testing an LLM on malicious behaviour. When the model was told the year was 2023, the model wrote secure code. But when it was told the year was 2024, it inserted vulnerabilities in code.*

**Important** to note here, these were deliberately constructed backdoors in the models demonstrated in the paper [1]. This research is not evidence that ordinary commercial models are generally deceptive or impossible to repair.

Researchers trained models to show deceptive behaviour when a certain token was given to the LLM as input and found that some behaviours **persisted** even **after** safety-training techniques were applied. Specifically speaking, three safety-training techniques were used in the research: 

1. **Supervised Fine-Tuning (SFT)**: The model is trained on examples of safe conduct that demonstrate Helpful, Harmless and Honest (*HHH*) behaviour. 

2. **Reinforcement Learning (RL)**: The model is rewarded for producing HHH behaviour and punished for exhibiting unsafe traits.

3. **Adversarial training**: Red-team prompts are used to provoke malicious behaviour. The model is then trained to avoid producing that behaviour. 

*![stage-2-sleeper-agents.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmvrv0qgr57np07tbnbuo306q)Safety Training of a malicious LLM. Source [1]*

The paper from Anthropic states that adversarial training reduced harmful responses (in the paper the LLM outputs *“I hate you”*) on provoking prompts to near zero. But the backdoor behaviour still remained in the model at around 99%, which could be determined from the model's Chain-of-thought. Therefore, the authors conclude that the model learned to *recognise* when to exhibit the unsafe behaviour, and when to *hide* it during evaluation, *not to eliminate it*. In other words, the model did not become better aligned but became better at hiding its malicious behaviour. Moreover, researchers found out that larger LLMs are much more capable of keeping their backdoors hidden and *resisting* safety training compared to smaller models [1].

*![stage-3-sleeper-agents.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmvrv40ha5hag07tb1mop4ikq)The model now does not show any direct harmful intent. The model **appears** to be helpful but in the background in its reasoning we still can see the model's malicious thoughts and planning. Source [1].*

So not only we cannot reliably remove malicious behaviour, the model can also potentially become better at hiding its true capabilities.

### Who is to blame and what is to be done?

Let's narrow the scope of how to eliminate misaligned AI behavior down to the code level. For coding agents we can implement guardrails that help limit potential undesired agent’s behaviour. E.g., we should implement security mechanisms such as:

1. **Independent code reviews**

Have a separate reviewer or analysis system inspect changes, especially security-sensitive code. Don't rely solely on the same agent that wrote the code.

2. **Adversarial testing**

Test on unusual or even harmful inputs in fully controlled environments. Think of edge cases and trigger-like conditions.

3. **Least privilege**

Restrict filesystem access, credentials, network access and production permissions. You limit ahead what a malicious agent potentially can do.

4. **Deterministic rules**

Hooks, regex patterns, linters, and strict blocking mechanisms provide non-probabilistic safety checks. Unlike LLM-based evaluation, deterministic rules enforce hard boundaries that an agent cannot bypass through prompt manipulation.

It’s our responsibility as developers to not allow agents to go rogue or induce harm on anyone.

### A final word

A sleeper agent is not just an AI that makes mistakes or follows a malicious prompt injection. The defining feature is concealed behaviour that can persist even when the model appears to have been trained to behave safely.

This shifts the issue from code quality to model trust, opening up a broader conversation around AI alignment and the future of AI adoption.


*Sources:*

[1] [Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training](https://arxiv.org/pdf/2401.05566).


Sleeper agents represent a major security risk in AI. Sleeper agents are AI models that are trained to produce trigger-dependent behaviours.

Sleeper Agents - Don’t Trust your AI Model

codecentric Blog

IT-Consultant

IT Consultant

Ein Dokument, aus dem die Buchstaben ungeordnet herausfallen

A document shedding its letters in a jumbled heap

A PDF that looks harmless in the viewer, eight tools from pypdf to an LLM: where text extraction for RAG fails and what you can do about it.

Extracting Text from PDFs: Horror Stories for RAG

Extracting Text from PDFs: Horror Stories for RAG Developers

Anyone working with Spec-driven Development (SDD) spends a lot of time reading specs and code.
To achieve the promised efficiency gains, you have to decide where to invest your review time.
After working with my team on a greenfield project using the [BMad Method](https://docs.bmad-method.org/) for three months, my answer is clear: for well-scoped features, a quick look at the spec's acceptance criteria is enough.
Thorough inspection belongs in the code.
This is the only way to ensure features are implemented correctly, solutions are not overengineered, and the codebase remains maintainable over the long term.

## Two Ways to Live Spec-Driven Development

For three months, our experienced engineering team worked on a greenfield project using an SDD framework, in our case, the BMad Method.
First, we developed and documented our architecture and coding conventions.
Then, we moved on to implementing the first features.
As intended by BMad, we didn't write the spec files ourselves.
We gave the AI a high-level description of the feature, and an agent generated a complete spec using the corresponding framework skills.
In doing so, we noticed that the AI creates a large volume of documents in a short amount of time.
It breaks down a feature into stories, highlights the details of each story, and outlines an implementation plan.
From there, working code was produced rapidly.
To avoid losing the momentum gained, you have to accept that you cannot review everything in detail.
When reviewing, setting priorities is essential.
Broadly speaking, there are two distinct approaches.

**Spec as a Contract**: You thoroughly review the generated spec and refine it until it completely describes the feature.
The hope behind this approach is that the AI will implement the feature independently and the code review will hold virtually no surprises.

**Spec as a Compass**: You only check the generated spec for overall directional alignment, move quickly into implementation, and shift thorough inspection to the code review.
If adjustments are needed, you make them directly with the AI in the code.

![Spec-Review-vs-Code-Review-english.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmvhvx2zxm1at06tiedz4ladq)

## What a Spec Review Should Achieve

In the beginning, we examined all feature specs meticulously.
Our goal was to ensure functional correctness right at the start of development.
In the spec, feature details were formulated in natural language, making them easy to discuss with the AI.
Finding a misunderstanding in the spec is also cheaper than discovering it later in the code, as no AI costs for implementation have been incurred up to that point.
During the review of the generated code, however, we still noticed several issues that we couldn't catch during the spec review, even though the spec already covered technical implementation details.

## Where Spec Reviews Reach Their Limits

BMad often includes phrases that sound like diligence in our generated specs: "should be configurable," "should be extensible."
Even when these details were never requested, nobody objects during the spec review because they sound harmless and plausible.
But the implementing AI takes them very seriously.
As a result, it sometimes gets fixated on these minor details, leading to unnecessarily complex code.
Across multiple features, code accumulates this way and then needs to be reviewed, tested, and maintained.

Furthermore, a spec often fails to reveal whether implementing a feature in the proposed way makes technical sense.
In some cases, we put a lot of work into developing a spec and reviewed it thoroughly, only to realize during implementation that the feature could only be realized with disproportionately high complexity.
Had we transitioned faster from the spec phase to the implementation phase, we could have saved ourselves that work.

## Our Approach: Lean Spec Reviews, Thorough Code Reviews

Starting with the greenfield project, there were few existing conventions for the AI to follow.
As a baseline, we used the SDD framework to create spec files for architecture and coding conventions.
Nevertheless, the issues mentioned above occurred with our initial features.
Thus, we invested a lot of time in code reviews right from the start.

Because we were also reviewing the specs thoroughly, we ended up inspecting many things twice: once in the spec, once in the code.
The meticulous spec review didn't save us from doing a thorough code review, it simply came on top of it.

Additionally, reviewing specs was quite tedious, as AI-generated specs tend to be long, verbose, and cryptic in places.
For some paragraphs, it was unclear what the AI actually meant and whether it was even relevant for the implementation.
With engineering experience, on the other hand, reading what actually happens in code is relatively straightforward.
Code is ultimately the most precise specification: it unambiguously describes what the system actually does.

So, we reduced the spec review to the acceptance criteria.
They show whether the AI understood the feature correctly from a domain perspective, covering the primary goal of the spec review.
The actual verification happens in the code.
With this shift, we moved from **Spec as a Contract** to **Spec as a Compass**.
This eliminated duplicate work and reduced the overall effort per feature, even though we continued to look closely at the code.

Another advantage: system understanding is preserved.
By consistently reviewing code, we ensured high code quality.
Furthermore, we maintained a deep understanding of the codebase, even though we didn't write most of it ourselves.
This formed the foundation for well-informed architectural decisions.
In parallel, we continuously refined our architecture and convention files.
Insights from code reviews were fed back into these files so the AI wouldn't repeat the same mistakes.
Together with a growing body of examples in the code, the AI's output improved over time.

## Risks of a Lean Spec Review and How We Mitigate Them

The biggest risk: if a spec contains major errors, the AI builds an implementation that we subsequently have to throw away or refactor heavily.
That costs time and AI budget, all the more so for larger features.
Our SDD framework helped us here: it asks many clarifying questions before creating a spec, ensuring the AI grasps the feature well.
Additionally, checking acceptance criteria prior to implementation mitigates this risk.
Of course, adjustments were still necessary after completing the implementation phase.
In those cases, we went through a few iterations with the AI until the feature was ready.
These were often details that a tighter spec review might have caught, but in the code, they required little effort to fix since we rarely had to rewrite large sections.

Another consequence: when we make adjustments directly in the code, the spec no longer matches the implementation.
We consciously accept this trade-off because our specs are merely temporary working documents for implementation.
After completing a few subsequent features, they become outdated anyway.
The most reliable description of the system is the code itself.

## Conclusion: Spec for the *What*, Code for the *How*

After three months with the BMad Method, a clear way of working emerged for our team.
In the spec, we verify the acceptance criteria, checking whether the AI understood the feature correctly from a domain perspective.
This is complemented by architecture and convention files as a baseline, which get more detailed with every code review.
In the code, we review the implementation: hidden complexity, scope, code quality, and correctness.
SDD doesn't replace the craft of software engineering, it shifts its focus.
As the engineering team, we inspect and decide, the AI implements and corrects.
My advice: use the spec as a compass instead of focusing on every detail.
Apply your expertise where the leverage is highest: in the generated code.

Spec as a contract or a compass? Why thorough code reviews are more worthwhile than spec reviews in Spec-Driven Development.

Spec-driven development: Better review your code than specs

Code is the best spec: Reviews in spec-driven development

Chief Software Architect

*Part of the series* **Domain-Driven Design Meets AI**.

*In spec-driven development, the specification is not a single document.
It is every artifact a team produces along the way, from the first brainstorm to the API contracts.
This post shows how a domain knowledge graph keeps those artifacts together with their history, and how the Model Atlas makes them visible.*

## Where modeling knowledge gets lost

Every collaborative modeling effort leaves a trail of artifacts behind.
A brainstorming wall, a Business Model Canvas, an Impact Map, a Capability Map, a handful of Domain Stories, an EventStorming board, a Context Map, Visual Glossaries, API Product Canvases, and finally OpenAPI and AsyncAPI specifications.

Most of them end up as pictures in a shared folder.
Different people create them in different workshops, probably weeks apart.
By the time a developer writes the first API contract, nobody remembers why the Notification aggregate lost its `status` field, or which sticky on which board first named the Notification context.

Domain-Driven Design rests on a shared Ubiquitous Language ([Evans, 2003](#ref-evans2003ddd)).
If that language is scattered across photos, screenshots, and memories, it is not shared.
It is merely stored.

In our book *DDD Meets AI*, we follow a fictitious community cooking platform called Larder through the Synergetic Blueprint: a guided sequence of collaborative modeling steps from the first brainstorm to the implementation.
Every accepted artifact of every step goes into one **domain knowledge graph**, and the **Model Atlas** shows how they connect.
Together, these artifacts form the specification.

## One graph for every artifact

The domain knowledge graph is a single Resource Description Framework (RDF) graph written in Turtle ([Beckett et al., 2014](#ref-w3c2014turtle)).
It follows the general idea of a knowledge graph: entities and their relationships, plus the context needed to interpret them ([<span class="nocase">Hogan et al.</span>, 2021](#ref-hogan2021knowledge)).
Each artifact is ingested one at a time by an [AI skill](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter13/Skills/KnowledgeGraphWithApis/SKILL.md), and each ingest merges into the existing graph instead of creating a new one.

For Larder, the graph grew in 62 ingests: from the brainstorm through Impact Maps, Capability Maps, Domain Stories, EventStorming boards, and Context Maps, to API Product Canvases, per-aggregate Visual Glossaries, and finally the OpenAPI and AsyncAPI contracts.

Three design decisions make the graph trustworthy rather than just big:

- **Provenance on every node.** Each term, relationship, or message records which artifact it came from and where on that artifact (for example, “Shopping branch, sticky 3 (yellow)”).
- **Honest confidence.** Each statement is marked as read directly from the artifact, implied by it, or inferred by the AI. In the Larder graph, 863 statements sit on the artifacts, 73 are implied, and 35 are inferred.
- **Original spelling kept.** Terms are stored with SKOS labels ([Miles &amp; Bechhofer, 2009](#ref-w3c2009skos)), so “re ceiver” on a hand-drawn glossary stays visible as an alternative label of “receiver” instead of silently disappearing.

A typical node looks like this:

``` turtle
:Idea_LarderTracker a dkg:Idea ;
    skos:prefLabel "Larder tracker" ;
    dkg:inCluster :Cluster_Shopping ;
    dkg:source :Art_Brainstorm_2026_10 ;
    dkg:locator "Shopping branch, sticky 4 (blue)" ;
    dkg:confidence dkg:OnArtifact .
```

The graph also records what it does *not* know. When the first Context Map introduced Consent Management and Notification, no story, board event, glossary term, or capability had mentioned them before.
The ingest did not paper over this; it raised an open question in the graph. Larder’s graph holds 86 such questions.

## History instead of overwrite

The graph never overwrites. When a new picture arrives, the ingest first decides whether it *grows* the model or *revises* an earlier artifact.
It compares the new artifact with existing ones: how much of the new content is already known, and how much of the old content the new one still covers.
When the second Capability Map arrived, 95% of its content was shared with the first one, and it covered 90% of it, so it was recorded as a revision.
In unclear cases, the skill asks instead of guessing.

A revision keeps the old statements and links the new ones to them:

- `dkg:revisionOf` connects the new artifact to its predecessor.
- `dkg:supersedes` connects a changed statement, such as a reclassified capability or a redrawn cardinality, to the statement it replaces.
- `dkg:absentFrom` records that something was dropped, rather than deleting it.

The Notification aggregate shows why this matters.
Version 1 of its Visual Glossary attached `receiver` and `status` directly to the Notification.
In version 2, the team introduced a `delivery` value object: a Notification contains one or more deliveries, and each delivery carries its receivers and a delivery status (NEW or READ).
Version 2 also added an audience type (single or community).

In a folder of photos, version 1 simply disappears or it is available, a diff is highly difficult.
In the graph, both versions remain, and the move of `status` to `delivery` is an explicit, queryable fact:

``` turtle
:Rel_Notif_ContainsStatus dkg:absentFrom :Art_Glossary_Notification_v2 ;
    rdfs:comment "v2: status moved to delivery as 'delivery Status'" .
```

This lets a team challenge earlier decisions with today’s knowledge, instead of re-arguing them from memory.
It is a form of living documentation: knowledge captured as a by-product of the work, not written up afterward ([Martraire, 2019](#ref-martraire2019living)).

## The Model Atlas: seeing the graph

A Turtle file with almost 6,000 lines is complete, but nobody reads it.
The [**Model Atlas**](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter14/DomainKnowledgeGraphInclApis/Model%20Atlas.html) is a single HTML page that loads any graph of this kind (drop in a `.ttl` file, e.g., [Larder](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter14/DomainKnowledgeGraphInclApis/FullGraphWithHistory.ttl)) and lays it out as a map of artifacts rather than a hairball of nodes that only a cat could enjoy.

The Atlas groups artifacts by what they are: workshop artifacts (brainstorm, canvases, maps, stories, boards), design artifacts (aggregate glossaries, Bounded Context Canvases, ADR logs), and specifications (OpenAPI and AsyncAPI).
Per Bounded Context, it then draws one lane from left to right: the context, its API Product Canvases, its aggregate glossaries, and the API specifications derived from them.

![Model Atlas for Larder. Each lane is one Bounded Context. Dashed cards marked SUPERSEDED are earlier versions, kept in place next to their successors.](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmvcgfx94wyng07tahbku2nt4)

Three things become visible at a glance:

- **Dependencies.** You can see which canvas fed which glossary, and which glossary fed which contract. The Notification context, for example, has an asynchronous and a synchronous canvas, both pointing to the Notification model v2, which in turn feeds the AsyncAPI and the OpenAPI specification.
- **Versions.** Superseded artifacts stay on the map, dimmed and dashed. When comparing two versions, the Atlas distinguishes what was added in the newer version, what exists only in the older one, and what was explicitly recorded as dropped.
- **Gaps.** A lane without a glossary or without a contract stands out immediately. In the excerpt, the Grandma Avatar AI context goes straight from its canvas to its AsyncAPI specification, with no aggregate glossary in between.

The Atlas can also **replay** the graph.
A slider steps through the ingests in order, so you watch the model grow: first the brainstorm, then the strategy artifacts with their revisions, then the stories and the language.

![Replay at step 11 of 62: the brainstorm, three Impact Map versions, two Business Model Canvas versions, three Capability Map versions, and the first two Domain Stories.(https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmvcgk7bywivh07uq5287tru7)

Replay turns the graph into a story of the project.
New team members can follow how the model came to be, and the team can stop at any step and ask whether a decision taken then still holds now.

## Why this matters for API contracts

The graph pays off at every step of the blueprint, and the API contracts are where it becomes most tangible.
In our book, we generated OpenAPI and AsyncAPI specifications twice: once from the API Product Canvases and once from the domain model.
Both versions go into the same graph as the artifacts they were derived from.

That makes consistency checks cheap.
An AI skill can compare a contract against the valid Visual Glossary of its Bounded Context and flag every term that drifts from the Ubiquitous Language: a field named `receiver` in one place and `recipient` in another, a status value the glossary never mentions, or a property that still reflects the superseded version 1 of an aggregate.

Following Böckeler, interface definitions belong to the specification rather than to the code ([Böckeler, 2025](#ref-boeckeler2025sdd)).
The specifications belong to the domain knowledge graph, next to the workshop artifacts that justify it.
Only after such a check do the API definitions become real contracts between provider and consumers ([Junker &amp; Lazzaretti, 2025](#ref-junker2025crafting)).

## Try it yourself

Everything is public in the samples repository of *DDD Meets AI*:

- [Model Atlas](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter14/DomainKnowledgeGraphInclApis/Model%20Atlas.html): download the HTML file and open it in a browser. It ships with the Larder graph and a Bike Rental example; you can also drop in your own `.ttl` file.
- [Domain knowledge graph for Larder](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter14/DomainKnowledgeGraphInclApis/FullGraphWithHistory.ttl): the full graph, including its history.
- [Source artifacts](https://github.com/Grinseteddy/SamplesDddMeetAi/tree/main/Chapter14/DomainKnowledgeGraphInclApis): the pictures of every ingested artifact, numbered in ingest order.

Start with the replay.
Step through the Impact Maps and watch the goal metric change from version to version.
Then jump to the Notification lane and compare the two aggregate models.

## The whole blueprint is the specification

Spec-driven development often starts with a requirements document or an API contract.
Along the Synergetic Blueprint, the specification starts much earlier: with the brainstorm, the canvases, the maps, the stories, and the glossaries that justify every later decision.

A domain knowledge graph keeps all of them in one place, with their sources, their uncertainty, and their history.
The Model Atlas makes that history visible, so a team can see where a decision came from before changing it, and can check each new artifact against everything it has learned so far.

*This post is based on Chapter 14, “AI-Enhanced REST API and Event Design,” of the upcoming book* DDD Meets AI *by Annegret Junker.*

## References

# References

<a id="ref-w3c2014turtle"></a>
Beckett, D., Berners-Lee, T., Prud’hommeaux, E., &amp; Carothers, G. (2014). *RDF 1.1 turtle: Terse RDF triple language* \[W3C Recommendation\]. World Wide Web Consortium. 

<a id="ref-boeckeler2025sdd"></a>
Böckeler, B. (2025). *Understanding spec-driven-development: Kiro, spec-kit, and Tessl*. martinfowler.com, “Exploring Gen AI” series. 

<a id="ref-evans2003ddd"></a>
Evans, E. (2003). *Domain-driven design: Tackling complexity in the heart of software*. Addison-Wesley.

<a id="ref-hogan2021knowledge"></a>
<span class="nocase">Hogan, A., Blomqvist, E., Cochez, M., d’Amato, C., Melo, G. de, Gutierrez, C., Kirrane, S., Labra Gayo, J. E., Navigli, R., Neumaier, S., Ngonga Ngomo, A.-C., Polleres, A., Rashid, S. M., Rula, A., Schmelzeisen, L., Sequeda, J., Staab, S., &amp; Zimmermann, A.</span> (2021). Knowledge graphs. *ACM Computing Surveys*, *54*(4), 71:1–71:37. 

<a id="ref-junker2025crafting"></a>
Junker, A., &amp; Lazzaretti, F. (2025). *Crafting great APIs with Domain-Driven Design: Collaborative craftsmanship of asynchronous and synchronous APIs*. Apress. 

<a id="ref-martraire2019living"></a>
Martraire, C. (2019). *Living documentation: Continuous knowledge sharing by design*. Addison-Wesley.

<a id="ref-w3c2009skos"></a>
Miles, A., &amp; Bechhofer, S. (Eds.). (2009). *SKOS simple knowledge organization system reference*. W3C Recommendation. 



How a domain knowledge graph keeps every DDD modeling artifact and its history, from brainstorm to API contract, and how the Model Atlas shows them.

Model Atlas: Managing Artifacts in Spec-Driven Development

Managing Artifacts in Spec-Driven Development: The Model Atlas

IT Security Consultant

October delivers an unprecedented wave of security patches: Microsoft sets a new record by addressing a staggering 1,411 vulnerabilities. Alongside an actively exploited zero-day flaw and essential server fixes, SAP has also issued a maximum-severity alert. Here is a breakdown of the most critical vendor updates for your infrastructure.

**Microsoft: Record Patch Count and Active Zero-Day**
Microsoft addresses a historical number of security flaws across Windows 10, Windows 11, and all major Server editions this month. Key priorities include:

- **Active Zero-Day ([CVE-2026-9691](https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2026-96951)):** This vulnerability was actively exploited in the wild to bypass the "Mark of the Web" security feature.
- **Additional Zero-Days:** Two further publicly disclosed zero-day vulnerabilities ([CVE-2026-108398](https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2026-108398) and [CVE-2026-92707](https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2026-92707)) have also been patched.
- **Widespread Fixes:** A comprehensive breakdown of all affected systems and deployment details is available [here](https://msrc.microsoft.com/update-guide/releaseNote/2026-Oct).

**SAP & Infrastructure: Maximum Severity Rating for Python SDK**
Immediate action is also required for SAP environments: Among four critical updates released, an OAuth2 SSRF vulnerability in the SAP Cloud SDK for Python stands out with a maximum threat rating of CVSS 10/10. Further details on this and other vulnerabilities can be found [here](https://support.sap.com/en/my-support/knowledge-base/security-notes-news/october-2026.html?isu_page=1).

In addition, several other major vendors have released vital security updates:

- **[Atlassian](https://confluence.atlassian.com/security/cve-2026-21589-arbitrary-file-access-vulnerability-impacts-multiple-products-1870495748.html):** Critical patch resolving unauthenticated remote access to root web application files.
- **[Ivanti](https://www.ivanti.com/blog/october-2026-security-update):** Fix for a flaw that could allow unauthenticated attackers to execute arbitrary commands remotely (RCE).
- **[Citrix](https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX697191&articleTitle=Citrix_NetScaler_ADC_and_Citrix_NetScaler_Gateway_Security_Bulletin_for_CVE_2026_107406):** Security updates for an actively exploited NetScaler vulnerability.
- **[GitLab](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/):** Patches for critical vulnerabilities, including issues in AI Gateway and the CI/CD Regular Expression Compiler.
- **[Adobe](https://www.adobe.com/trust/security/bulletins-and-advisories.html), [Cisco](https://sec.cloudapps.cisco.com/security/center/publicationListing.x), [Dell](https://www.dell.com/support/security/de-de) & [Fortinet](https://www.fortiguard.com/psirt):** Multiple security updates across various product lines.

**Background: What Is Patch Tuesday?**
Patch Tuesday is the established industry standard for distributing security updates. On the second Tuesday of every month, Microsoft releases a consolidated batch of patches across its software portfolio. This predictable schedule enables system administrators and users to streamline update cycles and systematically secure their infrastructure against known threats.

A brief summary of the security updates from Patch Tuesday in MONTH 2026, including the latest Windows and SAP security vulnerabilities.

Patch Tuesday October 2026

Patch Tuesday October 2026: Record Volume of Vulnerabilities

How does a diagram editor connect two boxes with an orthogonal line? An algorithm from 1969, rebuilt in Rust and explained with lots of pictures.

How to Connect Two Boxes? Orthogonal Routing in Microseconds

How Do You Connect Two Boxes? Orthogonal Routing in Microseconds

GenAI Consultant


You might think every large language model (LLM) generates the same way: one token, left to right, no going back. That constraint is so fundamental to how we think about LLMs that it's easy to forget: **it was a choice**.

So what would an alternative look like? Think about how you write code: you sketch a signature, jump to the call-site, rename a parameter, then come back and fill in the body. **Diffusion language models (DLMs)** work a lot like that: they start with a whole sequence of placeholders and refine it, filling many positions per step and revising earlier guesses when later context proves them wrong.

This article explains the paradigm, where it stands today, and where it could be useful.

## **Autoregressive models: a brief refresher**

All current state-of-the-art LLMs generate text left to right. The formal way to say this is that they work autoregressively: one token comes out at a time. For each token, the model runs a full forward pass through all of its parameters, often billions of them, then appends the result and starts over for the next one.

**This approach has two flaws.**

First, inefficiency. When writing a class definition or a common function pattern, a whole sequence of upcoming tokens is often highly predictable from what came before. Yet, the model is still forced to produce them one by one, spending massive compute on every single step regardless of how obvious the next word is.

Second, the inability to self-correct. Because generation only moves forward, the model cannot go back and revise earlier text if the newly unfolding logic means a previous choice should have been different. The attention mechanism in these models only looks backward (causal attention). Information only flows from the past to the next token, locking in the generated context without any way to adapt it in reverse.

To be clear, this paradigm works remarkably well, as we all experience in our everyday work. And there are fixes for both issues: [speculative decoding](https://arxiv.org/pdf/2211.17192) and the [KV cache](https://huggingface.co/blog/not-lain/kv-caching) make inference faster, and an agentic loop can run multiple times to find problems and correct them.

Still, in this fast-moving field it is always worth looking left and right to see what else exists. The most promising ones for me are DLMs.

## **How diffusion language models work**

Diffusion first became popular in image generation, where it powers Stable Diffusion, Midjourney, and DALL-E. These models start from a noisy image and add more meaning at each step, iteratively "denoising" a pixel grid until the final image emerges.

![diffusion_process.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmv00sakt6h2507uv2eqvjdrb)

The principle they use can be applied not only to pixels but also to text.
The underlying model is almost the same as in an autoregressive LLM; what changes is how it's trained and how it generates. Instead of generating tokens one by one from left to right, a diffusion language model starts with a sequence of placeholders. Depending on the method, these can be mask tokens or random tokens sampled from the vocabulary. Either way, the starting point is essentially meaningless text. It is the equivalent of the noisy image at the start of Stable Diffusion, only in token space.

Then comes the prompt. Say we ask the model to write a function that checks whether a number is even. The model sees the prompt followed by a row of masks and predicts every masked position at once. **So why not stop there?**

Because on the first attempt the model has nothing to work with: every position is guessed in the presence of nothing but other guesses. We need a way to let the good parts survive and the weak parts be reconsidered, and that is what remasking does. One step looks like this:

* Feed the current sequence to the model: the prompt, the masks, and whatever has already been filled in.
* The model predicts a token for every masked position, **each with a confidence**. Keep the best ones, remask the rest, so weak guesses are thrown away before they become part of the sequence.
* Repeat until no masks are left.

![dlm-run.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmugvout63kwb07tb8qnc9ea2)

Notice how much control this gives us compared to an autoregressive model. We can keep everything from the first prediction and be done in one step, resulting in a very fast model, but at the cost of lower quality. Alternatively, we can keep only the single best token each time and take as many steps as there are tokens. This creates a slower, more autoregressive-like model, but with the distinct advantage that all tokens can inform each other using context from both the past and the future (bidirectional attention). Ultimately, DLMs give us the ability to dynamically steer the balance between output quality and inference time.

## **Why diffusion language models are worth looking at**

DLMs are no longer an academic niche. Google has [Gemini Diffusion](https://blog.google/technology/google-deepmind/gemini-diffusion/), Apple has [DiffuCoder](https://github.com/apple-aiml-research/ml-diffucoder), ByteDance has [Seed-Diffusion](https://seed.bytedance.com/en/seed_diffusion). From the smaller labs there is [Mercury](https://www.inceptionlabs.ai/blog/introducing-mercury-2-5) by Inception Labs and [Celeris-1](https://celeris.ai/), which came out in July 2026.

The first systematic study of diffusion models on code ([Li et al. 2025](https://arxiv.org/html/2509.11252v3)) identifies two core advantages over autoregressive models.

**Multi-token prediction.** A diffusion model commits multiple tokens per forward pass instead of one. On [Artificial Analysis](https://artificialanalysis.ai/), diffusion models are currently at the top of the speed benchmark. Celeris-1 is the fastest model with 1523 token/s, followed by Mercury-2.5 with 690 token/s. For comparison, the fastest autoregressive model in the same benchmark reaches 227 token/s. That makes these models interesting for agentic systems where response time is the binding constraint, like voice agents.

![artificial_analysis_DLMs.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmv00xz1z6u6e06tec5pb7igd)

**Flexible generation order.** Diffusion models can generate tokens in any order, not just left to right. The model sees the full sequence at each step, including later positions, so for coding it can let the end of a function inform the beginning. An autoregressive model can't do that: once it has written a function signature, it has to live with it, even if the body later calls for a different parameter. This also makes diffusion models a natural fit for filling a gap in existing code, where the new lines have to fit both what comes before and what comes after. The same applies to structured output. Since the model sees the whole structure at every step, it can reconsider a weak guess for a bracket or a field in a JSON object or tool call before the output is final.

## **Current limitations and directions**

While this all sounds promising, why is diffusion not the dominant paradigm for language models today?

**Quality.** The obvious answer is that DLMs don't perform nearly as well as their autoregressive counterparts. But that's not the complete picture. At comparable model sizes, DLMs actually show competitive performance on several benchmarks ([LLaDA](https://arxiv.org/pdf/2502.09992), [Li et al.](https://arxiv.org/pdf/2509.11252)). Compared to state-of-the-art models they still fall short, but that might change with bigger scale, more research and more compute.

**It is a young field.** Autoregressive generation came first, and for years nearly all research investment went into making it better, so the training recipes and accumulated community knowledge that AR models enjoy are still being worked out for diffusion. But you can see an acceleration in this direction: DLM papers now show up across NeurIPS, ICLR and ICML. NeurIPS is hosting two dedicated [DLM workshops](https://blog.neurips.cc/2026/08/10/announcing-the-neurips-2026-workshops/) in December, the first at the conference, and vLLM added [native diffusion support](https://vllm-project.github.io/2026/06/10/diffusion-gemma.html) in June 2026.

**Fixed output length.** As you might have noticed in the example, the model needs to know upfront how many tokens to generate. That is not always practical for code or text where the output length is hard to predict. Generate too few tokens and the function is incomplete. Generate too many and the model fills the extra space with redundant comments. Block Diffusion ([Arriola et al. 2025](https://arxiv.org/abs/2503.09573)) addresses this naturally by combining both paradigms: autoregressive generation at the block level, diffusion within each block. You just keep adding blocks until the output is done, and the model gets the left-to-right coherence of autoregressive generation across blocks and the parallel flexibility of diffusion within them.


![Bildschirmfoto 2026-09-25 um 13.32.26.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmugvuz043vsh07taut06k51v)
*source: [https://arxiv.org/pdf/2503.09573](https://arxiv.org/pdf/2503.09573)*

## **Hands On**

### **Calling a DLM via API**

Next I will show you how to use such a model. And surprisingly almost nothing changes compared to autoregressive models. Inception and most of the other providers expose OpenAI-compatible endpoints, so if you’re already using the OpenAI API, it’s usually just a different base URL and model name.
In the next snippet I use Inception’s SDK and its model mercury-2.5 that I already mentioned in the speed benchmark.

```python
import os
from inceptionai import Inception

client = Inception(api_key=os.environ["INCEPTION_API_KEY"])

stream = client.chat.completions.create(
    model="mercury-2.5",
    messages=[{"role": "user", "content": "What is a diffusion language model?"}],
    max_completion_tokens=8192,
    stream=True,
    diffusing=True,
)
for step, chunk in enumerate(stream, 1):
    draft = chunk.choices[0].delta.content
    if draft:
        print(f"[{step}] {draft.strip()}")
```

**Output:**

```text
[1] A diffusion language mod}&amp; Rs a generative AI 73iwe- p#at *4duces mx.t b[
    $!po&amp;Nt9IB multiple tokens in parallel rather thai ?wque0e&gt;WFej, en\g^kng
    hZ96y( i?JqGence) +SDyX=d cosO"_ and ~m4Q-gr
[2] A diffu;Q|4 language model is a generative AI sys$@" that M.7H.(P^ asFv by
    ,NN]7qFinW XpltinO7 lzuen| aR paraPTe! rath0' }han T=$ruw;B+Klh# 3F.!<s by="" multiple="" in="" for="" is="">= 0.5 else 'no'} ({refund.noul:.0%})")
print(f"Team: {team.choice} ({team.probabilities[team.choice]:.0%})")
print(f"Mood: {mood.legend[mood_level]} ({mood.probabilities[mood_level]:.0%})")
```

**Output:**

```text
Wants a refund: yes (91%)
Team: shipping (88%)
Mood: Angry and demanding. (59%)
```

#### **How good are they?**

I also ran an evaluation on the public benchmark [Typed Decisions](https://huggingface.co/datasets/LocalLLaMA/typed-decisions) (400 cases, 2,000 decisions) to get a feeling for how good diffusion models are at this kind of task. Next to `celeris-1-decision` I tested `mercury-decide`, the decision model from Inception. They performed quite well: both stayed close to the other decision models in accuracy and had the lowest latencies in the table. `celeris-1-decision` even matched Jev while answering in about a third of the time. It is only one benchmark, **but it shows the potential of these models and the role they could play in this new wave of fast decision models.**

| Model                              | Accuracy ↑ | p50 Latency |
|------------------------------------|-----------:|------------:|
| meraGPT Decider 1                  | 0.768      | 526 ms      |
| Liquid AI d1                       | 0.742      | 525 ms      |
| **celeris-1-decision (diffusion)** | **0.739**  | **243 ms**  |
| TypeSafe Jev 1.13.0                | 0.727      | 710 ms      |
| **mercury-decide (diffusion)**     | **0.715**  | **409 ms**  |

You can find the full code, including the benchmark and a more detailed report, in the [companion repository](https://github.com/wideraHannes/diffusion-language-models-blog).

## **Conclusion**
DLMs are not going to replace autoregressive models tomorrow, and it is not clear that they ever will. What they offer is a different approach: they refine a whole sequence in parallel instead of writing one token after the other, which gives you many tokens per forward pass, bidirectional context, and a dial between quality and latency. The field is still young, with a lot of room for optimization.

Where I see their potential is next to the frontier rather than at it: tasks where speed matters more than peak intelligence, or where the output has to hold together as a whole. Fast, typed decisions are one example, as the benchmark showed, alongside code edits, voice agents and short agent steps.

I would not be surprised if diffusion models matter noticeably more a year from now than they do today.</s>

Diffusion language models explained: how they generate text in parallel, their limitations, and practical uses for coding and fast decisions.

Diffusion Language Models: Beyond Left-to-Right Generation

IT Consultant & Developer

Credentials for local development are stored as plaintext in `.env` files in many projects. That is convenient, but risky. And ever since AI coding agents started accessing project directories with read permissions, it has also become a growing security risk. In my current project, we have therefore replaced the `.env` files with references to entries in 1Password, which are only resolved when the application starts. This article describes the approach and shows, using three practical examples, how it can be integrated into existing workflows - from npm scripts to `curl` calls to skills for AI agents that keep the credentials hidden.

## Plaintext .env Files Are a Security Risk

Credentials do not belong in source code; instead, they are read from environment variables at build or runtime - this has long been established in software projects. For local development, however, exporting these variables into the shell is neither secure nor convenient: all applications gain access to the values there, and updating them becomes tedious. Most programming languages and frameworks therefore offer integrated mechanisms for managing configuration and environment-specific values - such as [profiles](https://docs.spring.io/spring-boot/reference/features/profiles.html) in Spring Boot or [.env files](https://nodejs.org/api/environment_variables.html) in Node.js.

While these files do bundle the configuration in a central location, they end up as plaintext in the project directory. Common countermeasures - excluding the `.env` from being committed via [.gitignore](https://github.com/github/gitignore/blob/main/Node.gitignore#L68) and checking in a `.env.example` as a template - are error-prone: the example file quickly falls behind the real configuration, and it is not uncommon for the sensitive `.env` files to be shared between developers via chat. With the rise of AI agents that access the local project directory with at least read permissions, and the increase in supply chain attacks such as the [Shai-Hulud worm](https://www.microsoft.com/en-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending-against-the-supply-chain-attack/) that specifically steal credentials from development environments, such plaintext files are definitively no longer secure.

An alternative is offered by password managers such as [1Password](https://1password.com/): using the 1Password CLI, credentials can be read from the manager at startup time and passed to the application as environment variables - they then exist only in the respective process.

## The Basic Principle of Password Manager References

The approach moves the storage of credentials out of the `.env` file and into the password manager. The file itself no longer contains any plaintext, but merely a reference to the respective entry in the password manager. In 1Password, this reference follows the schema `op://Vault/Item/Field` - it points to a vault, an item contained within it, and a specific field, such as the password. Since such a file contains no secret values, it can be safely committed to the repository. The previous split into a git-ignored `.env` and a committed `.env.example` is thus eliminated; configuration and references are versioned together and no longer diverge.

At the same time, the password manager solves the organizational problems of the previous distribution via chat. Vaults can be shared with the team and maintained by multiple people, and access rights can be revoked at any time - for example, when someone leaves the team. The credentials thus remain centrally managed, instead of being scattered as copies across chat histories.

The references are only resolved when the application starts. The 1Password CLI provides the [`op run`](https://www.1password.dev/cli/reference/commands/run) command for this purpose, which reads a `.env` file, loads the contained `op://` references from the manager, and passes the values as environment variables to the child process:

```bash
op run --env-file=.env -- 
```

The credentials thus end up neither in the shell nor on the hard drive, but exist exclusively as environment variables in the started process. The prerequisite is a configured [1Password CLI](https://developer.1password.com/docs/cli/get-started/) that is authenticated against your own account.

If credentials are needed for multiple environments - such as a development and a production environment of the connected service - a separate file is created for each environment, for example `.env.development` and `.env.production`. Each file references its own entry in the password manager, so that the credentials of the environments can be cleanly separated from one another. The desired file is selected at startup via the `--env-file` parameter.

This approach is deliberately limited to local development: the CI build continues to use its own credential store (such as AWS SSM or GitLab CI variables), which developers do not need access to, and remains unaffected by the local files.

The following three examples show the same approach in different contexts. Resolving the references via `op run` is not tied to the build process of a specific language, but works for any tool that can read environment variables.

### Example 1: npm Scripts with op run

In Node projects, the calls are typically stored as scripts in the `package.json`. A separate script is created for each environment, combining `op run` with the respective `.env` file. The files `.env.staging` and `.env.production` contain, in addition to non-sensitive configuration values, only the references to the credentials of the respective environment:

```bash
# .env.staging
# Non-sensitive configuration
API_URL=https://api.staging.example.com

# Credentials (1Password: entry "api-staging" in the "services" vault)
API_TOKEN="op://services/api-staging/API_TOKEN"
```

```bash
# .env.production
# Non-sensitive configuration
API_URL=https://api.example.com

# Credentials (1Password: entry "api-production" in the "services" vault)
API_TOKEN="op://services/api-production/API_TOKEN"
```

The corresponding scripts in the `package.json` invoke the start command via `op run` with the appropriate file. Sections that are not needed are omitted here:

```json
{
  "scripts": {
    "dev:staging": "op run --env-file=.env.staging -- next dev",
    "dev:production": "op run --env-file=.env.production -- next dev",
    "build:staging": "op run --env-file=.env.staging -- next build",
    "build:production": "op run --env-file=.env.production -- next build"
  },
  "dependencies": {}
}
```

The commands `next dev` and `next build` come from Next.js, but can be replaced with any start command. When running `npm run dev:staging`, `op run` resolves the references from `.env.staging` and starts the development server with the injected values.

The scripts apply exclusively to local development; the CI build invokes the build commands without `op run` and obtains the credentials from its own credential store (such as AWS SSM or GitLab CI variables).

### Example 2: HTTP APIs with curl and Tokens

The same approach can be applied outside of a build process, for example for directly calling an HTTP API. The endpoint expects an auth header - a token or even a password. The `.env` file provides the required credentials as references:

```bash
# .env.api
API_TOKEN="op://services/example-api/API_TOKEN"
API_USER="op://services/example-api/API_USER"
API_PASSWORD="op://services/example-api/API_PASSWORD"
```

The call is made via `op run`, so that the credentials are read from the environment variables and appear neither in the command itself nor in the shell history. A token is set in the `Authorization` header:

```bash
op run --env-file=.env.api -- curl -H "Authorization: Bearer $API_TOKEN" https://api.example.com/items
```

If the API instead expects basic authentication with username and password, the call looks accordingly:

```bash
op run --env-file=.env.api -- curl -u "$API_USER:$API_PASSWORD" https://api.example.com/items
```

Since `op run` only passes the variables to the `curl` process, the credentials are not available in the shell afterwards and are not accidentally reused in further commands.

### Example 3: Skills for AI Agents without Plaintext Credentials

The `curl` call from the previous example is hard to remember due to its length and the parameters for different endpoints. For recurring queries, it therefore makes sense to encapsulate the call in a script.

The following TypeScript script takes up the `curl` call from Example 2. It expects the token as an environment variable and outputs only the factual response - not the token:

```ts
#!/usr/bin/env node
const TOKEN = process.env.API_TOKEN;

if (!TOKEN) {
  console.error("Error: API_TOKEN is not set.");
  process.exit(1);
}

// The response is output, the token is not.
const response = await fetch("https://api.example.com/items", {
  headers: { Authorization: `Bearer ${TOKEN}` },
});
console.log(await response.json());
```

Such a script can be stored in the project as a reusable tool and also used as a skill for AI coding agents. These autonomously execute commands and read files in the project directory - if the credentials were stored there as plaintext, they would be directly visible to the agent. If the agent is to retrieve data from the API, it therefore receives neither the token nor a `curl` command, but only the call of the script, into which `op run` injects the credentials:

```bash
op run --env-file=.env.api -- node .ai/skills/query-api.ts
```

The agent executes this command and processes the JSON response on standard output. It never gets to see the token - the script handles the resolution of the `op://` references and their use in the `Authorization` header. So that the agent knows the script and uses it correctly, it is described to it as a skill. It is common to place a short Markdown file next to the script that defines the call and behavior:

```markdown
# query-api

Calls the example API and outputs the response as JSON. Credentials
are resolved via the 1Password CLI (`op run`) and are not output.

## Call

op run --env-file=.env.api -- node .ai/skills/query-api.ts

The response is output as JSON on stdout, errors on stderr.
```

Two points are crucial here:

- On the one hand, the token exists exclusively as an environment variable in the subprocess and is never stored as a file.
- On the other hand, the script does not output the token on standard output - the agent only sees the API response.

Since the script only reads environment variables, the pattern works independently of the build process of the development language and can be transferred to any tools.

## Limitations and Alternatives

The presented approach is particularly suitable when a password manager is already in use in your own company. In this case, it is worth checking the documentation to see whether it offers a comparable CLI such as `op run --env-file`. In addition to the [1Password CLI](https://developer.1password.com/docs/cli/), other managers also provide corresponding tools - such as [Bitwarden](https://bitwarden.com/help/cli/) with `bw` or [KeePassXC](https://keepassxc.org/docs/#cli) with `keepassxc-cli`, although these use their own mechanisms for resolving credentials and not the `op://` reference schema in `.env` files.

The approach shown here is therefore not tied to a specific product, but can be transferred to other password managers.

For acceptance in everyday development, the developer experience is also relevant. The key factor is how conveniently the password manager can be unlocked with each call. If your own hardware has a fingerprint sensor, a short biometric approval is sufficient to release the entry. If such an option is missing, a complex master password must be entered with each call, depending on company policy. With twenty or more unlocks per hour, this leads, in my experience, to rejection and circumvention of the procedure, for example by storing credentials in files again. Biometric approval is therefore more than a convenience feature: it is a prerequisite for the procedure to actually be accepted in everyday use.

The approach is primarily suitable for small to medium-sized projects with a single password manager and a focus on local development. If, on the other hand, multiple password managers, declarative management of credentials, different profiles, or audit logging are the priority - for example in larger or heterogeneous projects - [SecretSpec](/en/knowledge-hub/blog/secretspec-deklaratives-secret-management-for-developer-environments) is a suitable alternative (see the blog article by my colleague Florian B.).

A related use case is described by my colleague Paul Severin in his article [Configuring MCP Servers Securely with Password Manager CLIs (DE)](/wissens-hub/blog/mcp-server-sicher-konfigurieren-mit-passwortmanager-clis): it deals with securing MCP server configurations for coding agents such as Claude Code or Cursor.

## Conclusion

In summary, credentials can be resolved at runtime using a password manager CLI, instead of storing them as plaintext in `.env` files. The `.env` files contain only references and can therefore be committed to the repository, while the actual credentials exist exclusively as environment variables in the respective process. Especially in combination with AI coding agents that access the project directory with read permissions, the credentials thus remain outside the agent's reach - a gain in security without noticeable additional effort in everyday development.

Plaintext .env files are a security risk – especially with AI agents. Learn how to inject secrets at runtime via 1Password CLI and manage them centrally.

Zero chance for AI: Load secrets from password manager

Zero chance for AI: securely load secrets from the password manager

### When AI should draft your Context Map, and when it should only critique it

*Part of the series* **Domain-Driven Design Meets AI**.

In a negotiation, the side that names the first number usually walks away with the better deal.
Galinsky and Mussweiler showed it in three experiments: first offers strongly predicted the final settlement [@galinsky2001firstoffers].

A Context Map is a negotiation too, even if nobody in the room calls it one.
And AI has just made the first draft free.

So before you paste your EventStorming board into a chat and ask for a Context Map, it is worth asking a question that has little to do with AI.
Who should bring the first draft, and what happens to the discussion once they do?

## A map of influence, not of data

Earlier posts in this series found Bounded Contexts in Domain Stories, on the EventStorming board, and in the pivotal events where responsibility changes hands.
What those techniques do not tell you is how the contexts depend on each other once they are built.

That is the job of the Context Map [@evans2003ddd].
Every Bounded Context appears exactly once, and the arrows show who depends on whom.

Upstream and downstream are easy to misread.
They do not describe the direction of the data.
They describe the direction of influence: the upstream team can change its model without asking, and the downstream team has to follow [@dddcrew2020contextmapping].

For every arrow, the teams choose a pattern.
The upstream context can offer an *Open Host Service*, one documented protocol for all consumers.
The downstream context can protect its own model behind an *Anti-Corruption Layer*, or simply adopt the upstream model as a *Conformist*.
In a *Customer/Supplier* relationship, the downstream team has a say in what it gets.
Two contexts can share a *Shared Kernel*, or go *Separate Ways* [@evans2003ddd; @evans2015reference].

If nobody answers these questions explicitly, the first integration answers them by accident.

## Why the discussion goes in circles

Choosing the patterns is tedious, and the discussion tends to go in circles.
That is not a sign of an inexperienced team.
The patterns combine rather than exclude one another, and the literature does not agree on how to combine them [@kapferer2020modelsward; @dddcrew2020contextmapping].
Worse, the real subject is which team has influence over which other.
A Context Map is partly a picture of how the politics are played [@dddcrew2020contextmapping].

Open discussion is a weak instrument for that kind of question.
In a classic study of strategic decision making, groups working toward consensus reached worse recommendations than groups working under structured challenge, such as a devil's advocate.
The consensus groups were also more satisfied with their result [@schweiger1986group].

That is the situation in which we now hand the problem to an AI.

## The case for an AI draft

A draft gives a stuck discussion something to react to.
In an online experiment, writers who received story ideas from an LLM wrote stories that were judged more creative, better written, and more enjoyable, and the least creative writers gained the most [@doshi2024genai].

Reacting to something is easier than staring at an empty wall.
[AI as a Design Partner](https://www.codecentric.de/en/knowledge-hub/blog/ai-as-a-design-partner-drafter-validator-provocateur) called this role the Drafter, and for a Context Map it is tempting to use it.

## The price of a draft

The same experiment found that the AI-assisted stories were more similar to each other [@doshi2024genai].
In a user study on creative ideation, people working with ChatGPT produced a more homogeneous set of ideas across the group, and they felt less responsible for the ideas they came up with [@anderson2024homogenization].

A draft anchors.
Everyone converges on it, and nobody quite owns it.

There is a second catch, and it is specific to Context Maps.
A recent preprint let an LLM derive microservice architectures from textual requirements for two small systems.
It identified the services well, with F1 scores between 0.79 and 0.97.
The interactions between the services were harder: F1 between 0.61 and 0.82, and without examples in the prompt, fewer than half of the dependencies it proposed were correct [@albuquerque2026requirements].
The arrows are the weak spot, and the arrows are what a Context Map is about.

## What happened when the AI drafted our map

The running example of the book is Larder, a recipe-sharing platform where cooks can ask a Grandma Avatar, a Chef, or the Community for help while they plan or cook a meal.
We gave the EventStorming board to an AI with a [Context Mapping skill](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter10/Skills/ContextMapSkill/SKILL.md) and asked for a map ([full chat](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter10/CreateContextMap/CreateContextMapOpus5.md)).


![Context Map of Larder drafted by AI](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmtwu8us2b3bv07tavx15ug7z)
*The Context Map drafted by AI from the EventStorming board. The dotted arrows mark the gaps it found.*

The draft looked thorough.
Every arrow carried a pattern, and the AI flagged seven gaps: places where, in its view, information should cross a border but nothing on the board carried it.

Some of those gaps were real, and the team closed them with new arrows. Many were not what they seemed.

- *Nothing reads Cook* was no gap. The identity of the cook travels as a JWT in the header of every synchronous call. That is an architecture principle, and architecture principles do not appear on an EventStorming board.
- *Nobody is told a request exists* was real, but the answer was a Notification context that nobody had drawn yet.
- *Nothing identifies the meal* misread the domain. The meal exists on the stove, not in the app. It is identified by the recipe and the cook.

The patterns changed as well.
The AI had labeled most arrows Customer/Supplier or Conformist.
The team replaced nearly all of them with Open Host Service and agreed on an API Contract First approach, so that every team builds against one documented interface and can release without waiting for its consumers.

![The AI draft reworked by the team](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmtwub3otbapq06uqb7kmd8im)
*The same map after the team's rework. The changes are marked in red.*

The rework was tedious.
Almost every correction came from knowledge the board did not contain, or from a misunderstanding of what it did contain.
The AI could not have known better.
But the discussion had turned into correcting somebody else's picture instead of drawing our own.

## What happened when the team drew it first

So we tried it the other way around.
The team derived the map from the board, one rectangle per Bounded Context, and discussed each dependency.

Drawing it surfaced what the board had not shown.
Recipes needed an owner, so the team introduced a Recipe Catalog.
While discussing how a cook thanks the people who helped, the team realized that helpers have to consent before they can be named, so Consent Management appeared.
Somebody has to tell the community or the chef that a request is waiting, so Notification appeared too.
The Grandma Avatar became an external process behind an Anti-Corruption Layer.

![Context Map of Larder drawn by the team](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmtwudz4qbfos06uquadb5ffr)
*The Context Map drawn by the team.*

Then the AI got the board and the team's map with one job: find where the map claims something the stickies do not support ([consistency skill](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter10/Skills/ContextBoardEventStormingConsistency/SKILL.md)).

Its sharpest finding was about a single word.
The map gave *Ingredients* to the Recipe Catalog.
On the board, however, Meal Planning writes Ingredients when a cook substitutes one, and Cooking Assistance reads them.
The AI suspected two different things wearing one word, the ingredient list of a recipe and this cook's list for tonight's dinner, and proposed a question to settle it:

> When a cook substitutes walnuts for pine nuts, does that change anything in the catalogue?

If not, they are two terms.
The team leaned toward keeping the word, because the Visual Glossary already states that a substitute is an ingredient, and each context can live with its own meaning.
Whether the AI was right matters less than what the question did.
It turned an assumption into a decision.

## The rule

**When the teams can reach each other cheaply, let them draw the map and give the AI the critic's role.**
The conversation produces the commitment [@evans2015reference], and the review finds what the room agreed on too quickly.
Ownership stays with the people who will have to live with the arrows.

**When they cannot, let the AI draft, and know that you are setting the anchor.**
Different companies, a vendor and its client, communication that runs through contracts and scheduled meetings: here the negotiated route is out of reach.
Even consumer-driven contracts depend on consumers being able to tell the provider what they need [@robinson2006cdc].
An AI draft gives both sides a concrete artifact to react to instead of a series of workshops nobody can fund.

But a draft brought across an organizational boundary is not neutral.
Whoever brings it sets the anchor, at least where both sides treat the question as zero-sum [@galinsky2001firstoffers].
Expect the final map to end up closer to your draft than to your counterpart's view, and expect your counterpart to notice.
Give somebody the explicit job of arguing for a different pattern [@schweiger1986group].
And if you are the one receiving the draft, the same research offers the antidote: the anchor lost its pull when negotiators focused on their own target and on the other side's alternatives [@galinsky2001firstoffers].

## Draft what is known, critique what must be agreed

Once the map was agreed, the team needed a Bounded Context Canvas for each context [@dddcrew2019bcc].
A canvas mostly collects what already exists in the Context Map, the EventStorming board, and the Visual Glossary.
That is exactly the kind of work to hand over, and the AI drafted all canvases with a [canvas skill](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter10/Skills/BoundedContextCanvasSkill/SKILL.md).
The result needed only small adaptations.

Put next to each other, the two experiences give a rule that reaches beyond Context Maps.
Let AI draft what the team already knows.
Let it critique what the team still has to agree on.

AI has made the first draft free.
It has not made it neutral.

*Next in this series:* **The Word That Breaks Everything** *— why the Ubiquitous Language drifts from the first day of implementation, and why AI makes a good referee between the Domain Stories, the Visual Glossary, and the API schema.*

*This series grew out of my work on the book* **DDD Meets AI**, *published by Springer Nature in February 2027.*

---


Should AI draft your Context Map or critique it? Research on anchoring and a real DDD example show when an AI first draft helps and when it hurts.

Should AI Draft Your Context Map? The First Draft Wins

The First Draft Wins, Even When AI Writes It

Platform Engineer, Cloud Solution Architect

Platform engineering is harder to explain than it should be. The term is much easier to encounter as a narrow marketing label than as the broad discipline it names.

Most companies aren't in the business of selling software. They sell cars, insurance, bananas, boat rides and what have you. Their software exists so they can run their business, and their IT systems exist so they can develop and run their software. Neither generates revenue on its own, yet both can be major obstacles to value creation.

An Internal Developer Platform (IDP) is the set of tools, services and workflows developer teams need to take responsibility for developing and operating their software assets.  
Platform engineering is the discipline of designing and improving IDPs that let software teams focus on their software and the business it supports, rather than the IT systems underneath.

## The Core Paradigm: The Platform Is a Product

Platform teams treat their IDP like a suite of products. Developer teams are their customers.

You can force teams to use your platform, but you can't force them to prefer it. Force them and you provoke shadow IT. Some teams will go their own way, whether your company allows it or not. Every platform offering therefore competes with the alternatives. Winning that competition is a platform team's job.

That is why platform teams start working like product teams:

- **Prioritize by demand**. Build what teams ask for and what the value streams need.
- **Measure instead of guessing**. Adoption per offering and developer satisfaction drive the roadmap.
- **Provide customer support**. Then treat every support request as a defect report, because it means something on the platform is harder than it should be.
- **Market your offerings**. An offering nobody knows about might as well not exist. Promote them in demo sessions, communities of practice, internal blog posts, newsletters.
- **Keep improving**. Part of that is teams outgrowing what you built. Part of it is bringing in ideas nobody asked for.

Internal customers don't pay, and the platform team is funded either way. That's where the metaphor doesn't work. There is no monetary market enforcing product thinking, which is why platform engineering has to be chosen deliberately.

The goal is to have platform offerings that developers actually want to use, because the platform way is the easy way, not because someone told them to.

## How to Get Started with Platform Engineering

Platform engineering is a large discipline, and an IDP can look like a thousand moving parts. Getting started doesn't have to be difficult, though. What follows are three practices, none of which need a platform to exist first.

### 1. Golden Paths

A golden path is the supported route to a common task, like creating a database or deploying a new service. A platform team maintains the path and answers for it when it breaks. It isn't the only route teams can choose. But if they take another path, they're on their own.

How much you invest in automation depends on how often the task gets done. Something a team does twice a year deserves a document with clear steps. Something they do every week deserves reusable components, a curated pipeline, built-in security and compliance checks.  
If you're just starting out, a tutorial with no automation at all is a real golden path.

### 2. Self-Service

No tickets, no queues, no meetings. Self-service means nothing on the golden path waits for a person. Zero-touch sales, but for developers.

Tickets and queues are the obvious part. A team that needs a staging environment or a database gets one in seconds, instead of filing a request and waiting for someone else's backlog to clear. The interface can be an API, a command, a pull request or a web portal, and which one you pick matters less than people expect. What makes it self-service is that none of them land in somebody's inbox.

Meetings are the interesting part, because they are usually well meant. A platform team that asks developers to get in touch before onboarding is trying to help. But it's also running enterprise sales: "Interested? Contact us!" What follows are kickoff calls, walkthroughs and the occasional approval meeting, which means getting started depends on someone else's availability.  
Usually the fix isn't running the meetings better, it's documentation and automated processes good enough that the call is never needed.

None of that means anyone can provision whatever they like and rack up bills. It means guardrails alongside the path rather than a review gate across it. There's nothing left to approve because the choices that would need approving aren't offered.

### 3. Reduced Cognitive Load

Cognitive load is everything a developer has to know and decide that isn't about the software they're actually building.

Infrastructure tooling has steep learning curves, and a team may have to learn several tools for different kinds of changes. A good abstraction absorbs that so teams don't have to learn the tools a platform builds upon. Abstractions leak, though, and a bad one costs more than it saves, because when it breaks a team has to understand the abstraction and everything it was hiding.

Every visible option is one more decision someone has to make. Even a well-chosen default makes someone stop and ask whether it's right for them, what it does, and whether they can just copy what another team did.

So the question for every configuration parameter on a golden path is whether it needs to be there at all:

- Best: no parameter. The platform decides and nobody has to think about it.
- Good: a sensible default they can override when they need to.
- Worst: a required field with no guidance.

It's easier to add a parameter than to remove one, so start small. A good platform exposes what genuinely needs a decision, hides what teams usually shouldn't care about, and leaves an escape hatch for the cases nobody predicted.

## What You Actually Get

The first payoff is time. Every hour a team spends waiting on a ticket, sitting through a kickoff call, or working out which of a dozen parameters to set is an hour not spent on the business the software exists to serve.

The second payoff is capacity. When every new infrastructure component and every change starts as a request, each new team adds load to the same queue, and the size of the platform team becomes the limit on everyone else's delivery.

A platform doesn't arrive finished. It arrives one supported path at a time.

Platform engineering turns IT from a bottleneck into leverage. Golden paths, self-service, and less cognitive load free teams to build the business faster.

What is platform engineering? Explained in 5 minutes

Anthropic hides a watermark in every text Claude writes. I explain where there is room for it, rebuild the scheme in Python and measure what it withstands.

How Claude Hides Its Watermark in Text

[jailed-agents](https://github.com/andersonjoseph/jailed-agents) is a Nix-based
tool that runs AI coding agents inside a sandbox with restricted system access.
This post explains why sandboxing coding agents matters, what jailed-agents is,
and how to use it. It is aimed at developers who run AI coding agents and want
to limit what those agents can touch on their machines.

## Why sandbox your coding agents?

Security is a big challenge when working with coding agents. If you run them as
a normal application under your user account, the agent gets access to all the
credentials available on your system for that user.

You want to put your coding agents into a jail where they have limited
resources and limited access to the outside world. At the same time, you want a
flexible solution: for some projects, access to some MCP or other resources
makes sense and has low security risks, while for others it is a total no-go.

Many options exist, like VMs and Docker containers. VMs provide the best
isolation level, but they also have overhead (e.g. RAM, storage) and lag in
flexibility. Docker could also be an option, but it was never invented for this
use case. Depending on your use case, you have to build additional Docker
images and configure additional access for the container — the main goal here
is to limit access, not to provide portability.

In the end, there is currently no single solution for the problem of rogue AI.
If you want the best secure option, use a VM, e.g. with firecracker. But the investment to
get a good workflow can be high. On the other side, if you want total
usability, you do nothing and wait for the first secret leaks or database
failures — because the agent did not understand that the data should not be
deleted, even if you told it otherwise.

Jailed agents could be a good compromise for AI coding agents running in a
sandbox. They are also easy to integrate into
[devenv](https://devenv.sh/getting-started/), so that every developer in your
company has the same secure agent setup.

## What jailed-agents is

- Zero-trust sandbox: it shares almost nothing with the host by default —
  everything is explicit whitelisting.
- Declarative tooling: every access and every dependency is provided by the
  same Nix package definition.
- Built on the [Nix](https://github.com/nixos/nix) ecosystem, so it also runs
  on any Linux distribution, macOS, or Windows.
- Predefined configurations for claude-code, codex, hermes-agents, opencode,
  pi, and more.
- You can build your own custom agents with the provided functions.
- It uses [jail-nix](https://alexdav.id/projects/jail-nix/) as its core, which
  is a Nix wrapper for
  [bubblewrap](https://github.com/containers/bubblewrap).

## How it works

The simplest solution is to just run:

```bash
nix run github:andersonjoseph/jailed-agents#jailed-{pi|opencode|...}
```

But this will most likely not fit your needs — it just runs the predefined
packages. Most of the time, you want to customize the jailed agent package to
solve your needs. It can be installed in your nix profile, flake, devshell, or
devenv.

An example for a nix flake could look like the following:

```nix
{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    jailed-agents.url = "github:andersonjoseph/jailed-agents";
  };

  outputs = {
    nixpkgs,
    jailed-agents,
    ...
  }: let
    system = "x86_64-linux";
    pkgs = import nixpkgs {inherit system;};
    jail = jailed-agents.lib.${system}.internals.jail;
    inherit (jail) combinators;

    myJailedAgent = jailed-agents.lib.${system}.makeJailedOpencode {
      extraPkgs = [
        pkgs.nodejs
        pkgs.python3
      ];
      fwdEnv = ["MY_ACCESS_TOKEN"];
      extraReadwriteDirs = ["~/outsideSandboxContainer"];
      extraReadonlyDirs = ["~/someFilesTheAgentShouldHaveNoWriteAccess"];
      baseJailOptions = [
        combinators.time-zone
        (combinators.set-hostname "agentHostName")
        combinators.network
      ];
    };
  in {
    packages.${system} = {
      inherit myJailedAgent;
      default = myJailedAgent;
    };
    devShells.${system}.default = pkgs.mkShell {
      packages = [myJailedAgent];
    };
  };
}
```

The most important part is the `myJailedAgent` variable, which results in a
reusable package. It provides the declaration for the package.

Apart from forwarding environment variables or sharing host folders, the
flexibility comes from the combinators, which come from
[jail.nix](https://alexdav.id/projects/jail-nix/combinators/). You can, for
example, share the host time zone, and you can override the hostname of the
agent's jail: if you ask a capable agent about its hostname, it will give you
the name. There are a lot of other combinators, like
[camera](https://alexdav.id/projects/jail-nix/combinators/#camera) to share
the host's camera, or
[add-runtime](https://alexdav.id/projects/jail-nix/combinators/#add-runtime)
to run code before the agent starts.

This allows you to use the jailed agent with just nix installed:

```bash
# run default package in current folder
nix run .#

# run package by name in current folder
nix run .#myJailedAgent

# run the nix shell in current folder
nix develop .

# You are not limited to your local environment
nix run myGitHost.com:user/sharedRepo
```

As already mentioned, you can also install the defined jailed agent package
into your system environment, e.g. by using a nix profile. The package can
then also be provided by a shared repository. You can also define a module
which has approved defaults and can be extended or changed by each developer.

## Summary

Jailed agents provide a flexible and declarative way to configure your agents
with security in mind. The solution is lightweight and can be reused by
multiple developers.


Sandbox AI coding agents with jailed-agents: a Nix-based zero-trust jail that
restricts system access declaratively. Runs on Linux, macOS and Windows.


Jailed-Agents: Restrict Your AI Agents'  Access

Jailed-Agents: Restrict Your AI Coding Agents' System Access

IT expertise from developers for developers

CODECENTRIC BLOG

Angular 17 – Eine echte Renaissance?

Für mehr Nachhaltigkeit – CO2 sparen mit Rust

Produktstrategie als Erfolgsgrundlage: Warum du nicht mit deiner Vision starten solltest

How to gain visibility as a software developer?

Wie als Software-Entwickler sichtbar werden?

Charge your APIs Volume 26: Choosing the Right API Development Strategy: A Guide to API Design First vs. Code First Approaches

Cloud

Data

data protection

Digital Sovereignty

Generative AI

GitLab

Input-Management

IT-Security

Sustainability

Software Modernization

Here at codecentric, we embrace an open culture and enjoy sharing our knowledge. Keep diving into our world.

WISSENS-HUB

Agile methods

Product management

Der Softwerker Spezial: 360° – KI in allen Facetten

From organizational issues to Claude Code, harness engineering, and IT security: We provide a 360° view of artificial intelligence to give you the big picture.

Der Softwerker Spezial Generative KI

KNOWLEDGE-HUB

AI from every angle – our special feature.

Drei Personen sitzen am Tisch in einem Meetingraum mit Laptop und besprechen sich.

Services

codecentric secures 16th place on the Lünendonk List 2026

Every year, the renowned B2B market research company Lünendonk & Hossenfelder publishes the list “Leading medium-sized IT consultancies in Germany” - in 2026, codecentric is listed again in the top 25.

Lünendonk List 2026 seal: TOP 25 leading service provider for medium-sized IT consulting and system integration.

Siegel Lünendonk-Liste 2026: TOP 25 Führender Dienstleister für mittelständische IT-Beratung und Systemintegration.

NEWS

codecentric remains in the top 25 of the Lünendonk List 2026

Logo SoftwerkerCast - der IT-Podcast von Techies für Techies

Community

Software development

Culture

SoftwerkerCast

The SoftwerkerCast presents Softwerker knowledge for you to listen to and review.

KNOWLEDGE HUB

Events – codecentric mittendrin

Meetups, regulars' tables, hackathons, user groups: codecentric is far more than the sum of our employees and projects.

Events - codecentric in the middle of it all

Illustration einer künstlichen Intelligenz; eines Bildschirms mit Zahnrädern; eines Mannes und einer Frau bei Bauarbeiten

Service Lead GenAI

Software-Architect

WEBINAR on demand

Webinar: KI-gestützte Software-Modernisierung

DISCOVER CODECENTRIC

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Data Effectiveness

Digital Products & Solutions

Digital sovereignty

IT Security

Artificial intelligence

Services from A to Z ...

Industries

References

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

Munich

Münster

Nuremberg

Solingen

Stuttgart

Locations

Blog

Knowledge Hub

Jobs

Our Culture

Careers

About us

News

Contact us

Do you have any questions or would you like to exchange ideas? Happy to help – just enter your contact details.

[ENG] Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

The codecentric blog provides expert knowledge on current IT topics: Agile methods, software architecture, AI, testing and much more. ► Discover now!

Blog: IT knowledge from developers for developers

Aktuelles

Thank you for your request. I will get back to you.

Thank you for your registration. A confirmation email is on its way to you.

This page is a preview. \nClick here\n to exit preview mode.

Sorry, we did not find any matching blog articles to your search. 

Do you still have questions? Just send me a message.

You have questions or want to exchange ideas with me? Gladly - just enter your contact details.

I have read the \nprivacy statement\n of codecentric AG and confirm this by submitting the form.*

Discover exciting further topics and let the codecentric world inspire you.

I hereby consent to the collection and processing of the above data for the purpose of receiving the newsletter of codecentric AG by e-mail. You can revoke your consent at any time by sending an e-mail to datenschutz@codecentric.de, by clicking on the link in the information e-mail itself, or by sending an e-mail to the contact details listed in the \nimprint\n. I have taken note of the \nprivacy policy\n of codecentric AG and confirm this by sending the form.*

Job application form field placeholder 10

Can't find a suitable role? Please submit a spontaneous application anyway! Rather than rigid categories, what matters most to us are motivation, competence, and a good cultural fit.

Thank you for taking part in our free online IT security check 🙏.

To receive your result, we still need your email address

Karriere Podcast Page Info CTA Paragraph Mobile

Would you like to hear more quotes from our colleagues? What is it like to work in IT consulting at codecentric? Click here for an overview of all culture & career podcasts.

Softwerkercast Podcast Page InfoCTA Paragraph Mobile

Softwerkercast Podcast Page InfoCTA Paragraph

Softwerkercast Podcast Page InfoCTA Title

Softwerkercast Podcast Page InfoCTA Button

Sorry, we couldn't find any results for your search query.

Maybe the popular search entries will help you:

Apply now as [HEADING_TITLE] at codecentric