devs group blog

Kubernetes v1.37: upgrading without downtime

Ralph Segi — Wed, 26 Aug 2026 00:00:00 GMT

Kubernetes v1.37 was released on 26 August 2026. Three changes break running clusters on upgrade: static pods may no longer reference secrets or config maps, the kubelet refuses to start when deprecated cAdvisor flags are set, and SELinuxMount is now on by default. The frequently quoted containerd 1.x deadline, by contrast, has been postponed again.

The full release notes are in CHANGELOG-1.37.md in the kubernetes/kubernetes repository, and the feature overview in the sneak peek of 31 July 2026. Anyone running between two and twenty production clusters needs only the part that hurts: an order of operations and a handful of check commands. That is what follows.

Static pods may no longer reference secrets and config maps

Kubernetes v1.37 removes the PreventStaticPodAPIReferences feature gate. Static pods using configMapRef or secretRef will not start after the upgrade. The ones affected are mostly bare-metal installations and self-managed control planes, not the standard components kubeadm manages.

This is a bug fix, not an imposition. Static pods are read by the kubelet directly out of /etc/kubernetes/manifests/ and do not go through the API server. That they could nonetheless reference API objects was a defect. According to the release entry the gate has been removed and can no longer be disabled.

The check takes a minute per node:

# On every control plane and worker node
grep -rlE 'configMapRef|secretRef' /etc/kubernetes/manifests/

Every output line is a manifest you have to rework before the upgrade. The replacement is unspectacular: write the values as literals into the pod spec, mount files through hostPath, or move the component out of the static pod directory into a real DaemonSet.

The kubelet will not start when old cAdvisor flags are set

The kubelet in v1.37 refuses to start as soon as a deprecated cAdvisor option appears in its configuration. The embedded cAdvisor now uses the leaner module github.com/google/cadvisor/lib, and of the old flags only --housekeeping-interval survives.

The release notes carry this as a deprecation, but in practice it behaves like a hard breaking change: a node with --containerd, --boot-id-file, --machine-id-file, --container-hints, --global-housekeeping-interval, --event-storage-age-limit, or one of the --storage-driver-* flags simply does not come back after a restart.

Where you look matters. The systemd unit is only one of the places: kubeadm puts its flags in /var/lib/kubelet/kubeadm-flags.env, and many distributions additionally in /etc/default/kubelet. Checking only systemctl cat gives you a clean result on an affected node.

# On every node: find forbidden cAdvisor flags in all three sources
FLAGS='--(application-metrics-count-limit|boot-id-file|container-hints|containerd|enable-load-reader|event-storage-|global-housekeeping-interval|log-cadvisor-usage|machine-id-file|storage-driver-)'

systemctl cat kubelet 2>/dev/null | grep -E -- "$FLAGS"
grep -hE -- "$FLAGS" /var/lib/kubelet/kubeadm-flags.env /etc/default/kubelet 2>/dev/null

No output means clean. On top of that, the metrics container_cpu_load_average_10s, container_cpu_load_d_average_10s and container_tasks_state disappear from /metrics/cadvisor. Anyone with a Grafana panel or an alerting rule hanging off those sees a silent gap after the upgrade rather than an error. That is the more unpleasant variant. More on this in our article on observability you actually read.

containerd 2.0 under Kubernetes: is the move mandatory for v1.37?

No, containerd 2.0 is not mandatory with Kubernetes v1.37 either. The claim has been circulating in upgrade guides since the v1.36 cycle and is wrong. Removal of the deprecated kubelet configuration flags along with the CRI fallback has been postponed twice: in CHANGELOG-1.36.md from v1.36 to v1.37, and in CHANGELOG-1.37.md again from v1.37 to v1.38 (PR #139121, merged 22 May 2026), explicitly “to align with containerd v1.7 support”.

Do not relax on that account. According to containerd RELEASES.md, extended support for containerd 1.7 ends in September 2026, and it is explicitly limited to Kubernetes 1.30 through 1.32 on GKE. For anything else, 1.7 is already unmaintained.

The kubelet tells you itself when the music stops:

# Node inventory: kubelet version, runtime, OS image
kubectl get nodes -o custom-columns='NODE:.metadata.name,\
KUBELET:.status.nodeInfo.kubeletVersion,\
RUNTIME:.status.nodeInfo.containerRuntimeVersion,\
OS:.status.nodeInfo.osImage'

# kubelet metrics: cgroup version and the runtime's end of support
kubectl get --raw "/api/v1/nodes/<NODE>/proxy/metrics" \
  | grep -E '^kubelet_(cgroup_version|cri_losing_support)'

kubelet_cri_losing_support is a gauge with a version label reporting the Kubernetes version in which the currently running CRI implementation loses support. Alpha stability, but exactly the number you need when planning.

What the jump from 1.7 to 2.x actually means:

Point	containerd 1.7	containerd 2.x
Support	extended to September 2026, only for K8s 1.30–1.32 on GKE	2.3 as LTS until 30 April 2028
CRI API	`v1` and `v1alpha2`	`v1` only, `v1alpha2` removed
`config.toml`	version 2	version 3 recommended, version 2 still works
Docker schema 1 images	pull possible, deprecated	disabled in 2.0, removed in 2.1
Runtime plugins as `*.so`	supported	removed in 2.1, use external plugins

If you migrate, go to containerd 2.3: LTS until 30 April 2028. containerd 2.2 already goes out of support on 6 November 2026, and 2.1 has been EOL since 3 July 2026. The config does not have to move at the same time; containerd 2.x still reads version 2.

If you are not sure whether your nodes come back after the kubelet restart, you can find out in about an hour: node inventory, kubelet unit diff, static pod scan. If you would rather not work through it yourself, we will look at it together.

cgroup v1 was settled in v1.35, not now

The kubelet has refused to start on cgroup v1 nodes since Kubernetes v1.35, because failCgroupV1 defaults to true there. The v1.37 sneak peek lists it as an ongoing change, not a new one.

In practice: anyone still on v1.34 does not meet cgroup v1 at the jump to v1.37 but at the intermediate step to v1.35. Affected are older node images and on-premise estates, typically CentOS 7, RHEL 7 and Ubuntu 18.04. The kubelet_cgroup_version metric from the block above answers this per node without anyone having to log in.

kube-proxy IPVS: the clock is running, but slowly

kube-proxy’s IPVS mode disappears over four releases, not in this one. KEP-5495 lays out the path: v1.35 warnings, v1.37 a new KubeProxyIPVS feature gate (on by default), v1.40 gate off by default, v1.43 code removed, v1.46 gate removed.

The reasoning is honest and readable in the KEP: “sig-network currently lacks maintainers who are familiar with the ipvs backend code.” On top of that, IPVS still uses iptables underneath. The migration target is nftables, GA since v1.33.

kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep 'mode:'

An empty mode: is worth a warning from v1.37 as well: kube-proxy now reports when no mode is set explicitly, because the Linux default will move from iptables to nftables. Set the value explicitly, even if you want to keep current behaviour.

Which Kubernetes version still has support

Kubernetes maintains the three most recent minor releases. The documentation calls that “roughly a year”; the last three releases actually ran 14.0, 14.4 and 14.2 months. Plan for twelve months and be pleased about the rest. As of kubernetes.io/releases on 18 August 2026:

Version	Release	End of life	What to do
v1.34	27.08.2025	27.10.2026	Urgent. Two months left, three minor jumps to v1.37
v1.35	17.12.2025	28.02.2027	cgroup v1 already enforced, IPVS warnings active
v1.36	22.04.2026	28.06.2027	The most comfortable position, one jump to v1.37
v1.37	26.08.2026	approx. October 2027 *	New, initially at .0 patch level

* EOL for v1.37 has not been published. The value is extrapolated from the 14-month pattern of the three predecessors and should be treated as a planning figure rather than a commitment.

For Swiss teams on Exoscale SKS there is a second cadence: minor versions are supported for around 14 months, upgrades must run sequentially through every minor version, and the control plane is raised first, after which the node pools are cycled. From v1.34 to v1.37 that is three rounds, not one.

An upgrade without downtime follows the official version skew policy: control plane before nodes, no skipped minor versions on the kube-apiserver.

Check before touching anything. Static pod scan, cAdvisor flag scan, kubelet_cgroup_version, kubelet_cri_losing_support, kube-proxy mode. All five commands are above.
Clear scheduling.k8s.io/v1alpha2 out of etcd. v1.37 removes the version entirely. The core types Workload and PodGroup have been promoted to scheduling.k8s.io/v1beta1, the rest to v1alpha3. Existing objects must go before the update.
Raise the kube-apiserver, then kube-controller-manager, kube-scheduler and cloud-controller-manager. Those three may be at most one minor version older than the API server.
Lift one worker node as a test. kubelet and kube-proxy may be up to three minor versions older than the kube-apiserver. So you have time, and you need it: the first node is the experiment.
Roll the remaining node pools, with PodDisruptionBudgets that deserve the name. A PDB with minAvailable: 1 on two replicas does not block a drain, it only delays it.

One point that often gets lost: SELinuxMount is GA in v1.37 and on by default. On clusters with SELinux enabled — practically every RHEL and OpenShift estate — that can break running workloads. Kubernetes published a dedicated blog post on 22 April 2026 that makes the affected patterns identifiable in a v1.36 cluster. Without SELinux, nothing changes.

When you should not upgrade

Do not upgrade to v1.37.0. Wait for v1.37.1 or v1.37.2, unless you have a concrete reason. On release day a .0 is the least production-exercised state of a version, and the history of the urgent upgrade notes gives little cause for optimism.

The trade-off is real and cuts both ways: waiting accumulates distance from v1.34, whose support ends on 27 October 2026. Because kube-apiserver may not skip minor versions, that is three sequential upgrades. Starting only in October means three jumps under time pressure rather than one at leisure. Every jump is operational effort, and operational effort is the largest item when you work through what Kubernetes really costs in Switzerland.

Our line: anyone on v1.36 has peace until June 2027 and can wait for .2. Anyone on v1.34 starts this week, and starts with v1.35, not v1.37. And anyone in the middle of a quarterly close or running a release freeze postpones the whole thing deliberately and in writing, rather than forgetting it.

Also, do not put everything into the same maintenance window. Ingress NGINX was retired in March 2026 with no further security patches, backed according to internal Datadog research by around half of all cloud-native environments. Moving to the Gateway API is its own project with its own risk, not a sideshow of a minor upgrade.

A cluster is not an end in itself anyway. Before planning three upgrade rounds, it is worth asking whether a cluster is the right answer at all.

Frequently asked

How does a Kubernetes cluster upgrade without downtime work?

A downtime-free upgrade raises the control plane first, then the nodes. kube-apiserver goes first, then controller-manager and scheduler, and finally kubelet and kube-proxy. Workloads stay available when every application has at least two replicas, a sensible PodDisruptionBudget and working readiness probes. Nodes are drained one at a time, not in parallel.

Which Kubernetes version is still supported?

Supported are v1.35, v1.36 and v1.37 once v1.37 is out. v1.34 reaches end of life on 27 October 2026. Kubernetes maintains the three most recent minor releases as a rule, which works out to roughly a year of patch support per version. Managed providers differ: Exoscale SKS gives around 14 months.

How do I check which kube-proxy mode my cluster uses?

The command kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:' reads the mode out of the ConfigMap. An empty value means the default, currently iptables on Linux. If it says ipvs, plan the migration to nftables: from v1.40 IPVS is off by default, and from v1.43 it is removed.

Do I have to move to containerd 2.x for Kubernetes v1.37?

No, not necessarily. Removal of the kubelet CRI fallback has been postponed to v1.38. Extended support for containerd 1.7 does however end in September 2026 and covers only Kubernetes 1.30 through 1.32 on GKE. In practice: plan the move to containerd 2.3 now, but not in the same maintenance window as the v1.37 upgrade.

A little over two months until v1.34 reaches end of life. To v1.37 that is three sequential jumps, and each needs its own maintenance window. We will walk the path with you once: which version first, what breaks at each jump, how long it realistically takes. At the end you have an order of operations, not a presentation.

Write to us through contact with the version you are running and how many clusters hang off it, and we will prepare the path. Or book a slot directly. What else we build and operate in clusters is under Kubernetes and infrastructure.

What Kubernetes really costs in Switzerland

Ralph Segi — Tue, 25 Aug 2026 00:00:00 GMT

A production Kubernetes cluster with three worker nodes of 4 vCPU and 16 GB RAM each, 500 GB of storage and a control plane with an SLA costs between CHF 158 and CHF 779 a month at Swiss providers. That is the smaller half of the bill. Operations start at CHF 1,730 a month, calculated at four hours a week at the lowest Swiss hourly rate.

Both figures are a model calculation. Every input comes from a public price list, retrieved on 19 August 2026. For context we worked the same scenario through on Azure in Switzerland North and on AWS in Europe (Zurich). The derivation is below, item by item.

Why searching for Kubernetes prices in Switzerland comes up empty

Search for Kubernetes costs and you find calculators from AWS, Azure and Google in USD and EUR. For Swiss providers there is not a single worked comparison in CHF. That is the reason for this article.

Instead, two figures circulate that both come from search summaries rather than from checked price lists: “managed Kubernetes from CHF 100 a month” and “CHF 150 to 400 a month”. We looked both up. Both are wrong, in different directions.

The cheapest published entry point is considerably lower. At Infomaniak the shared control plane is free, and three worker nodes with 2 vCPU and 4 GB RAM cost CHF 0.01043 per hour per node, so around CHF 23 a month together. With a load balancer, a minimal cluster lands at roughly CHF 33.

And a cluster at production size is considerably higher than CHF 400. At Flow Swiss a single worker node with 4 vCPU and 16 GB RAM alone costs CHF 197 a month. Three of them are mandatory.

The four cost blocks the bill is made of

A Kubernetes bill consists of control plane, worker nodes, storage plus traffic, and operations. The first three are on the price list. The fourth is nowhere and is the largest.

First, because it is the second most common search in this area: Kubernetes is open source under the Apache 2.0 licence and therefore free of licence cost. Operating it is not. You do not pay a licence, you pay for machines and people.

Control plane. The price for the managed control plane. Exoscale and Infomaniak give it away in the basic variant, though then without an SLA. At Flow Swiss it costs CHF 73 a month per cluster, independent of cluster size.

Worker nodes. The largest item on the bill. Between Swiss providers the differences here are factors, not percentages.

Storage and traffic. Block storage is billed per GiB-hour. Egress models differ sharply: Infomaniak gives bandwidth away free as a matter of course, Flow Swiss includes 20 TB per organisation per month, and Exoscale grants 1.42 GiB per hour per instance and charges CHF 0.02 per GiB after that.

Operations. Upgrades, certificates, network policies, alerts at three in the morning. This block appears on no price list, because no provider sells it.

This is exactly where budgets slip. A managed Kubernetes offering from Infomaniak or Exoscale takes on the control plane, the etcd backups and node provisioning. Everything above the Kubernetes API stays with you: ingress, certificate rotation, RBAC, backups of application data, alerting, and the question of who plans the upgrade path.

What managed Kubernetes costs: the Swiss provider comparison

Of seven Swiss providers, four publish a price list and three do not. All values in the table below come from the linked price lists, retrieved 19 August 2026, excluding VAT.

Provider	Control plane	Worker 4 vCPU / 16 GB	Block storage	Egress	Data location	SLA
Exoscale SKS	Starter free, Pro CHF 0.054995/h	CHF 0.18667/h	CHF 0.00014 per GiB/h	1.42 GiB/h per instance free, then CHF 0.02/GiB	zones ch-gva-2, ch-dk-2	99.95 % (Pro)
Infomaniak	Shared free, dedicated 4 from CHF 0.04/h	CHF 0.03429/h	CHF 0.00012 per GiB/h	included	own data centres in Switzerland	99.9 % (dedicated)
Flow Swiss	CHF 73/month per cluster	CHF 197/month (k1.4x16)	CHF 0.22 per GB/month	20 TB per organisation included	ZRH1 Zurich, ALP1 Lucerne	99.9 %
cloudscale.ch	no managed Kubernetes of its own	CHF 4.40 per 24 h (Flex-16-4)	published	100 GB per 24 h included	Switzerland	99.99 %
VSHN / APPUiO	included in the service price	from CHF 4,900/month for the whole cluster	client’s infrastructure	client’s infrastructure	free choice	up to 99.99 % 24/7
Metanet	no public price list	no public price list	no public price list	no public price list	Switzerland, ISO 27001	enterprise SLA on request
Swisscom	no public price list	no public price list	no public price list	no public price list	Switzerland	not published
Azure AKS, Switzerland North	free tier free, Standard CHF 0.082/h	CHF 0.2075/h (D4s v5)	CHF 72.68/month (P20, 512 GiB)	100 GB/month free, then CHF 0.0656/GB	Switzerland North	free without SLA, Standard with a stated uptime SLA
AWS EKS, Europe (Zurich)	USD 0.10/h per cluster	USD 0.253/h (m6i.xlarge)	USD 0.1142 per GB/month (gp3)	USD 0.09/GB up to 10 TB	eu-central-2	99.95 %

Three notes. First, Flow Swiss computes monthly prices with 730 hours and Exoscale with 720; we standardise on 730 below. Second, AWS publishes only USD for the Zurich region, while Azure delivers genuine CHF prices for Switzerland North through the retail prices API. We convert nothing, because we have no defensible reference rate for a given day.

Third, Exoscale has belonged to A1 Digital, a subsidiary of the Telekom Austria Group, since 2017. The data sits in Switzerland; the ownership does not. For revDSG questions both count.

The model calculation: the same cluster at five providers

The same reference scenario costs between CHF 158.10 at Infomaniak and CHF 779.00 at Flow Swiss. The scenario: three worker nodes of 4 vCPU and 16 GB RAM each, 500 GB of persistent storage, a control plane with an SLA, one load balancer, egress under 1 TB, calculated at 730 hours.

Provider	3 worker nodes	Control plane	Storage	Load balancer	Total per month
Infomaniak	CHF 75.10	CHF 29.20	CHF 43.80	CHF 10.00	CHF 158.10
Exoscale	CHF 408.81	CHF 40.15	CHF 66.43	CHF 25.35	CHF 540.74
Azure AKS, Switzerland North	CHF 454.42	CHF 59.86	CHF 72.68	CHF 14.78	CHF 601.74
Flow Swiss	CHF 591.00	CHF 73.00	CHF 110.00	CHF 5.00	CHF 779.00
AWS EKS, Europe (Zurich)	USD 554.07	USD 73.00	USD 57.10	USD 21.68	USD 705.85

A model calculation, not a quotation. Prices excluding VAT, retrieved 19 August 2026 from the price lists linked above. The storage row additionally contains the node disks at Exoscale (3 × 50 GiB), which are billed separately there; at Infomaniak 50 GB per node is included in the flavour; at Azure it corresponds to a premium SSD P20 with 512 GiB. Egress falls within the free allowance or is free at all five.

Price is not performance. Infomaniak runs shared vCPUs in an OpenStack cluster and positions itself explicitly on price. Flow Swiss delivers dedicated resources, a 99.9 per cent SLA and two Swiss regions. What the table does not capture: support quality, response time during incidents, API maturity, how quickly a new Kubernetes minor version becomes available.

What Kubernetes costs on Azure and AWS in Switzerland

Azure AKS in Switzerland North costs CHF 601.74 a month in the same scenario, AWS EKS in Europe (Zurich) USD 705.85. Both therefore sit within the field of Swiss providers rather than above it. That refutes the widespread assumption that a hyperscaler is automatically the expensive option.

Azure is cheaper than Flow Swiss and dearer than Exoscale. Infomaniak undercuts Azure by nearly a factor of four. The price spread within Switzerland is therefore larger than the gap between Switzerland and the hyperscalers.

Two differences that appear on no price list. First, egress: Azure gives 100 GB a month free and charges CHF 0.0656 per GB after that, AWS USD 0.09 per GB up to 10 TB. At Infomaniak bandwidth is free; at Flow Swiss 20 TB is included. Shipping 2 TB (2,000 GB) a month costs an additional CHF 124.64 at Azure and nothing at Infomaniak.

Second, the legal position. Microsoft and AWS operate Swiss regions but as US groups are subject to the CLOUD Act. For revDSG reviews with elevated protection needs, that is the point where the pricing question ends and the architecture question begins.

What operations cost: Swiss hourly rates as the unit

Operations cost a multiple of the infrastructure. gryps.ch gives, for software engineering in German-speaking Switzerland, CHF 100 to 150 an hour for junior profiles and CHF 140 to 180 for senior profiles, with CHF 160 as the midpoint in the published example (retrieved 19 August 2026). Running a cluster is senior work.

Operational effort	CHF 100/h	CHF 140/h	CHF 180/h
4 h per week (17.3 h/month)	CHF 1,730	CHF 2,430	CHF 3,120
10 h per week (43.3 h/month)	CHF 4,330	CHF 6,070	CHF 7,800
20 h per week (86.7 h/month)	CHF 8,670	CHF 12,130	CHF 15,600

The row that matters: even the most cautious assumption, four hours a week at the lowest published rate, comes to CHF 1,730 a month. That is more than the most expensive infrastructure bill in the comparison above.

Four hours a week is tight for a production cluster. Kubernetes ships three minor versions a year, each with deprecations. How much preparation a single upgrade costs we worked through on the example of 1.37.

Work your own case through completely once, infrastructure plus person-days. We do that with you in one session, with your node sizes and your price list, and you keep the table. Thirty minutes with an engineer who runs Swiss clusters.

Managed, self-operated, or operated for you

There are three operating models, and they differ less in price than in who gets up at night. The matrix below sorts them along the criteria that actually come up in budget discussions.

Criterion	Managed at the provider	Self-operated on IaaS	Operated for you
Infrastructure per month	CHF 158 to 779	CHF 132 per node per 30 days at cloudscale.ch	as managed or IaaS
Internal operational effort	4 to 10 h a week	10 to 20 h a week	close to zero
Additional operating cost	CHF 1,730 to 6,070	CHF 4,330 to 12,130	from CHF 4,900 at VSHN
Control plane	provider	you	partner
Vendor lock-in	high	low	low
Data location controllable	provider zones only	fully	fully
Fits when	one team, clear workloads	compliance demands your own control	the platform is critical and the team is small

The price for “operated for you” is public: VSHN publishes CHF 4,900 a month as the baseline for managed OpenShift on cloud provider infrastructure, CHF 7,500 with 99.9 per cent around the clock, and CHF 10,100 at 99.99 per cent (retrieved 19 August 2026). The hourly rate for additional work is CHF 250.

This is where the gap in the Swiss market sits. Exoscale, Infomaniak, Flow Swiss, cloudscale.ch, Metanet and Swisscom sell infrastructure. VSHN sells its own platform. Nobody sells “we build and operate your platform on your infrastructure, with your tools”. That is precisely our position, which is why it appears here in the matrix rather than in an advertising box.

Where the over-provisioning nobody sees is hiding

The infrastructure bill is created at a point that lives in the code, not in the portal. Kubernetes schedules pods by requests, not by actual load. Requesting generously means paying for nodes worth of capacity that is never used.

resources:
  requests:
    cpu: "2"
    memory: "4Gi"
  limits:
    cpu: "2"
    memory: "4Gi"

Four such pods occupy 8 vCPU and thereby tie up, on the CPU side, two of the worker nodes from our reference scenario. At Flow Swiss that is CHF 394 a month, at Infomaniak CHF 50.06. Whether the pods use 5 per cent or 95 per cent of it is not visible on the bill.

Comparing requested against consumed takes two commands:

kubectl get pods -A -o custom-columns=\
NS:.metadata.namespace,\
POD:.metadata.name,\
CPU_REQ:.spec.containers[*].resources.requests.cpu,\
MEM_REQ:.spec.containers[*].resources.requests.memory

kubectl top pods -A --containers

Wherever the second output sits durably far below the first, you are paying for air. That is the only lever in this article that works without changing provider.

When the cluster does not pay for itself

Below roughly five services and one team, Kubernetes does not pay for itself in Switzerland. At CHF 158 of infrastructure and CHF 2,430 of operations a month, around 94 per cent of the bill goes on operational knowledge that a single well-sized VM with Docker Compose, systemd and a clean deploy script does not need.

We advise against it in those cases, even though we build and run Kubernetes. The honest question is in Kubernetes is not a goal: what happens when this service falls over at three in the morning, and who looks at it? If the answer is “an alert, a runbook, a restart”, you do not need an orchestrator.

The cluster pays for itself as soon as several teams deploy independently, load spikes are unpredictable, or compliance demands reproducible, declarative infrastructure with an audit trail. For onocoy and Relai exactly that applies. For an application with one database and known traffic it does not.

What changes on the bill over twelve months

Over twelve months it is mostly the worker nodes that move, and in both directions. Right-sizing the requests typically extracts the most, because it directly reduces the number of nodes.

Cluster autoscaling only helps with variable load. With constant baseline load it does not move the bill, it complicates it. Infomaniak and Exoscale support node pools with a minimum and a maximum; setting both to the same value gives you autoscaling in name only.

What is missing in Switzerland: reservations. Neither Exoscale nor Infomaniak nor Flow Swiss publishes discounts for term commitments of the kind AWS offers with savings plans. Planning to save 30 per cent through prepayment means planning with an instrument that does not exist here.

The operations side moves the other way. Effort is highest in the first year, because ingress, secrets handling, backup strategy and CI integration are only being built. After that it settles to a background hum of upgrades and incidents, and that background hum is the number to plan with, not the build-out effort.

The item that blows this calculation apart fastest is not in it: GPUs. A single inference card costs more than the entire cluster above. What sovereign AI inference costs on Swiss infrastructure, and from what request volume self-operation beats an API, is in sovereign AI inference in Switzerland.

Frequently asked

What does a managed Kubernetes cluster cost per month in Switzerland?

A cluster with three worker nodes of 4 vCPU and 16 GB RAM each, 500 GB of storage and a control plane with an SLA costs between CHF 158 and CHF 779 a month, depending on the provider. The minimum for a very small cluster at Infomaniak is around CHF 33. All values from published price lists, retrieved 19 August 2026, excluding VAT.

Isn’t Kubernetes free?

Kubernetes is open source under the Apache 2.0 licence, and there are no licence costs. Costs arise from machines and people: control plane, worker nodes, storage and traffic come to CHF 158 to 779 a month for a cluster at production size, plus operational effort from CHF 1,730 a month. The licence-free part is the smallest part of the bill.

What does Kubernetes cost on Azure and AWS in Switzerland?

Azure AKS in the Switzerland North region costs CHF 601.74 a month in the reference scenario, AWS EKS in Europe (Zurich) USD 705.85. Both sit within the field of Swiss providers: dearer than Exoscale at CHF 540.74, cheaper than Flow Swiss at CHF 779.00. AWS publishes only USD prices for Zurich; Azure delivers genuine CHF prices (as of 19 August 2026).

As an SME do I need Kubernetes at all, or is Docker Compose enough?

Docker Compose on a VM is enough as long as there is one application, one database and one team, and traffic is known. Kubernetes earns its keep from several independently deploying teams, unpredictable load spikes, or compliance requirements for declarative infrastructure. Operating costs from CHF 1,730 a month upward decide this question more often than the infrastructure costs do.

Does my data stay in Switzerland with a Swiss Kubernetes provider?

That depends on the provider and the zone chosen. Infomaniak operates its own data centres in Switzerland, Flow Swiss the regions ZRH1 and ALP1. Exoscale offers the Swiss zones ch-gva-2 and ch-dk-2, but has belonged to the Telekom Austria Group since 2017. For revDSG reviews, ownership matters alongside location.

Let’s work through your cluster

Bring your node sizes, your storage class, and an honest estimate of the internal hours. We put the current price lists next to them and work both sides of the bill, infrastructure and operations, through in one session.

Book a slot or write to us if you would rather ask by email. What we build and operate in this area is under Kubernetes and infrastructure.

Sovereign AI inference in Switzerland: the architecture

Robert Pupel — Mon, 24 Aug 2026 00:00:00 GMT

Sovereign AI inference is a property of the whole data flow, not of the model. An Apertus model hosted in Zurich is not sovereign if the traces land at a US monitoring service, the vector database sits in Ireland, or support from a third country reads the logs. An architecture is sovereign only when prompt, context, weights, logs and metadata never leave the same jurisdiction.

A great deal has been written about digital sovereignty. ipt, for instance, runs a page titled “Sovereign AI platforms on Kubernetes” and has worked the subject with the ETH AI Center. What is missing is the layer beneath: which providers exist, what they cost, what operating them looks like.

We work it through on the Swiss market, because prices and legal position there are publicly checkable. The architecture underneath is the same whether the sovereign cloud sits in Zurich, Frankfurt or Paris.

What sovereign AI inference means technically

Sovereignty can be checked against five artefacts produced by every inference request: model weights, prompt, retrieved context, generated response, and the telemetry about it. Each has a physical location and a legally entitled accessor, and those two are not the same thing.

Swiss law turns that into a concrete test. Art. 16 revDSG permits disclosure of personal data abroad only where the Federal Council has assessed the destination state as adequate.

The list is in Annex 1 of the Data Protection Ordinance (SR 235.11). The USA has been on it since 15 September 2024, but only for organisations certified under the Swiss-US Data Privacy Framework.

The second test runs through the provider itself. 18 U.S.C. § 2713, introduced with the CLOUD Act, obliges US providers to hand over stored data “regardless of whether such communication, record, or other information is located within or outside of the United States”.

A data centre in Zurich changes nothing about that if the operating company is subject to US corporate law. Which architecture decisions follow is in A revDSG-compliant AI architecture.

Which Swiss cloud providers offer sovereign AI inference

Four providers realistically come into question for production GPU inference in Switzerland, plus self-operation. Only one of them publishes complete prices.

Provider	GPU types	Billing model	Data location	Kubernetes access	Public prices
Exoscale	RTX Pro 6000 (96 GB), A40, A5000, A30, V100, 3080ti; B300 on request	per instance-hour, dedicated inference per second	depending on GPU type CH-DK-2 (Switzerland), DE-FRA-1, AT-VIE-2, HR-ZAG-1	yes, SKS	yes, complete in CHF
Infomaniak	B300, H200, H100, A100, L40S, L4, A2, T4	GPU instance per hour, AI services per token	Geneva and Zurich	yes, Kubernetes service	partly: token prices published, instance prices only in the configurator
Swisscom Swiss AI Platform	NVIDIA SuperPOD	GPU as a service, plus inference endpoints per token	Switzerland	not documented	no
Phoenix Technologies	H100, H200	not published	Switzerland	not documented	no
Self-operation, colocation	free choice	CapEx plus housing	free choice	yes, self-built	n/a

One detail that counts in a sovereignty review: Exoscale’s RTX Pro 6000 instances run in DE-FRA-1, HR-ZAG-1 and CH-DK-2, and the 3080ti instances exclusively in AT-VIE-2. A Swiss provider does not automatically guarantee a Swiss zone (retrieved 19 August 2026).

Apertus 1.5: what the Swiss model can do today

Apertus 1.5 appeared on 24 July 2026 and is a different model from the September 2025 version. The context window is 262,144 tokens, a fourfold increase. The models now accept images; audio is marked experimental. Licence: Apache 2.0.

For operations, tool integration matters more than multimodality. The model card for Apertus-v1.5-70B documents a dedicated tool-call parser and an optional thinking mode, both drivable directly in vLLM. That makes Apertus usable for agent architectures, not only for chat.

It was developed by EPFL, ETH Zurich and CSCS on the Alps supercomputer in Lugano. For those who do not want to run it themselves, Infomaniak lists swiss-ai/Apertus-v1.5-70B as an API model, currently in beta.

Running Apertus yourself: Hugging Face, Ollama or Apertus Mini

There are three routes to self-operation, with very different degrees of production readiness.

Hugging Face plus vLLM is the production path. swiss-ai/Apertus-v1.5-70B and the 8B variant sit there under Apache 2.0 and load without a conversion step.

Ollama is the fastest route to a prompt and the slowest to production. There is no official Apertus build from swiss-ai; the widespread GGUF packages come from community packagers and carry the 2509 release, i.e. Apertus 1.0. Anyone wanting 1.5 locally quantises it themselves. For a laptop test that is fine; for a service under concurrent load it is not.

Apertus Mini often solves the actual problem. The official collection contains v1.1 distillates at 0.5B, 1.5B and 4B, plus quantisations for MLX and vLLM. For classification, extraction and routing a 4B model is usually enough, and it moves the GPU cost by an order of magnitude.

What inference on your own infrastructure costs

A model calculation, derived from published price lists retrieved on 19 August 2026. It applies to Apertus-v1.5-70B and compares two purchasing routes at the same level of sovereignty.

The model card gives --tensor-parallel-size 4 as the reference configuration at the full 262,144 tokens of context. With 72 billion parameters in BF16 that is 144 GB of weights alone, plus the KV cache. Four cards of 96 GB each are therefore the minimum, not generosity.

Self-operation, Exoscale dedicated inference on RTX Pro 6000, published price list:

CHF 2.15277778 per GPU-hour, billed by the second
4 GPUs running continuously: 4 × 2.15277778 × 720 h = CHF 6,200 per month (720 hours, as Exoscale itself converts to monthly prices)
Model storage 134 GiB (144 GB of weights) at CHF 0.0000275 per GiB-hour: CHF 2.65 per month

API purchase, Infomaniak AI Services, published price list: CHF 0.70 per million input tokens, CHF 2.50 per million output tokens for the same model.

Assumed request profile: 3,000 tokens of input (system prompt plus RAG context), 500 tokens of output. That comes to CHF 0.00335 per request, or CHF 0.96 per million mixed tokens.

The break-even sits at around 1.85 million requests per month, i.e. roughly 62,000 a day. Below that the API is cheaper. That corresponds to 6.5 billion tokens a month, or around 2,500 tokens per second of sustained throughput.

At 2,500 tokens per second, though, the four cards run flat out around the clock, and no operation runs like that. Planning headroom for load spikes and a second zone for failures doubles the GPU cost and with it the break-even: realistically three to four million requests a month.

Conversely, per-second billing helps: someone with load only during office hours who scales to zero pays CHF 1,894 for 220 hours a month rather than CHF 6,200, and the break-even falls to around 566,000 requests. The required peak capacity stays the same.

Not included: the cluster underneath (Exoscale SKS Pro at CHF 0.054995 per hour, around CHF 40 a month, in detail in what Kubernetes really costs in Switzerland) and your own time.

Recompute the break-even for your profile. It moves a lot with prompt caching, a smaller model, or a different input-output ratio. If you know your request profile, we will work it through together, with your numbers rather than our assumptions.

GPU scheduling on Kubernetes: DRA rather than device plugins

Dynamic Resource Allocation replaces the counting approach of “give me a GPU” with a requirement expressed over properties. The core of DRA has been GA since Kubernetes v1.34, with the API group resource.k8s.io/v1; the concept page in the docs now lists DRA as Kubernetes v1.35 [stable].

The old device plugin only knew nvidia.com/gpu: 4. Which four cards the scheduler picked was of no concern to it. With a 70B model using tensor parallelism that is not a detail: four 24 GB cards are not the same as four 96 GB cards, and the pod only dies when the weights load.

With DRA you express the requirement as a CEL expression against the attributes the driver publishes:

# Four GPUs of at least 80 GiB each, exclusively for one vLLM pod.
# Requires the DRA driver for NVIDIA GPUs (DeviceClass gpu.nvidia.com).
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: apertus-70b-gpus
  namespace: inference
spec:
  spec:
    devices:
      requests:
        - name: gpu
          exactly:
            deviceClassName: gpu.nvidia.com
            allocationMode: ExactCount
            count: 4
            selectors:
              - cel:
                  expression: |
                    device.capacity['gpu.nvidia.com'].memory.isGreaterThan(quantity('80Gi'))

The pod references the template instead of asking for a number:

spec:
  resourceClaims:
    - name: gpu
      resourceClaimTemplateName: apertus-70b-gpus
  containers:
    - name: vllm
      image: vllm/vllm-openai:v0.27.1
      resources:
        claims:
          - name: gpu

The practical difference: a wrongly sized node fails at scheduling, not after an eight-minute model download. The DRA driver for NVIDIA GPUs publishes productName, architecture and cudaComputeCapability, among others, for this purpose.

Inference serving: what belongs between model and application

vLLM is the model server, not the platform. It does continuous batching, PagedAttention and an OpenAI-compatible endpoint. What it does not do: decide which of eight replicas gets a request.

A deployment fragment for Apertus. The tool parser and chat template come from the model card; the context window is halved, because otherwise the KV cache fills the GPU memory:

containers:
  - name: vllm
    image: vllm/vllm-openai:v0.27.1
    args:
      - --model=swiss-ai/Apertus-v1.5-70B
      - --served-model-name=apertus-70b
      - --tensor-parallel-size=4
      - --max-model-len=131072
      - --gpu-memory-utilization=0.90
      - --chat-template-content-format=string
      - --enable-auto-tool-choice
      - --tool-call-parser=apertus
    ports:
      - containerPort: 8000
    readinessProbe:
      httpGet: { path: /health, port: 8000 }

Routing belongs a layer higher. The Gateway API Inference Extension (v1.6.0 of 17 August 2026) brings the InferencePool and an endpoint picker that evaluates queue depth and KV cache utilisation. A round-robin load balancer, by contrast, hits a replica whose cache does not hold the prefix and pays for the prefill twice.

apiVersion: inference.networking.k8s.io/v1
kind: InferencePool
metadata:
  name: apertus-70b
spec:
  selector:
    matchLabels: { app: apertus-70b }
  targetPorts:
    - number: 8000
  endpointPickerRef:
    name: apertus-70b-epp
    port: { number: 9002 }
    failureMode: FailOpen

llm-d (v0.9.0 of 17 August 2026) combines both into disaggregated serving, i.e. prefill and decode on separate pods. For most installations of this size that is a size too big.

Where sovereignty actually breaks

The model is rarely the problem. The breaking points sit in the periphery that nobody perceives as an AI component and therefore nobody checks.

Monitoring SaaS is the most common breaking point. An OpenTelemetry trace around an LLM call carries attributes such as gen_ai.input.messages and gen_ai.output.messages, i.e. the full content of the conversation. Pointing the collector at a US provider exports the prompt, not just the latencies. That is not a misconfiguration but the default behaviour of common instrumentation. The data protection consequences hanging off it are in A revDSG-compliant AI architecture.

The vector database stores the cleartext alongside. Every RAG implementation puts the source text chunk as payload next to the vector, otherwise it cannot place it in the prompt. A managed vector database with region Ireland is therefore a copy of your document corpus outside Switzerland.

Support access is in the contract, not in the architecture diagram. Whether a provider delivers second-level support from a third country, and whether that team has read access to production systems, is a question for procurement. It is rarely asked.

The CDN sees every request before it reaches the origin. Putting a US CDN in front of the inference endpoint means the prompt is in cleartext at a provider subject to CLOUD Act access.

Then the quieter ones: the embedding service, often a different provider from the LLM service, and the object storage for model weights, whose bucket region nobody checks any more. Auditing these points does more for sovereignty than the choice of model. The same discipline was required for the distributed platform we built for onocoy.

When sovereign inference is the wrong answer

For the majority of the use cases we see, running your own GPUs is the more expensive and slower solution. Below roughly a million requests a month you pay a premium for sovereignty with no technical return.

An API provider with a clean processor agreement, a documented data location and a commitment on model training generally covers the revDSG requirements for business data. Infomaniak, for example, processes in Geneva and Zurich. That is in production in days, not weeks.

Self-operation earns its keep when one of these applies: volume is durably above the break-even; the data falls under professional secrecy under Art. 321 of the Swiss Criminal Code; or you need a pinned model version because a validation depends on it.

What we advise against: the halfway solution with your own cluster but monitoring, vector database and CDN at a US provider. That costs the full operational effort and still does not deliver sovereignty.

The decision matrix

Criterion	API purchase	Dedicated GPU in Switzerland	On-prem or colocation
Request volume	up to around 1 m per month	from around 3 m per month, predictable	durably high, over a 3-year horizon
Data class	business data without special categories	sensitive personal data (Art. 5 lit. c revDSG)	professional secrecy (Art. 321 SCC), export-restricted data
Model control	provider decides version and deprecation	you pin version and quantisation	plus driver and kernel
Latency control	none, batching sits with the provider	batch size, KV cache, prefix routing	plus the network path
Operational effort	API key and an invoice	cluster, DRA driver, vLLM, gateway, capacity planning	plus hardware lifecycle
Time to production	hours	days to weeks	months

The rows are not equally weighted. Almost always the second decides it: which class of data flows through the prompt. The rest is a question of cost after that.

Frequently asked

What Swiss alternatives to ChatGPT are there?

Apertus is the open Swiss language model from EPFL, ETH Zurich and CSCS, available in version 1.5 since 24 July 2026. It can be obtained through Infomaniak AI Services, the Swisscom Swiss AI Platform, Phoenix Technologies, or from Hugging Face for self-operation. Alongside it, Swiss providers run endpoints for open models from Mistral, Qwen and Google.

What does a self-hosted LLM cost compared with the API?

By our model calculation of 19 August 2026, four RTX Pro 6000 at Exoscale running continuously cost CHF 6,200 a month. The same load through the Infomaniak API costs CHF 0.00335 per request at 3,000 input and 500 output tokens. The arithmetic break-even is 1.85 million requests a month; with headroom for peaks and failures, closer to three to four million.

What hardware do I need for my own LLM?

For Apertus-v1.5-70B the model card gives four GPUs at the full context window: 72 billion parameters in BF16 are 144 GB of weights alone, plus the KV cache. The 8B model runs comfortably on one 48 GB card. Quantisation lowers the requirement but costs quality and has to be measured for the specific use case.

Does Swiss hosting protect against the US CLOUD Act?

Only if the operator is not subject to US law. 18 U.S.C. § 2713 obliges US providers to hand over data regardless of where it is stored. What decides is therefore the provider’s corporate structure, not the address of the data centre. A data centre in Zurich operated by a Swiss subsidiary of a US group remains within reach.

Let’s discuss the inference architecture. Thirty minutes with one of our engineers on your concrete case: which model, what volume, where the data sits, and where the periphery leaves the jurisdiction. No sales pitch, no preparation needed.

A slot is available here. If you would rather write first, you can reach us through contact. What we work on is under AI and machine learning and Kubernetes and infrastructure.

The agents nobody approved

Robert Pupel — Sat, 22 Aug 2026 00:00:00 GMT

Anyone who has not settled which agents may run with which rights on which code has still made that decision, just unconsciously. Agent platforms such as OpenClaw run on a developer’s own machine, need no procurement, and appear in no inventory. Agent governance therefore has three parts: an allowlist, graded permission classes, and a form of detection that does not require suspecting anyone.

The typical trigger is a subordinate clause in a daily standup. Someone mentions that the agent did the refactoring overnight, kicked off over Telegram, from a personal MacBook. And at that point the question is no longer whether such a thing is in use, but since when.

A repository with 386,890 stars that never went through procurement

On 20 August 2026 OpenClaw stands at 386,890 GitHub stars, making it the sixth most-starred repository there is, well ahead of React at 247,443 (GitHub API, retrieved 20 August 2026). That is not a vendor claim but the platform’s own counter.

What sits behind it: an open agent platform by Peter Steinberger that runs on your own machine and is operated through ordinary chat apps — WhatsApp, Telegram, Discord, Slack, Teams. The project puts it itself as “Your assistant. Your machine. Your rules.” No SaaS, therefore no contract, no invoice, no procurement process a CTO ever sees.

For inventory purposes the naming history matters too. The weekend project “WhatsApp Relay” from November 2025 became “Clawd”, then “Moltbot”, and since 29 January 2026 it has been OpenClaw. Anyone maintaining a list of permitted tools and searching for the old name finds nothing.

What rights an agent like this actually has

OpenClaw can read files, execute commands, install plugins and open network connections, and the project itself says the decisive sentence about it: “It is not a sandbox.” The security documentation describes boundaries instead — path protection, a proxy — but concedes that a plugin with shell rights can still do anything shell rights permit.

That openness is more honest than the marketing of most commercial tools. But it describes precisely the class of software that should not run unattended on a machine holding client code.

That the permission system can break is documented. CVE-2026-33579 describes a privilege escalation with CVSS v4.0 9.4 and CVSS v3.1 9.9, rated CRITICAL by the CNA VulnCheck, CWE-863, published 31 March 2026. All versions before 2026.3.28 are affected: a caller with pairing but not admin rights could approve device requests carrying elevated rights including admin, because the scope check was missing from the approval path.

If you cannot say right now which agents run on your development machines and with which rights: taking exactly that inventory is half a day with your team, with no tool recommendation at the end. Write to us through contact.

What local operation triggers under the revised Swiss DPA

An agent that sends repository contents to a model is, in data protection terms, a disclosure — and usually one abroad. Where the code contains personal data, for instance in fixtures, logs or migration scripts, Art. 16 and Art. 9 of the revised DPA apply.

Art. 9 para. 3 is particularly awkward: a processor may transfer processing “to a third party only with the prior authorisation of the controller”. A self-installed agent that reaches an additional model provider creates exactly that unauthorised third party, and nobody in the company knows about it.

The sanction lands on people, not departments. Art. 61 of the revised DPA provides for fines up to CHF 250,000 against private persons, on application, in cases of intent. Covered are, among other things, disclosure abroad without the conditions of Art. 17, and handover to a processor without the conditions of Art. 9 paras. 1 and 2.

How that translates into architecture we set out provision by provision in A revDSG-compliant AI architecture.

Three permission classes rather than one approval

A binary approval fails, because “permitted” means something different for an autocomplete than for an agent that commits at night. So we work with three classes, and the class follows from the access rather than from the product name.

Class	Visible code	Execution	Network	Approved by	Typical case
A Assistance	open workspace, no secrets	none	model providers on the allowlist	team lead	autocomplete, chat in the editor
B Delegated	one repository, secrets through a vault	yes, in a container or VM, result as a pull request	allowlist plus approved MCP servers	tech lead plus data protection officer	coding agent on assignment
C Autonomous	several repositories, close to production	yes, outside working hours, unobserved	any outbound connection possible	executive, time-limited, with a record	general-purpose agent over a chat app

The line that matters lies between B and C. Anything falling in class C belongs on a dedicated machine with its own operating system account, not on the laptop that will open a client project tomorrow. OpenClaw’s documentation itself recommends separating trust boundaries on shared hosts, with separate OS users or separate hosts.

For class B the frame can be captured in configuration. OpenClaw has a restrictive baseline that works as a starting point: gateway on loopback only, execution denied by default.

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "<long-random-token>" },
  },
  tools: {
    deny: ["group:automation", "group:runtime", "gateway", "cron"],
    exec: { security: "deny", ask: "always" },
  },
  agents: {
    defaults: {
      sandbox: { mode: "all", scope: "agent" },
      workspaceAccess: "ro",
    },
  },
}

The file itself belongs locked down: ~/.openclaw at 700 and ~/.openclaw/openclaw.json at 600. The project ships a check that also finds configuration drift:

openclaw security audit --deep
openclaw security audit --fix

How to detect use without hunting anyone

Detection here means inventory, not surveillance: you ask the machine, not the colleague. Three signals are enough for a first pass, and all three fit into an onboarding script or an MDM check.

# 1. Globally installed agent packages
npm ls -g --depth=0 2>/dev/null | grep -Ei 'openclaw|opencode|codex|claude-code'

# 2. Configuration directories of long-running agents
ls -ld ~/.openclaw ~/.claude ~/.codex 2>/dev/null

# 3. The OpenClaw gateway listens by default on 127.0.0.1:18789
lsof -nP -iTCP:18789 -sTCP:LISTEN 2>/dev/null

The second part concerns not the machines but the repositories. An agent sees whatever the working directory offers, and that is regularly more than assumed:

git ls-files | wc -l
git grep -nIE '(api[_-]?key|secret|BEGIN [A-Z ]*PRIVATE KEY)' -- ':!*_test*' | head

If that second query finds something, the agent question is secondary. You have a secret management problem that affects every clone of the repository.

Tool lock-in is the second, quieter risk

Thinking about governance only as a security question misses the consolidation happening in the market. Windsurf no longer exists as its own brand: on 20 August 2026 windsurf.com answers with HTTP 308 to devin.ai/desktop, checked with a simple redirect test. Cursor has been building its own code hosting with “Origin” since 17 August 2026, complete with repositories and pull requests, in open beta for all paid plans according to the changelog, with an opt-out for enterprise administrators.

Usage shares are moving at the same pace. The JetBrains Developer Ecosystem Survey 2026 with over 15,000 respondents, collected between May and July 2026, measures a redistribution within a few months. To note: JetBrains operates in the same market and is therefore not a neutral surveyor.

Tool	Before	Survey May–July 2026
Claude Code	18 %	39 %
GitHub Copilot	29 %	21 %
Codex	3 %	16 %
Cursor	18 %	12 %

A tool that sheds or doubles a third of its user base within two quarters is not a platform decision but a snapshot. What binds you should therefore not be the tool but whatever survives switching it.

Three things are portable today: the Model Context Protocol in the specification version of 28 July 2026; the AGENTS.md format, which according to agents.md over 60,000 open-source projects use and which is maintained under the Linux Foundation; and A2A in version 1.0, also handed to the Linux Foundation.

Putting your project conventions there rather than in tool-specific settings means changing tools without a migration project. What building your own MCP server looks like we described in Running MCP servers in Go in production.

The MCP specification is notably clear on security: tool descriptions and annotations are to be treated as untrusted unless they come from a trusted server. At the same time it records that the protocol cannot enforce those principles. Enforcement lies with the host, which is to say with you.

What belongs in the policy, and what we advise against

An agent policy fits on two pages. It only gets read at greater length when an audit is due.

An allowlist with versions, not only product names. OpenClaw has run an extended-stable channel since 30 July 2026, the first such release being 2026.6.33. What you approve is a channel, not “the tool”.
A permission class per deployment, per the table above, documented with one sentence of reasoning.
Named outbound destinations. Which model providers, which MCP servers. GitHub introduced MCP allowlists in enterprise settings on 6 August 2026; that is the right lever.
Personal subscriptions are not corporate access. Not because the tool would not work, but because the contract is a different one: Free, Pro and Max run under consumer terms where training use hangs off a personal account setting the employer neither sees nor controls. Anthropic describes this explicitly for using Claude Code from such accounts. Which plans and purchasing routes exist instead is in Using coding agents in line with data protection law.
A reporting route with no consequence. Someone reporting a previously unapproved agent gets a class assigned, not a reprimand.

What we advise against: a ban. A ban produces better-hidden shadow IT and costs you exactly the information you need.

We equally advise against letting the agent sign off its own work. Review, tests and the merge gate stay outside the agent, otherwise the system checks itself. Why that matters architecturally is in AI writes the code. Who writes the architecture?

When our recommendation does not fit: in a two-person team with a single repository and no personal data, the permission class matrix is overhead. There a maintained list in the README suffices, plus the rule that no agent executes commands outside a container.

Frequently asked

Is OpenClaw fundamentally unsuitable for companies?

No. OpenClaw is a technically impressive project with open security communication that names its own limits. What is unsuitable is the operating model on a work machine holding client code: local, broadly permissioned, driven through consumer chat apps. On a dedicated machine with its own OS account, loopback binding and a restrictive tool policy, sanctioned use is possible.

How do I tell whether an agent has sent personal data to a model?

From the outbound traffic and the agent session, not from the repository. The workable route is the reverse: check which directories the agent was allowed to read, and treat everything in them as disclosed. That is why class B specifies workspaceAccess: "ro" and a single repository. Less visibility is what makes the data protection assessment under Art. 16 revDSG tractable in the first place.

Is a container enough protection?

A container limits the damage, it does not prevent it. It protects the host’s file system and separates agents from one another, but changes nothing about which data the agent sees inside the container and where it sends them. Container plus a tight tool policy plus named outbound destinations work together. Individually, none of the three works.

What do we do with an agent that has been running unnoticed for months?

Inventory first, classify second, decide third. Check the version, particularly against CVE-2026-33579 and the 2026.3.28 boundary; record the rights and the scope of access; rotate the secrets that were within its reach. Only then ask whether it keeps running or gets switched off. Switching it off immediately destroys the information about what the agent actually did.

The next step

Take 30 minutes with one of our engineers, no sales pitch: we go through your tool list, assign each entry a permission class, and name the places where revised DPA obligations are engaged. Book a slot or write informally through contact; both reach the same person.

If it turns into more than a policy — an agent that should run cleanly bounded inside your environment, say — that is our day job under Artificial Intelligence & Machine Learning.

Running MCP servers in Go in production

Ralph Segi — Fri, 21 Aug 2026 00:00:00 GMT

An MCP server following the specification of 28 July 2026 holds no session state. The revision removes the initialize handshake and the Mcp-Session-Id header: every request carries the protocol version and client identity itself, in _meta. For a production server in Go that means three things: round-robin behind an ordinary load balancer, state in server-issued handles, identity in an OAuth token per call.

The primary source is the changelog for revision 2026-07-28. All the code examples below are written against the official Go SDK v1.7.0, which went stable the same day.

What the specification of 28 July 2026 changes

Revision 2026-07-28 turns MCP from a bidirectional, stateful protocol into a request/response protocol. The changelog lists nine points as “major changes”, and six of them force work on an existing server.

Before (2025-11-25)	After (2026-07-28)	What you have to change
`initialize` handshake, `Mcp-Session-Id` header	every request self-describing through `_meta`; new mandatory RPC `server/discover`	turn off sticky sessions at the load balancer, remove process-local session storage
server-initiated requests (`roots/list`, `sampling/createMessage`, `elicitation/create`) over a held stream	multi round-trip requests: the server answers with `resultType: "input_required"`, the client repeats with `inputResponses`	encode intermediate state in `requestState` rather than holding it in the process
routing by inspecting the JSON body	mandatory `Mcp-Method` header on every streamable HTTP POST, `Mcp-Name` additionally on `tools/call`, `resources/read` and `prompts/get`	switch gateway rules to headers, otherwise `HeaderMismatchError` (`-32020`)
list results without a cache hint	`ttlMs` and `cacheScope` are mandatory fields on `tools/list`, `prompts/list`, `resources/list`, `resources/read` and `resources/templates/list`	set the values deliberately; for user-dependent tool lists, `cacheScope: "private"`
roots, sampling and logging active	all three deprecated (SEP-2577), still functional	log to `stderr` or through OpenTelemetry, replace sampling with a direct call to the provider API
Dynamic Client Registration (RFC 7591) as the standard route	deprecated in favour of Client ID Metadata Documents	support CIMD, keep DCR only as a fallback

For planning purposes the governance part matters: the specification now has a feature lifecycle and deprecation policy with a minimum window of twelve months. Anyone using roots, sampling or logging does not have to rebuild this week. Anyone building new does not touch them at all.

A common misunderstanding concerns tasks: they have not moved into the core but out of the experimental core into the io.modelcontextprotocol/tasks extension. MCP Apps (io.modelcontextprotocol/ui) and enterprise-managed authorization also sit outside the core, but were never in it: both have been extensions from the start. Extensions are opt-in and negotiated through the extensions field.

Why an MCP server gets built in Go

Go is the language the agent infrastructure is already written in: Kubernetes controllers, inference gateways, agentgateway, kagent. Why we build critical backends in Go generally is in a separate article on Go for long-lived systems, and the rest of this text does not repeat it.

One point is new for MCP. A tool server is a short-lived process that restarts often, runs in many instances, and is occasionally deployed separately per tenant. A static binary in a FROM scratch image is a different starting position for that than an interpreter with a package tree.

The Go SDK requires at least Go 1.25.0 in its go.mod. As a base, Go 1.26 at patch level 1.26.6 of 13 August 2026 is a sensible choice.

Stateless means the state gets a name

A production MCP server holds no session state in the process. State belongs in external storage and is addressed through a server-issued handle that travels back and forth as an ordinary tool argument. That is how SEP-2567 describes it.

The gain: the second call may land on a different instance, a deployment in the middle of an agent session destroys nothing, and the load balancer needs no stickiness. In the Go SDK it is one field, StreamableHTTPOptions.Stateless.

The four examples in this article are complete programs: copy them, go get github.com/modelcontextprotocol/go-sdk@v1.7.0, go run .

// Complete program. go get github.com/modelcontextprotocol/go-sdk@v1.7.0
package main

import (
	"context"
	"encoding/json"
	"fmt"
	"log"
	"net/http"
	"sync"
	"time"

	"github.com/modelcontextprotocol/go-sdk/mcp"
)

// Store is the external state store. In production: Redis, Valkey, Postgres.
// Just not the process, because the next call lands on a different instance.
type Store interface {
	Put(ctx context.Context, handle string, v any, ttl time.Duration) error
	Get(ctx context.Context, handle string, v any) error
}

// memStore is the throwaway variant, so this example runs without Redis.
type memStore struct{ m sync.Map }

func (s *memStore) Put(_ context.Context, h string, v any, _ time.Duration) error {
	b, err := json.Marshal(v)
	if err != nil {
		return err
	}
	s.m.Store(h, b)
	return nil
}

func (s *memStore) Get(_ context.Context, h string, v any) error {
	b, ok := s.m.Load(h)
	if !ok {
		return fmt.Errorf("handle %q unknown or expired", h)
	}
	return json.Unmarshal(b.([]byte), v)
}

type exportState struct {
	UserID string   `json:"user_id"`
	Rows   []string `json:"rows"`
}

type startIn struct {
	Tenant string `json:"tenant" jsonschema:"Tenant code, three uppercase letters"`
}

type startOut struct {
	Handle string `json:"handle" jsonschema:"Opaque handle, pass back unchanged to export_page"`
	Total  int    `json:"total" jsonschema:"Number of rows in the export"`
}

type pageIn struct {
	Handle string `json:"handle" jsonschema:"Handle from export_start"`
}

func addExport(s *mcp.Server, store Store) {
	mcp.AddTool(s, &mcp.Tool{
		Name:        "export_start",
		Description: "Starts a bookings export and returns a handle. Fetches no data itself.",
	}, func(ctx context.Context, req *mcp.CallToolRequest, in startIn) (*mcp.CallToolResult, startOut, error) {
		rows := []string{"B-1", "B-2", "B-3"}
		handle := fmt.Sprintf("exp_%s_%d", in.Tenant, time.Now().UnixNano())
		st := exportState{UserID: userID(req), Rows: rows}
		if err := store.Put(ctx, handle, st, 15*time.Minute); err != nil {
			return nil, startOut{}, fmt.Errorf("could not store the handle: %w", err)
		}
		return nil, startOut{Handle: handle, Total: len(rows)}, nil
	})

	mcp.AddTool(s, &mcp.Tool{
		Name:        "export_page",
		Description: "Returns the rows of an export begun with export_start.",
	}, func(ctx context.Context, req *mcp.CallToolRequest, in pageIn) (*mcp.CallToolResult, any, error) {
		var st exportState
		if err := store.Get(ctx, in.Handle, &st); err != nil {
			return nil, nil, fmt.Errorf("%w, please call export_start again", err)
		}
		// The handle belongs to the caller, or it is not served.
		if st.UserID != userID(req) {
			return nil, nil, fmt.Errorf("handle %q belongs to a different identity", in.Handle)
		}
		b, _ := json.Marshal(st.Rows)
		return &mcp.CallToolResult{Content: []mcp.Content{&mcp.TextContent{Text: string(b)}}}, nil, nil
	})
}

// userID returns the identity from the bearer token, see the authentication section.
func userID(req *mcp.CallToolRequest) string {
	if req.Extra != nil && req.Extra.TokenInfo != nil {
		return req.Extra.TokenInfo.UserID
	}
	return ""
}

func main() {
	store := &memStore{} // one instance, outside the request path

	handler := mcp.NewStreamableHTTPHandler(func(r *http.Request) *mcp.Server {
		s := mcp.NewServer(&mcp.Implementation{Name: "erp-bridge", Version: "1.4.0"}, nil)
		addExport(s, store)
		return s
	}, &mcp.StreamableHTTPOptions{
		// No Mcp-Session-Id, no held connection, no process memory.
		Stateless:    true,
		JSONResponse: true,
	})

	log.Fatal((&http.Server{
		Addr:              ":8080",
		Handler:           handler,
		ReadHeaderTimeout: 5 * time.Second,
	}).ListenAndServe())
}

The handle gets a TTL and an owner. Without a TTL the store grows without bound; without the ownership check in export_page, a second user can redeem somebody else’s handle. Both are two lines, and both are missing from most example projects.

Authentication: how a tool call is bound to a user identity

A tool call is bound to an identity through an OAuth 2.1 access token whose aud claim contains the canonical URI of exactly this MCP server. The specification is unusually clear here: MCP servers must verify that a token was issued with them as the audience, and they must not accept or pass on any other tokens.

This is the section the example projects leave out. A prototype runs with a shared bearer token in an environment variable, and every tool call reaches the database under the same service account. At that point the log can no longer establish which human triggered what.

There is also an obligation that is not new but regularly missing: the server must serve OAuth 2.0 Protected Resource Metadata under RFC 9728, otherwise no client finds the responsible authorization server. That has been in the spec since revision 2025-06-18.

// Complete program. go get github.com/modelcontextprotocol/go-sdk@v1.7.0 github.com/golang-jwt/jwt/v5
package main

import (
	"context"
	"fmt"
	"log"
	"net/http"
	"slices"
	"strings"

	"github.com/golang-jwt/jwt/v5"
	"github.com/modelcontextprotocol/go-sdk/auth"
	"github.com/modelcontextprotocol/go-sdk/mcp"
	"github.com/modelcontextprotocol/go-sdk/oauthex"
)

const (
	// canonicalURI is the resource indicator under RFC 8707. Exactly this value
	// must appear in the aud claim, otherwise the token was for another service.
	canonicalURI = "https://mcp.example.ch/mcp"
	issuer       = "https://login.example.ch/realms/erp"
)

// claims extends the standard claims with scope, as Keycloak and Entra ID deliver it.
type claims struct {
	Scope string `json:"scope"`
	jwt.RegisteredClaims
}

func verifyToken(parser *jwt.Parser, keyFunc jwt.Keyfunc) auth.TokenVerifier {
	return func(ctx context.Context, raw string, _ *http.Request) (*auth.TokenInfo, error) {
		var c claims
		if _, err := parser.ParseWithClaims(raw, &c, keyFunc); err != nil {
			return nil, fmt.Errorf("%w: %v", auth.ErrInvalidToken, err)
		}
		if c.Issuer != issuer {
			return nil, fmt.Errorf("%w: unexpected issuer %q", auth.ErrInvalidToken, c.Issuer)
		}
		if !slices.Contains(c.Audience, canonicalURI) {
			return nil, fmt.Errorf("%w: token not issued for %s", auth.ErrInvalidToken, canonicalURI)
		}
		if c.Subject == "" {
			return nil, fmt.Errorf("%w: no sub claim, no identity", auth.ErrInvalidToken)
		}
		return &auth.TokenInfo{
			UserID:     c.Subject,
			Scopes:     strings.Fields(c.Scope),
			Expiration: c.ExpiresAt.Time,
		}, nil
	}
}

type bookingIn struct {
	Account string `json:"account" jsonschema:"Account number under the Swiss SME chart of accounts"`
	Rappen  int    `json:"amount_rappen" jsonschema:"Amount in rappen, integer"`
	IdemKey string `json:"idempotency_key" jsonschema:"UUID generated by the caller. The same key never books twice."`
}

func book(ctx context.Context, req *mcp.CallToolRequest, in bookingIn) (*mcp.CallToolResult, any, error) {
	tok := req.Extra.TokenInfo
	if tok == nil {
		return nil, nil, fmt.Errorf("call without identity")
	}
	if !slices.Contains(tok.Scopes, "accounting:write") {
		return nil, nil, fmt.Errorf("scope accounting:write missing")
	}
	// From here every query runs under tok.UserID, not under a service account.
	log.Printf("booking user=%s account=%s rappen=%d idem=%s", tok.UserID, in.Account, in.Rappen, in.IdemKey)
	return &mcp.CallToolResult{Content: []mcp.Content{&mcp.TextContent{Text: "booked"}}}, nil, nil
}

func main() {
	server := mcp.NewServer(&mcp.Implementation{Name: "erp-bridge", Version: "1.4.0"}, nil)
	mcp.AddTool(server, &mcp.Tool{
		Name:        "booking_create",
		Description: "Records a booking. Writes. The same idempotency key never creates a second booking.",
		Annotations: &mcp.ToolAnnotations{IdempotentHint: true},
	}, book)

	mcpHandler := mcp.NewStreamableHTTPHandler(
		func(*http.Request) *mcp.Server { return server },
		&mcp.StreamableHTTPOptions{Stateless: true},
	)

	var keyFunc jwt.Keyfunc // from the issuer's JWKS, cached
	requireToken := auth.RequireBearerToken(
		verifyToken(jwt.NewParser(jwt.WithValidMethods([]string{"RS256", "ES256"})), keyFunc),
		&auth.RequireBearerTokenOptions{
			Scopes:              []string{"accounting:read"},
			ResourceMetadataURL: "https://mcp.example.ch/.well-known/oauth-protected-resource",
		},
	)

	mux := http.NewServeMux()
	mux.Handle("/mcp", requireToken(mcpHandler))
	// RFC 9728. The specification makes this document mandatory: without it
	// no client finds the responsible authorization server.
	mux.Handle("/.well-known/oauth-protected-resource", auth.ProtectedResourceMetadataHandler(
		&oauthex.ProtectedResourceMetadata{
			Resource:             canonicalURI,
			AuthorizationServers: []string{issuer},
			ScopesSupported:      []string{"accounting:read", "accounting:write"},
		}))

	log.Fatal(http.ListenAndServe(":8080", mux))
}

The decisive point is in a single line: tok.UserID comes from the sub claim and is available to every tool handler from then on. The agent thereby inherits exactly the rights of the signed-in human, not those of a service account.

In Switzerland that is not merely good style. Article 4 of the Data Protection Ordinance (DPO, SR 235.11), the implementing ordinance to the revised DPA, obliges private controllers to log as soon as they process sensitive personal data automatically on a large scale and preventive measures cannot ensure data protection. Paragraph 4 says what has to be in it: information about “the identity of the person who carried out the processing, the type, the date and the time of the processing”.

Paragraph 5 sets retention at a minimum of one year, separated from the processing system. A shared service account does not satisfy that technically. What the revised DPA demands of an agent system beyond that, provision by provision, is in A revDSG-compliant AI architecture.

This is exactly where most prototypes stop, and usually only when the security review arrives. If that is where you are: we will look at your chain from identity provider to tool handler together once and say where it breaks. Book a slot.

Tool design: the mistakes we see most often

The three most common tool design mistakes are too many tools, vague descriptions, and missing idempotency. All three only show up in operation, as wrongly chosen tools and duplicate bookings.

A description is the only context the model has when choosing. It belongs written with boundaries: what the tool does, what it does not do, and which other tool covers the adjacent case.

// Complete program, speaks streamable HTTP on :8080.
package main

import (
	"context"
	"fmt"
	"log"
	"net/http"

	"github.com/modelcontextprotocol/go-sdk/mcp"
)

type searchIn struct {
	CustomerNo string `json:"customer_no" jsonschema:"Customer number in the format K-00000, exactly as held in Abacus"`
	Year       int    `json:"year" jsonschema:"Financial year, four digits, between 2015 and 2030"`
}

type searchOut struct {
	Hits      []string `json:"hits" jsonschema:"Invoice numbers, newest first"`
	Total     int      `json:"total" jsonschema:"Total number of hits, even where the list is truncated"`
	Truncated bool     `json:"truncated" jsonschema:"true when truncated to 50 entries"`
}

func search(ctx context.Context, req *mcp.CallToolRequest, in searchIn) (*mcp.CallToolResult, searchOut, error) {
	if in.Year < 2015 || in.Year > 2030 {
		// Error text as an instruction, not a status code. The model reads it.
		return nil, searchOut{}, fmt.Errorf(
			"year %d is outside the maintained range 2015 to 2030, please call again with a year in that range", in.Year)
	}
	return nil, searchOut{Hits: []string{"RE-2026-0184"}, Total: 1}, nil
}

func main() {
	server := mcp.NewServer(&mcp.Implementation{Name: "erp-bridge", Version: "1.4.0"}, nil)

	mcp.AddTool(server, &mcp.Tool{
		Name: "invoices_search",
		Description: "Searches a customer's accounts receivable invoices in a financial year. " +
			"Returns at most 50 invoice numbers and changes nothing. " +
			"Do not use to load a known invoice number; invoice_read is for that.",
		Annotations: &mcp.ToolAnnotations{ReadOnlyHint: true, Title: "Search invoices"},
	}, search)

	handler := mcp.NewStreamableHTTPHandler(
		func(*http.Request) *mcp.Server { return server },
		&mcp.StreamableHTTPOptions{Stateless: true},
	)
	log.Fatal(http.ListenAndServe(":8080", handler))
}

You can call it with curl. Since 2026-07-28 a streamable HTTP POST needs three headers and two mandatory fields in _meta, otherwise the server answers with -32020 or -32602:

curl -sN -X POST http://localhost:8080/ \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'Mcp-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: tools/call' \
  -H 'Mcp-Name: invoices_search' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
        "name":"invoices_search",
        "arguments":{"customer_no":"K-00042","year":1999},
        "_meta":{
          "io.modelcontextprotocol/protocolVersion":"2026-07-28",
          "io.modelcontextprotocol/clientCapabilities":{},
          "io.modelcontextprotocol/clientInfo":{"name":"curl","version":"1"}}}}'

# event: message
# data: {"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text",
#   "text":"year 1999 is outside the maintained range 2015 to 2030,
#           please call again with a year in that range"}],
#   "isError":true,"resultType":"complete"}}

The error case comes back as isError: true with readable text, not as a JSON-RPC error. That is deliberate: a model can read a sentence and correct the call; a status code it can only guess at.

One detail that stands out when rebuilding this: the Go SDK sets cacheScope: "public" on tools/list by default. Anyone serving a user-dependent tool list has to set private themselves, otherwise a gateway may show one user’s list to the next.

For write tools the same logic applies as for a payments API: the caller sends a self-generated key, the server reserves it before processing, and a repeat returns the same answer without a second effect. How we build that is in our article on idempotency in payments APIs.

With agents, repetition is more frequent than with humans, because after a timeout a model simply calls again.

On quantity: twenty sharply drawn tools beat sixty overlapping ones. And since this revision tools/list is supposed to be deterministically sorted, which improves clients’ prompt cache hit rate.

Operations: timeouts, rate limits, and what belongs in the logs

A failed tool call is reconstructable when a single log line contains the tool name, identity, protocol version, duration and correlation ID. Revision 2026-07-28 documents the OpenTelemetry conventions for _meta for the first time: traceparent, tracestate and baggage travel inside the protocol.

// Complete program. Every tool call produces exactly one JSON log line.
package main

import (
	"context"
	"log"
	"log/slog"
	"net/http"
	"os"
	"time"

	"github.com/modelcontextprotocol/go-sdk/mcp"
)

// logToolCalls writes one line per tool call, from which a failure can be
// reconstructed without asking anyone.
func logToolCalls(logger *slog.Logger) mcp.Middleware {
	return func(next mcp.MethodHandler) mcp.MethodHandler {
		return func(ctx context.Context, method string, req mcp.Request) (mcp.Result, error) {
			call, ok := req.(*mcp.CallToolRequest)
			if !ok || method != "tools/call" {
				return next(ctx, method, req)
			}

			start := time.Now()
			res, err := next(ctx, method, req)

			attrs := []any{
				slog.String("tool", call.Params.Name),
				slog.String("protocol_version", call.ProtocolVersion()),
				slog.Duration("duration", time.Since(start)),
			}
			// traceparent travels in _meta under the 2026-07-28 specification.
			if tp, ok := call.Params.Meta["traceparent"].(string); ok {
				attrs = append(attrs, slog.String("traceparent", tp))
			}
			if extra := call.GetExtra(); extra != nil && extra.TokenInfo != nil {
				attrs = append(attrs, slog.String("user_id", extra.TokenInfo.UserID))
			}
			if err != nil {
				logger.Error("tool_call failed", append(attrs, slog.String("error", err.Error()))...)
			} else {
				logger.Info("tool_call", attrs...)
			}
			return res, err
		}
	}
}

func main() {
	logger := slog.New(slog.NewJSONHandler(os.Stderr, nil))

	server := mcp.NewServer(&mcp.Implementation{Name: "erp-bridge", Version: "1.4.0"}, nil)
	server.AddReceivingMiddleware(logToolCalls(logger))

	mcp.AddTool(server, &mcp.Tool{
		Name:        "ping",
		Description: "Answers with pong. Serves only to check the logging chain.",
		Annotations: &mcp.ToolAnnotations{ReadOnlyHint: true},
	}, func(ctx context.Context, req *mcp.CallToolRequest, _ struct{}) (*mcp.CallToolResult, any, error) {
		return &mcp.CallToolResult{Content: []mcp.Content{&mcp.TextContent{Text: "pong"}}}, nil, nil
	})

	handler := mcp.NewStreamableHTTPHandler(
		func(*http.Request) *mcp.Server { return server },
		&mcp.StreamableHTTPOptions{Stateless: true},
	)
	log.Fatal(http.ListenAndServe(":8080", handler))
}

Two operational values are better set explicitly before the first incident sets them for you. First, a timeout per tool rather than per server: a full-text search may take ten seconds, an account balance may not.

Second, a rate limit per identity rather than per IP. Behind an IP sits an entire company; behind an identity sits an agent that loops when something fails. What belongs on the dashboards and what does not is in three dashboards instead of thirty.

Is a pod the right unit for an agent?

One pod per agent is the obvious answer but not obviously the right one. Lin Sun of Solo.io asked the question on 14 July 2026 in the CNCF blog under exactly that title: Is a Pod the right deployment unit for an AI agent?

A pod of its own brings process isolation and, through the ServiceAccount, a Kubernetes identity, but it costs baseline load: an agent is active for seconds and then idle for a long time.

For an MCP server doing pure tool execution that is good news: it is an ordinary stateless service and does not need this discussion. It only becomes relevant once the server executes foreign code. Then the pod is the wrong boundary, and a real sandbox is required.

What we advise against

Do not build an MCP server when an ordinary HTTP API will do. MCP solves a discovery problem, not an integration problem: it describes tools so that a model can find and choose them at runtime without anyone hard-wiring the integration beforehand. If your application knows exactly which endpoint it wants to call, a POST /invoices/search is cheaper and simpler to operate.

The trade-off is real. MCP costs you an authorization server, an RFC 9728 document, maintained tool descriptions, and a protocol in motion. In return you get tools any MCP-capable client can discover without you building anything for it.

Our line: an MCP server earns its keep when more than one client needs the same tools, or when choosing the tools is itself part of the task. For the AI agent platform AIgent that applies.

For a single internal automation with three known calls it does not. We say so even when a project was budgeted differently.

And: do not start the deprecation migration while authentication is missing. Roots, sampling and logging have twelve months. A server without identity binding does not have a deadline, it has a problem.

Frequently asked

What is the Model Context Protocol?

The Model Context Protocol is an open protocol through which AI applications discover and call a server’s tools, resources and prompts at runtime. It builds on JSON-RPC and knows two transports: STDIO for local processes and streamable HTTP for network services. Since revision 2026-07-28 the protocol core is stateless, and every request describes itself.

How do I build an MCP server in Go?

With the official github.com/modelcontextprotocol/go-sdk, currently v1.7.0. A server is created with mcp.NewServer, tools are registered through the generic function mcp.AddTool, which derives the input and output schema from your Go types by reflection. For network operation add mcp.NewStreamableHTTPHandler; for local processes server.Run with mcp.StdioTransport.

How do I authenticate an AI agent’s tool calls?

Through OAuth 2.1 with the MCP server as resource server. The client obtains an access token whose aud claim names the server’s canonical URI and sends it as a bearer token in every HTTP request. The server verifies signature, issuer and audience and translates the sub claim into an identity under which the tool handlers work. A shared static token does not satisfy this.

Do I have to migrate my existing MCP server now?

Not immediately, but the direction is clear. Roots, sampling, logging, the HTTP+SSE transport and dynamic client registration are deprecated and continue to work for at least twelve months. The move to stateless, by contrast, is not a deprecation matter but a protocol change: sessions and Mcp-Session-Id are removed in 2026-07-28. Anyone building new builds stateless.

Let’s talk about your agent infrastructure. Thirty minutes with one of our Go engineers: which tools you actually want to expose, how identity is passed from login through to the tool handler, and whether MCP is the right answer for your case. No sales pitch, no preparation on your side.

Book a slot · Get in touch · More on AI and agent systems and backend engineering

Guardrails for coding agents: never its own reviewer

Ralph Segi — Thu, 20 Aug 2026 00:00:00 GMT

A coding agent must not sign off its own work. Verification belongs in an authority the agent does not control: deterministic gates in CI, and a human who reads the whole diff whenever existing code is touched. How deeply something is checked is decided by the task type, not by the agent’s confidence score.

Robert Pupel set out three rules we hold to in AI writes the code. Who writes the architecture? This article describes the mechanism underneath: which gates sit in the pipeline, what triggers them, and where a human cannot be replaced. Guardrails for coding agents are not a process document but code in the repository.

Three sources arriving independently at the same conclusion

Research, consulting and practice arrived from different directions at the same rule in 2026: an agent must not be its own reviewer.

The Thoughtworks Technology Radar Vol. 34 of April 2026 lists “Putting coding agents on a leash” as one of four themes. Their reasoning: because agents deliver better results, humans increasingly step out of the loop, and teams therefore start investing in harnesses. Thoughtworks is a consultancy that sells AI transformation projects, and declares the Radar itself to be practitioner opinion rather than empirical work.

Octomind, a test tooling vendor, removed self-verification from its own agent in August 2026. The sentence from the release that names the problem precisely: “a model that wants to be done has a way to look done: advance the checklist, mark tasks complete, close the plan.” An external plan manager has owned progress since then, and the agent has no access to that tool. This is a vendor’s account of itself, but one with a mechanism you can follow.

The third source is the most interesting, because it is countable.

What 932,791 agent-generated pull requests show

Since February 2026 there has been a defensible evidence base for statements about coding agents. The AIDev dataset (Li, Zhang, Hassan, arXiv:2602.09185) collects 932,791 agent-generated pull requests from 116,211 repositories belonging to 72,189 developers, produced by five agents: OpenAI Codex, Devin, GitHub Copilot, Cursor and Claude Code. Open, academic, with no declared vendor funding.

Building on it, Ferdous, Banik, Chowdhury and Shamim compared 7,191 agent-generated against 1,402 human pull requests from Python repositories and detected breaking changes through AST analysis (arXiv:2603.27524, submitted 29 March 2026). The result is counter-intuitive:

Context	Breaking change rate
Greenfield, agents	3.45 %
Greenfield, humans	7.40 %
Agents on refactoring	6.72 %
Agents on chore changes	9.35 %

On a green field, then, agents break compatibility less often than humans. The moment they touch existing code, the picture inverts. Precisely the opposite of what most teams instinctively guard against.

The confidence trap: why the self-assessment fails as a filter

A high confidence score from the agent says nothing about whether the pull request stays compatible. The same work by Ferdous et al. names this the “confidence trap”: pull requests with a high self-reported confidence score contain breaking changes regardless. The authors derive from it, in so many words, the need for stricter checking on maintenance work, “regardless of reported confidence score”.

That is the practically most important number of the year, because it destroys a widespread short circuit. Hanging merge gates on a self-assessment has made the agent its own reviewer, just with more steps.

If you are about to let an agent loose on an existing Go backend and are not sure which gates need to be in place: that is a 30-minute conversation, not a project. We look at the pipeline you have and say what is missing.

Review depth by task type, not by confidence

What the data implies is a matrix with two lanes. It replaces the question “how confident is the agent?” with the question “what does this pull request touch?”.

Task type	Evidenced rate	Automated gates	Human review
Greenfield, new files, no existing code touched	3.45 %	Build, tests, `govulncheck`, lint, coverage threshold	Read the interface and the data model, not every line
Refactoring of existing code	6.72 %	plus `gorelease` against the last tag, rendered manifest diff	Full diff, second pair of eyes
Chore, dependencies, build, configuration	9.35 %	plus lockfile diff, image digest pinning, manifest diff	Full diff, second pair of eyes
Processing of personal data touched	none	everything above	Mandatory, whatever the task type

The last row is not a finding from the data but Swiss law. Art. 7 DPA requires data protection by design from the planning stage, and Art. 2 DPO names traceability as one of four protection goals. A merge nobody has signed off by name does not satisfy that. What it means for the architecture is in A revDSG-compliant AI architecture.

What the two lanes look like in a CI pipeline

Assignment to a lane has to be deterministic and out of the agent’s reach. It must not depend on how the agent titled its pull request.

The commit type under Conventional Commits is a usable hint but not evidence: the agent writes the title. The hard criterion comes from the diff itself. Deleted lines mean existing code was touched.

# .github/workflows/agent-gate.yml
name: agent-gate
on: pull_request

jobs:
  lane:
    runs-on: ubuntu-latest
    outputs:
      lane: ${{ steps.choose.outputs.lane }}
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - id: choose
        env:
          # Never interpolate the title directly into `run`: script injection.
          TITLE: ${{ github.event.pull_request.title }}
          BASE: ${{ github.event.pull_request.base.sha }}
        run: |
          case "$TITLE" in
            feat:*|"feat("*) LANE=greenfield ;;
            *)               LANE=existing ;;
          esac
          CHANGED=$(git diff --numstat "$BASE"...HEAD | awk '$2 > 0' | wc -l)
          if [ "$CHANGED" -gt 0 ]; then LANE=existing; fi
          echo "lane=$LANE" >> "$GITHUB_OUTPUT"

Unknown lands in the strict lane. That is the whole trick: the default is strict, not lenient.

Two gates that actually bite in Go and Kubernetes work

The existing-code lane needs checks that make compatibility breaks mechanically visible rather than leaving them to a review.

In a Go module, gorelease from golang.org/x/exp/cmd/gorelease does that. It compares the public API of the checked-out state against a base version and exits non-zero on incompatible differences from major version 1 onwards. That makes the study’s AST finding exactly what the gate measures.

  api-contract:
    needs: lane
    if: needs.lane.outputs.lane == 'existing'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - uses: actions/setup-go@v7
        with:
          go-version-file: go.mod
      - run: go install golang.org/x/exp/cmd/gorelease@latest
      - run: gorelease -base=latest

On the Kubernetes side the equivalent is the rendered manifest diff. Do not compare the chart, compare the result: an agent that renames a value leaves a harmless line in the chart and a missing environment variable in the deployment.

# Renders base and PR state and compares the result, not the source.
helm template svc ./chart > /tmp/new.yaml
git worktree add /tmp/base "$BASE_SHA"
helm template svc /tmp/base/chart > /tmp/base.yaml
diff -u /tmp/base.yaml /tmp/new.yaml

What the pipeline cannot catch

Static analysis alone is not a security gate. Firouzi and Ghafari held 1,080 LLM-generated code samples against a human-validated reference (arXiv:2602.05868, 5 February 2026): only 65 % of Semgrep’s and 61 % of CodeQL’s findings matched the reference. In aggregate both tools looked plausible; per sample they diverged considerably.

The need is real. Peng, Wang and Zhu found across 3,700 snippets from the LLMSecEval benchmark that 68.8 % violated at least one security requirement, rising to 79.1 % for hard-coded credentials (arXiv:2607.12089). Ma et al. report average vulnerability rates above 56 % across eight models (arXiv:2607.23088, poster). The absolute figures are not comparable between these works; the direction is consistent across more than a dozen independent studies.

What measurably helps is downstream repair rather than better prompts: Sriram, Pradhan and Saha combined compiler diagnostics, CodeQL and symbolic execution and reduced CodeLlama 7B’s security defects in C code from 49 % to 19 % (arXiv:2607.21641). So a repair pass belongs in the pipeline; a free pass drawn from it does not.

Separate planning from execution

The plan has to exist before the code and be signed off by a human. Boris Tane describes this as the most-shared working pattern there is: “The separation of planning and execution is the single most important thing I do”, and following from it, “never let Claude write code until you’ve reviewed and approved a written plan” (boristane.com, February 2026).

That is the interface between the agent and your team. An approved plan can be checked; a finished 2,000-line diff cannot. Where the plan contains an architecture decision it belongs in the repository anyway, see Decisions you can still understand in two years.

A word on context files, because a lot of effort drains away here: Gloaguen, Mündler, Müller, Raychev and Vechev of ETH Zurich evaluated AGENTS.md files systematically (arXiv:2602.11988, revised 23 June 2026). Finding: context files do not generally improve the success rate, and they raise inference costs by more than 20 %. Instructions are followed; repository overviews buy nothing. So write conventions and pitfalls into them, not directory trees.

What we advise against

Do not build a merge gate that only knows true or false. A single green tick across all task types is either too expensive for greenfield work or too cheap for maintenance, and usually both.

Do not use a second agent as the sole reviewer. A review agent is useful for structuring a diff and flagging candidates. It is not a verifier, because it shares failure classes with the agent it is checking, and because the chain then ends in a self-report again.

And the honest trade-off: the lenient greenfield lane lets errors through. The 3.45 % is better than the human figure, but it is not zero. Adopting this grading is a deliberate decision to move review effort where it statistically buys more. For a team of two with a prototype the whole apparatus is not worth it. For a product with external API consumers and a cluster in production it is.

Frequently asked

Why should agents be checked more strictly on maintenance than on greenfield work?

Because that is what the data shows. In the comparative study by Ferdous et al. across 7,191 agent-generated pull requests, the breaking change rate was 3.45 % on greenfield work, 6.72 % on refactoring and 9.35 % on chore changes. Maintenance presupposes knowledge of existing contracts, which is often only partially present in the context window. Greenfield work defines the contracts itself.

Can I use the agent’s confidence score as a merge criterion?

No. The same study describes a “confidence trap”: pull requests with a high self-reported confidence score contain breaking changes regardless. The score is a self-report from the system whose work is meant to be checked. Use criteria the agent does not influence instead: was existing code changed, does the public API break, does the rendered manifest change.

Is a security scanner in the pipeline enough as a gate?

Not as the only gate. Firouzi and Ghafari found across 1,080 validated samples that only 65 % of Semgrep’s and 61 % of CodeQL’s findings matched the human-validated reference. Scanners belong in the pipeline and their findings are hints. More effective is a downstream repair pass that combines compiler diagnostics with static analysis and re-checks the result.

How do I classify pull requests when the agent writes the title?

By the diff, not the title. A pull request that deletes lines has touched existing code and belongs in the strict lane. git diff --numstat gives you that in one line. The commit type under Conventional Commits remains a useful hint for humans but does not work as a gate, because the subject of the check sets it.

A walk through your pipeline, not through your strategy. Thirty minutes with one of our Go engineers: which gates you have today, which task types currently run through unchecked, and how much of that can be retrofitted in a week. No sales pitch.

Book a slot · Get in touch · How we build AI systems and agent infrastructure is under Artificial Intelligence & Machine Learning.

Using coding agents in line with data protection law: the gap in the subscription

Ralph Segi — Wed, 19 Aug 2026 00:00:00 GMT

A developer working on company code with a personal Pro or Max subscription falls under Anthropic’s consumer terms, not the commercial ones. There, training use is an account setting, explicitly “including when you use Claude Code from these accounts”, and with the setting enabled the data is held for five years rather than thirty days.

This is not a scandal and not hidden small print. Anthropic documents the differences on a public data usage page, in more detail than most providers. The gap opens inside companies that never settled the difference between a consumer and a business plan. Using coding agents in line with data protection law therefore starts with the account, not with the tool.

How a personal subscription ends up on company code at all

Coding agents enter a company through the developer, not through procurement. Somebody tries Claude Code on their own project in the evening, likes it, types claude in the client repository the next morning, and is still signed in with the personal account. There is no installation dialogue that notices.

The second route is the expense claim. A team without a licence reimburses twenty dollars a month as an expense. The subscription is paid for, but contractually it remains a consumer agreement between Anthropic and a private individual. The employer is not a party to it.

Both routes are technically inconspicuous. /status in Claude Code shows the login method and the organisation, but nobody looks there as long as nothing is broken.

Is company code a data protection matter at all?

Company code becomes a data protection matter as soon as personal data appear in it, and that happens more often than assumed. Test fixtures with real names, a database dump for a migration, a log extract somebody pastes into the prompt: in those moments a coding agent is processing personal data.

On 24 September 2025 the Swiss Federal Data Protection Commissioner recorded in AI and data protection that “the Swiss Data Protection Act (DPA) is directly applicable to AI-supported data processing”. No special AI legislation is needed for obligations to apply. Which provisions engage individually, and who is liable for a breach, is in our article on a revDSG-compliant AI architecture.

Where no personal data are involved, two other bindings remain: the client’s trade secrets, and the confidentiality clause in the framework agreement. Whether a particular clause covers disclosure to an inference provider is a question of the individual case and belongs checked before the first prompt, not after.

What Anthropic commits to per plan

The commitments differ between consumer and business plans in three respects: training, retention and negotiability. All figures come from the data usage page and the pricing page, retrieved 20 August 2026.

Plan	Training on your code	Retention at Anthropic	List price (USD)
Free, Pro, Max	depends on an account setting, including Claude Code use from those accounts	5 years with the setting enabled, otherwise 30 days	Pro 17 annually, 20 monthly; Max from 100
Team	no training under commercial terms	30 days	20 per standard seat, 100 per premium seat, both annual
Enterprise	no training under commercial terms	30 days; zero data retention on request	20 per seat plus usage at API rates
API, Bedrock, Google Cloud, Microsoft Foundry	no training; the Development Partner Program is not available at all through Bedrock and Google Cloud	30 days; with Foundry “Hosted on Azure” prompts and completions stay in Azure	usage-based

Three details that regularly get misreported in procurement conversations:

Zero data retention is not included in the standard Enterprise plan. Anthropic writes that ZDR is available for qualified accounts and is enabled per organisation by the account team after an eligibility check. If you need ZDR, you negotiate it.
Transcripts shared through /feedback, /bug and /share are retained for five years, whatever the plan. Session transcripts uploaded voluntarily through the quality survey for up to six months.
Error reports are active only with Pro and Max login, from version 2.1.198 and only on a direct connection to the Claude API. That too is a consumer property that does not arise on a business plan.

What closing the gap costs

Moving from personal subscriptions to team seats costs a twelve-person team three dollars per head per month. A model calculation from the list prices: twelve annual Pro subscriptions cost 12 × 17 = 204 USD a month, twelve team standard seats 12 × 20 = 240 USD. Delta: 36 USD a month, 432 USD a year.

For heavy users the arithmetic is different and cheaper still. Someone on a Max subscription at 100 USD a month costs the same 100 USD as an annual team premium seat. At that usage profile the move is price-neutral.

The honest caveat: a standard seat is not a substitute for a Max subscription, the usage quotas differ. Anyone currently expensing Max needs a premium seat, not the cheapest one. Even so the order of magnitude holds, and it is why this gap is irritating: it costs almost nothing except the decision.

If you do not know which accounts your team works under today, that is an hour’s work, not a week’s. Thirty minutes with one of our engineers is enough to turn it into an inventory and an order of operations.

Three data flows that remain even on a business plan

A commercial plan governs training, not every data flow. Three of them remain and belong in the record of processing activities, because otherwise they appear in no contract review.

Local transcripts in the clear. Claude Code stores session transcripts under ~/.claude/projects/, by default for 30 days. The documentation is unambiguous: “Transcripts and history are not encrypted at rest. OS file permissions are the only protection.” If a tool reads a .env file, its contents end up in the .jsonl file. Controllable through cleanupPeriodDays, CLAUDE_CODE_SKIP_PROMPT_HISTORY and claude project purge.

The WebFetch domain check. Before every fetch, WebFetch sends the requested hostname to api.anthropic.com to check it against a blocklist. Only the hostname, not the full URL. This runs independently of the model provider, so also through Bedrock, and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC does not cover it. It can only be turned off through skipWebFetchPreflight.

Telemetry and error reports. Controllable through DISABLE_TELEMETRY, DISABLE_ERROR_REPORTING, DISABLE_FEEDBACK_COMMAND and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC. On Amazon Bedrock, Google Cloud, Microsoft Foundry and Claude Platform on AWS, metrics, error reports and /feedback are already off by default. Session surveys and the WebFetch check still run there.

Which purchasing route for which kind of code?

The purchasing route follows the contents of the repository, not the size of the company. So the question is not “which plan do we buy” but “what is in this repository and what from it ends up in the prompt”.

What is in the repository and in the prompt	Purchasing route	What else is needed
Own tooling, open-source contributions, no client data	Team seat	nothing beyond the internal policy
Client code under NDA, no personal data	Team or Enterprise	check the client’s confidentiality clause, document the egress
Personal data in fixtures, dumps or logs	Enterprise, negotiate ZDR	processor agreement under Art. 9 DPA, deletion policy for local transcripts
Sensitive personal data under Art. 5 lit. c DPA	Bedrock with customer-managed KMS keys, or Foundry “Hosted on Azure”	check whether a data protection impact assessment is required, no production data in the prompt
Guaranteed data residency or professional secrecy	own hosting, open models	see sovereign AI inference in Switzerland

Amazon Bedrock encrypts with AES-256 and allows customer-managed keys through AWS KMS; Google Cloud supports CMEK. With Microsoft Foundry and “Hosted on Azure”, prompts and completions stay in Azure, and only usage metadata and content flagged by security systems go to Anthropic. Which regions are concretely available is not stated on the data usage page and has to be checked with the respective cloud provider.

How to enforce compliant use technically

Login to a particular organisation can be enforced, and it is the only point on this whole list that works without discipline. forceLoginOrgUUID and forceLoginMethod belong in managed settings and are rolled out through your device management: on macOS to /Library/Application Support/ClaudeCode/managed-settings.json, on Linux to /etc/claude-code/managed-settings.json.

{
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": "550e8400-e29b-41d4-a716-446655440000",
  "cleanupPeriodDays": 7,
  "env": {
    "DISABLE_TELEMETRY": "1",
    "DISABLE_ERROR_REPORTING": "1",
    "DISABLE_FEEDBACK_COMMAND": "1"
  },
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Four limitations that Anthropic names itself in the authentication documentation and that you have to know before ticking the box: claude setup-token and /install-github-app enforce only forceLoginMethod, so they can create a token in a different organisation. Sessions through cloud providers are not blocked; you restrict those through IAM. ANTHROPIC_API_KEY and apiKeyHelper are blocked at startup, because organisational membership cannot be verified there. And if you additionally distribute server-managed settings, both keys have to appear in both places, because the sources do not merge.

The second half belongs in the repository rather than on the device, so that it is visible in code review. A .claude/settings.json with deny rules applies to everyone who checks the project out:

{
  "permissions": {
    "deny": [
      "Read(./deploy/*.key)",
      "Read(./fixtures/prod-*.sql)"
    ]
  }
}

And a check script that runs as an MDM check or during onboarding:

#!/usr/bin/env bash
# Checks whether the Claude Code policy is in force on this device.
# Exit 1 as soon as a requirement is missing.
set -euo pipefail

case "$(uname -s)" in
  Darwin) managed="/Library/Application Support/ClaudeCode/managed-settings.json" ;;
  *)      managed="/etc/claude-code/managed-settings.json" ;;
esac

fail=0
note() { printf '%-26s %s\n' "$1" "$2"; }

if [ -f "$managed" ]; then
  org=$(jq -r '.forceLoginOrgUUID // empty' "$managed")
  [ -n "$org" ] || { note "forceLoginOrgUUID" "missing"; fail=1; }
  days=$(jq -r '.cleanupPeriodDays // empty' "$managed")
else
  note "managed-settings.json" "not present"
  fail=1
fi

# Cleartext transcripts older than our own retention period
old=$(find "$HOME/.claude/projects" -name '*.jsonl' -mtime +"${days:-30}" 2>/dev/null | wc -l | tr -d ' ')
[ "$old" = "0" ] || { note "old transcripts" "$old files past retention"; fail=1; }

exit "$fail"

OpenAI Codex: same check, different names

At OpenAI the check runs along the same three questions; the labels differ. The business plan costs, according to the Codex pricing page, 20 USD per user per month on an annual plan and carries the commitment “No training on your business data by default”. Enterprise adds controls for retention and data residency, SCIM, external key management, role-based access control, and audit logs through the compliance API.

For companies wanting to avoid the data flow to OpenAI entirely: since release 0.148.0 the Codex CLI supports Amazon Bedrock Runtime as a built-in provider, including AWS profile and region. That gives Codex the same route as Claude Code — inference in your own AWS account rather than at the model provider.

The practical consequence is inconvenient: anyone running both tools in-house needs two reviews and two policy lines. A single paragraph saying “AI tools are permitted” does not cover it.

What belongs in the policy on Monday

Six lines are enough, and they take an hour to write. In order, because the order determines the effort:

Inventory. Who works with which tool under which account? /status answers that per device in seconds.
Expenses rule. Personal AI subscriptions are no longer reimbursed. That line closes the second route in.
Enforce login. forceLoginOrgUUID and forceLoginMethod through device management, with the four limitations above in mind.
Repository classification. One column in the repository inventory: does it contain personal data, yes or no? The purchasing route from the table follows from that.
Document the egress. api.anthropic.com belongs on the allowlist and in the record of processing activities — because of the WebFetch check, even when you run through Bedrock.
Settle the feedback path. Either set DISABLE_FEEDBACK_COMMAND, or record in the team that /feedback and /share hand code to a recipient who keeps it for five years.

The guardrails belong in the repository and in device management, not in a wiki, for the same reason we put them there in who writes the architecture: what is not in the tooling stops applying after three weeks.

What we advise against

A ban. Banning coding agents does not stop people using them, it stops people saying so. The result is exactly the case this article describes: personal account, unknown plan, no oversight. A paid team seat is the cheaper control.

Zero data retention as a reflex. ZDR is not included in the standard Enterprise plan, is enabled per organisation, and requires a negotiation with the account team. For repositories with no personal data, thirty days of retention plus a documented processor agreement solves the same problem without a procurement project.

skipWebFetchPreflight as a default. Turning the check off means fetching URLs without comparison against the blocklist, and for an agent pulling web content into its context that is not a good trade. The better route is the allowlist plus an entry in the record.

The trade-off we will name openly: Bedrock and Foundry buy data residency with operational effort. You manage regions, IAM roles and your own keys, you lose billing through a single seat price, and new model versions tend to reach you later. For a repository with health data that is right. For the internal admin tool it is effort without a return.

Frequently asked

May a developer with a personal Claude Pro subscription work on client code?

Contractually possible, operationally hard to defend. Consumer plans are subject to consumer terms, training use hangs off a personal account setting the employer neither sees nor controls, and with the setting enabled retention is five years. Whether data protection or confidentiality obligations are additionally breached in a given case depends on the repository and on the client contract.

Is a team plan enough, or do we need Enterprise?

For the training question, team is enough: under commercial terms Anthropic does not train on code or prompts, and retention is thirty days. You need Enterprise for SSO, role-based permissions, the compliance API, and managed policy settings for organisation-wide configuration. Zero data retention is only available that way, and even there only after an eligibility check.

How do we get zero data retention?

Through the account team, not through a switch in the admin area. Anthropic describes ZDR as available for qualified accounts and enabled per organisation after confirmed eligibility, explicitly not as part of the standard Enterprise plan. Allow for lead time, and settle beforehand which repositories actually need it.

Does Amazon Bedrock solve our data protection questions?

Bedrock solves the residency and key questions, not the processing question. Encryption with AES-256 and customer-managed keys through AWS KMS are documented, and telemetry and error reports are off there by default. What remains are the local cleartext transcripts, the WebFetch domain check against api.anthropic.com, and your own obligations around purpose limitation, information and logging.

Take your list of developers and add a column for which account each person is signed in under. If a personal subscription shows up there, you already hold the conclusion of this article.

Thirty minutes with an engineer on plan choice, purchasing route and managed settings, no sales pitch: book a slot. Prefer writing? Through contact. How we build and secure AI systems is under Artificial Intelligence & Machine Learning.

All product and contract details verified against Anthropic’s and OpenAI’s primary sources on 20 August 2026. This article describes product and contract terms and derives technical consequences from them; it is not legal advice.

AI productivity: METR's 19 per cent is out of date

Robert Pupel — Mon, 17 Aug 2026 00:00:00 GMT

The most-quoted number on AI productivity is out of date. In 2025 METR measured, across 16 experienced open-source developers, 19 per cent more time needed with AI tooling. The same organisation’s follow-up study, running from August 2025 with 57 developers, measures 18 per cent less time for the same people. Both intervals are so wide that neither result is established.

Why the 19 per cent figure is quoted wrongly today

The 19 per cent comes from a randomised study by METR, February to June 2025: 16 experienced developers, 246 issues in their own repositories averaging over 22,000 stars. The tooling was mostly Cursor Pro with Claude 3.5 and 3.7 Sonnet.

The finding was uncomfortable and therefore widely quoted: the developers expected 24 per cent speed-up beforehand, believed afterwards they had gained 20 per cent, and were measured to be 19 per cent slower.

METR continued the work. The update of 24 February 2026 reports a second study running from August 2025: 57 developers, 10 of them from the original study and 47 new, 143 repositories, over 800 tasks. All values in the same metric — time needed with AI against without, where a minus means less time:

Group	Point estimate	Confidence interval
Original study, Feb–June 2025	+19 %, i.e. more time	+2 % to +39 %
Same developers, second study	−18 %, i.e. less time	−38 % to +9 %
Newly recruited developers	−4 %, i.e. less time	−15 % to +9 %

The result has not weakened, it has changed sign. More important is the difference in the intervals: the original study’s excludes zero, both new ones include it. Neither slowdown nor speed-up is established.

METR distrusts its own result, and gives clean reasons

METR itself writes that the data does not work as a productivity measure. Verbatim, on selection bias: “Because of the selection effects in our experiment, our data is only very weak evidence for the size of this increase.” And on the central estimate: “we believe it is likely a bad proxy for the real productivity impact.”

The reason is the most interesting point in the whole debate. METR cut compensation from 150 to 50 dollars an hour. That changed who took part at all, and which tasks got submitted.

“30% to 50% of developers told us that they were choosing not to submit some tasks because they did not want to do them without AI”, the report says. One participant, in their own words: “I avoid issues like AI can finish things in just 2 hours, but I have to spend 20 hours.”

That is exactly where measurability breaks. Filtering out the tasks where AI helps most measures systematically low. METR concedes that the results probably underestimate the true effect. On top of that, some participants ran several agents in parallel, which devalues the timing.

If you are writing a business case for AI tooling right now and notice you are missing the defensible number: that is not a failure of your research. Half an hour with somebody who has read the primary sources is cheaper at this point than another week of searching.

The counter-figure from the other camp is from 2022

The famous 55 per cent speed-up is a vendor number from 2022. GitHub Next published it on 7 September 2022, together with Microsoft’s Office of the Chief Economist. Ninety-five developers, randomly split into two groups, one single task: write an HTTP server in JavaScript.

The Copilot group took 1 hour 11 minutes, the control group 2 hours 41 minutes. The confidence interval runs from 21 to 89 per cent.

Three things about it are worth knowing before putting the number in a presentation. It comes from the maker of the tool being tested. It measures a self-contained laboratory task with no existing codebase, no review and no operations. And it is four years old, from before agentic tooling existed.

Who collected which number, and who paid for it

The comparison below sorts the six numbers that actually circulate in this debate by origin, funding and shelf life. All retrievals as of 20 August 2026.

Number	Who collected it	Who paid	Sample	Status in August 2026
55 % faster	GitHub Next, Microsoft	GitHub, i.e. Microsoft	95 people, one lab task	Vendor number from 2022, not valid for today’s tools
19 % slower	METR	non-profit, no vendor	16 people, 246 issues	Superseded by its own follow-up
18 % / 4 % faster	METR	non-profit, no vendor	57 people, 143 repos, 800+ tasks	Current, but the interval includes zero
AI acts as an amplifier	DORA	Google Cloud	State of DevOps 2025	Latest state, no 2026 report
3.45 % vs 7.40 % breaking changes	Ferdous et al.	academic, arXiv	7,191 agent PRs, 1,402 human PRs	Current
Context files ineffective, +20 % inference cost	Gloaguen et al., ETH Zurich	academic, arXiv	SWE-bench plus real repositories	Current, revised June 2026

The funding column is not a courtesy. DORA is a Google Cloud programme, and Google sells competing tools in Gemini, Jules and Antigravity. That does not make the methodology bad; it is rightly well regarded. But a report that helps companies defend AI budgets has a sender with an interest in AI budgets.

The amplifier finding is the most defensible statement in the research

The most stable insight is that AI tools amplify existing engineering maturity rather than replacing it. DORA puts it this way in the State of DevOps 2025: “AI acts as an amplifier, but the greatest returns come from focusing on the underlying sociotechnical systems.”

Two academic papers from 2026 show the same mechanism from below. The study “Safer Builders, Risky Maintainers” by Ferdous, Banik, Chowdhury and Shamim compared 7,191 agent-generated pull requests with 1,402 human ones from Python repositories and detected breaking changes through AST analysis.

Context	Breaking change rate
Code generation, agents	3.45 %
Code generation, humans	7.40 %
Agents on refactoring	6.72 %
Agents on chore changes	9.35 %

On new construction, agents break compatibility less often than humans. On maintenance work that inverts. The authors additionally describe a “confidence trap”: pull requests with a high self-reported confidence score from the agent contain breaking changes too. The score does not work as a review filter.

The second paper, “(Im)Paired Programming” by Balepur and colleagues, had 54 students build a website, with an agent or with a chatbot, and then tested comprehension through questions and through an extension task without an agent. Finding: agents help you finish and harm understanding, and it is precisely the comfortable interaction forms — copy-paste prompts, auto-accepted edits — that correlate with the worst understanding. The caveat belongs with it: 54 students are not an engineering team.

Why this supports the amplifier thesis: in both papers it is not the tool that decides but where and how it is used. The same observation from the practice side, without numbers, is in AI writes the code. Who writes the architecture?

What the range means for capacity planning

The second study’s confidence interval is too wide to budget with. Let us work it through in Swiss francs so the order of magnitude is visible.

A model calculation, not a survey: a team of ten developers, 1,800 working hours per person per year, so 18,000 hours. As an hourly rate we take CHF 160, the midpoint from the published worked example at gryps.ch for software engineering in German-speaking Switzerland (retrieved 20 August 2026). The annual capacity therefore corresponds to CHF 2,880,000.

Scenario from the METR interval	Time needed	Hours per year	Value
Lower bound	−38 %	6,840 hours freed	CHF 1,094,400
Point estimate	−18 %	3,240 hours freed	CHF 518,400
Upper bound	+9 %	1,620 hours extra	CHF 259,200

Between the two bounds lies CHF 1,353,600. Nobody plans a budget on a range like that, and that is the research’s honest answer rather than its failure.

The calculation deliberately transfers METR’s values crudely onto an annual capacity. METR measured issue-shaped tasks in mature open-source repositories, not full working years with meetings, operations and incidents. Anyone transferring the numbers one to one onto their team makes the same mistake as the camps they are criticising.

Measure your own baseline instead

The most useful response to an unclear body of research is your own before-measurement. Two metrics are enough to start, and both already sit in your repository.

First, a proxy for change failure rate, out of the git log over 90 days:

# All commits in the last 90 days
git log --since="90 days ago" --no-merges --oneline | wc -l

# Of those, reverts and hotfixes
git log --since="90 days ago" --no-merges --oneline \
  --grep="^Revert" --grep="^hotfix" --grep="^fix!" -i | wc -l

Second, the size of changes per author, to separate agent-generated from human pull requests:

gh pr list --state merged --limit 200 \
  --json number,author,additions,deletions,mergedAt \
  --jq '.[] | [.author.login, .additions + .deletions] | @tsv'

Collect both a month before rollout and three months after. Those two numbers say more about your team than any study in this article. How to record the decisions behind them so the measurement is still interpretable in a year is in Documenting architecture decisions.

What does not exist in August 2026

Three frequently expected sources do not exist at the time of writing, and anyone citing them is citing something invented.

No State of DevOps report 2026. dora.dev/research lists 2025 as the most recent entry. The only new thing is an interim product, the “ROI of AI-assisted Software Development report”, last updated 22 April 2026, with an ROI calculator.
No Stack Overflow Developer Survey 2026. The archive lists 2011 to 2025. The 2025 edition remains current.
No Technology Radar Vol. 35. Vol. 34 of April 2026 is the current issue, with “Putting coding agents on a leash” as one of the four themes.

What we advise against

We advise against three things, and the first concerns the numbers in this article itself. First: building an ROI business case on a point estimate, from whichever camp. The defensible statement from the research is a range, not a value.

Second: using an agent’s confidence score as a review filter. The confidence trap from “Safer Builders, Risky Maintainers” is exactly that mistake, empirically demonstrated. Grade review depth by task type instead. Greenfield work can run more loosely; refactoring and maintenance need strict control.

Third: auto-accept as the default setting. According to “(Im)Paired Programming” it is the interaction form with the worst comprehension outcome.

Where our recommendation does not fit: throwaway prototypes and spikes. If you are checking feasibility for a week and deleting the code afterwards, you do not need graded review depth. The effort pays from the moment somebody has to read the code a year later.

And a Swiss detail that gets lost in the international debate: the methodologically cleanest work on context files for coding agents comes from ETH Zurich. Gloaguen, Mündler, Müller, Raychev and Vechev showed in February 2026, revised in June, that AGENTS.md files do not generally improve the success rate but raise inference costs by more than 20 per cent. Three of the authors are affiliated with LogicStar AG in Zurich; Martin Vechev leads the Secure, Reliable and Intelligent Systems Lab at ETH.

Frequently asked

Is it true that AI makes developers 19 per cent slower?

That was the finding of a METR study from February to June 2025 with 16 experienced open-source developers. The same organisation’s follow-up, running from August 2025 with 57 developers and over 800 tasks, measures the opposite: 18 per cent less time needed among the returning participants. Anyone offering the 19 per cent as evidence today is quoting a superseded result.

Where does the “55 per cent faster” figure come from?

From a study by GitHub Next and Microsoft’s Office of the Chief Economist, published 7 September 2022. Ninety-five developers wrote an HTTP server in JavaScript, with or without Copilot. It is a vendor number from 2022, measured on a single laboratory task with no existing codebase, no review and no operations.

Which statement from the research is the most defensible?

The amplifier finding. DORA states in the State of DevOps 2025 that AI acts as an amplifier and that the greatest returns come from work on the underlying sociotechnical systems. Two academic papers from 2026 show the same mechanism in detail: the effect depends on the task type and the way of working, not on the tool.

Why is the productivity effect so hard to measure?

Because the participants influence the measurement. When METR cut compensation from 150 to 50 dollars an hour, 30 to 50 per cent of developers said they were not submitting certain tasks because they did not want to do them without AI. Filtering out exactly the tasks where AI helps most measures systematically low.

What should you measure in your own team instead?

Two metrics from your own repository, once before and once three months after introduction: the rate of reverts and hotfixes over 90 days as a proxy for change failure rate, and the change size per author, to separate agent-generated from human pull requests. Both take a few minutes with git log and gh pr list.

Let’s put your numbers next to them

Bring your git history and the question your management asked you. We collect the baseline together and tell you which of the studies quoted here actually applies to your case and which does not.

Book a slot or write to us. How we support teams using these tools is under Artificial Intelligence & Machine Learning.

Implementing the CRA reporting obligation from 11.9.2026

Ralph Segi — Thu, 13 Aug 2026 00:00:00 GMT

The CRA reporting obligation hits manufacturers of products with digital elements from 11 September 2026: report actively exploited vulnerabilities provisionally within 24 hours, fully within 72 hours, and file the final report at the latest 14 days after a corrective measure becomes available. Under Art. 14(1) CRA the report goes simultaneously to the coordinating CSIRT and to ENISA, through a single submission.

What applies concretely from 11 September 2026

Article 14 of Regulation (EU) 2024/2847 applies from 11 September 2026; the remaining manufacturer obligations only from 11 December 2027. The reporting obligation therefore arrives fifteen months before everything else that hits a manufacturer. Anyone waiting for full applicability has already missed the first deadline.

A third date regularly gets lost: Chapter IV on notified bodies (Articles 35 to 51) has applied since 11 June 2026. It concerns conformity assessment bodies, not you as a manufacturer.

Two triggers, two chains of deadlines:

Trigger	Early warning	Notification	Final report
Actively exploited vulnerability in the product	24 h from awareness	72 h from awareness	14 days after a corrective or mitigating measure is available
Severe security incident	24 h from awareness	72 h from awareness	one month after the incident notification

The clock runs from awareness, not from confirmation. Running an internal approval round first burns half the budget. Breaches of Articles 13 and 14 carry fines under Article 64(2) CRA of up to EUR 15 million or 2.5 % of worldwide annual turnover, whichever is higher.

Does the Cyber Resilience Act apply to Swiss companies?

Yes, as soon as a product with digital elements is placed on the market in the EU. Being based in Kreuzlingen, Zug or Zurich changes nothing. The only interesting question is which CSIRT a manufacturer without an establishment in the Union reports to.

Article 14(7) CRA solves that through a cascade: what governs is the member state where the authorised representative sits for the largest number of products. Failing that, the importer. Failing that, the distributor. If that remains open, the member state with the most users decides.

That is an architecture decision, not a legal footnote. Anyone who does not know today which national CSIRT is competent will not register in time on 11 September.

Where the report goes, and who your counterpart is

The report has two recipients and is nonetheless submitted only once. Article 14(1) CRA obliges the manufacturer to report an actively exploited vulnerability simultaneously to the CSIRT designated as coordinator and to ENISA. For severe security incidents, paragraph 3 says the same.

The technical route is one. Under Article 14(7) CRA the report goes through the reporting endpoint of the CSIRT designated as coordinator in the member state of the main establishment, and is simultaneously accessible to ENISA. The Commission puts it this way on its page on CRA reporting obligations: “Manufacturers report only once through the CRA Single Reporting Platform (SRP)”.

The party that comes back with questions is the CSIRT. Under Article 14(6) it may request an interim report, and it validates your access to the platform in advance. ENISA builds and operates it. If you want to know who you call in a real event: the CSIRT of your main establishment.

For implementation, three details from the ENISA FAQ on the SRP (as of 3 August 2026) matter more than any legal question:

There is no API for now. You can automate everything up to submission; the submission itself is typed by a human into a browser form.
Registration runs through EU Login (ecas.ec.europa.eu), with validation afterwards through the competent CSIRT. Both take time and belong before the real event.
The platform was not yet live in mid-August 2026, and the public URL not yet published. It is meant to be operational by 11 September.

So the last metre of your chain is manual. All the more important that the forty-nine metres before it are not.

Two authorities regularly get filed wrongly here. Germany’s BSI has been the notifying and market surveillance authority for the CRA since October 2025. Market surveillance, however, is not receiving reports.

And Switzerland’s BACS is not an address in the CRA context at all. It is the addressee of the Swiss ISG reporting obligation, a separate regime with its own legal basis. Conflating the two means reporting to the wrong place.

The CRA and the Swiss ISG reporting obligation side by side

Two regimes, two addressees, two legal bases, both with a 24-hour deadline. A Swiss software manufacturer that supplies the EU and whose products are used by Swiss critical infrastructure falls under both. We built this comparison because we could not find one anywhere. Every row is evidenced against the statutory text.

	CRA (EU)	ISG reporting obligation (CH)
Legal basis	Reg. (EU) 2024/2847, Art. 14	ISG (SR 128), Art. 74a–74h, plus CSV (SR 128.51)
In force since	11.09.2026	01.04.2025, sanctions from 01.10.2025
Who reports	manufacturers of products with digital elements	operators of critical infrastructure, including manufacturers of hardware or software whose products are used by critical infrastructure, where there is remote maintenance access or where they are used to control and monitor operational technology or for public safety (Art. 74b(1)(u))
Trigger	actively exploited vulnerability in the product, or a severe incident	cyberattack on one’s own IT assets under four criteria (Art. 74d)
Subject	the shipped product	one’s own operation
Addressee	coordinating CSIRT of the main establishment and ENISA simultaneously, one submission (Art. 14(1) and (7))	BACS
Channel	CRA Single Reporting Platform, EU Login account, no API	reporting form in the BACS Cyber Security Hub, alternatively an email form
First report	24 h from awareness	24 h from discovery (Art. 74e(1))
Second stage	72 h	none
Closure	14 days after the correction is available, one month for incidents	14 days to supplement, granted by BACS (Art. 16(1) CSV)
Inform users	yes, Art. 14(8), machine-readable where possible	not provided for
Extraterritorial	yes, through placing on the EU market	yes, for attacks with effect in Switzerland, including systems abroad (Art. 74b(3))
Sanction	up to EUR 15 m or 2.5 % of worldwide annual turnover (Art. 64(2))	fine up to CHF 100,000 against natural persons, subsidiarily up to CHF 20,000 against the business (Art. 74h)
Enforcement	market surveillance authorities of the member states	BACS sets a deadline, then issues an order with a penalty warning; prosecution by the cantons (Art. 74g)

The most interesting difference is in the last row. The CRA sanctions the omission directly. The ISG does not: under Art. 74g ISG BACS first sets a deadline, then issues an order, and only wilful disregard of that order is punishable under Art. 74h.

We know the same indirect construction from the revised Swiss DPA, where the Federal Data Protection Commissioner likewise has no direct sanctioning power. Anyone concluding from this that the ISG obligation is toothless is overlooking Art. 74h(1): the fine lands on natural persons, not on the company.

The figures come from BACS itself. In its semi-annual report 2025/2 (published 30 March 2026) the office processed 145 reportable cyber incidents in the second half of 2025, distributed across the public sector (25 %), IT and telecommunications (18 %) and finance and insurance (15.7 %). Alongside that, 64,733 voluntary reports across the full year.

What you have to build so that 24 hours is enough

Four artefacts have to be finished before the clock starts. None of them can be improvised during an incident.

An SBOM per release, stored immutably. Annex I Part II point 1 CRA requires a software bill of materials in a common machine-readable format covering at least the top-level dependencies. That is the legal floor, not the goal: stopping at transitive dependencies means missing Log4Shell-class problems.
A backwards-looking answer. The question in a real event is not “is the library vulnerable” but “which shipped versions contain it and who runs those”. That has to be a query, not a reconstruction.
An escalation path with a named person. Not “the security team” but a name and a deputy, with access to the registered EU Login account. At three on a Sunday morning.
An incident log with UTC timestamps. You do not only have to report within the deadline, you have to be able to prove that you did.

Five years of support, from 11 December 2027

Article 13(8) CRA sets the support period at a minimum of five years, shorter only where the product is expected to be in use for less time. Five years of security updates means five years of a working build pipeline for every still-supported release branch. That is the most expensive obligation in the whole CRA, and it appears in no reporting deadline.

If you are not sure whether your chain from detection to submitted form holds within a working day, run it once against a real, already-fixed vulnerability and time it. As an exercise that is an afternoon. What stands out is rarely the tooling and almost always the handover between two people.

SBOM in the pipeline: a setup that answers retrospectively

The SBOM belongs bound to the image digest, not to the tag. Tags get overwritten; digests do not. The workflow below produces both common formats, checks against CVE feeds, and signs the result keyless over OIDC. Versions as of August 2026: Syft v1.51.0, Grype v0.117.0, cosign v3.1.3.

# .github/workflows/release.yml
name: release
on:
  push:
    tags: ["v*"]

permissions:
  contents: read
  packages: write
  id-token: write            # keyless signing, no key material in the repo

jobs:
  sbom:
    runs-on: ubuntu-24.04
    env:
      IMAGE: ghcr.io/${{ github.repository }}
    steps:
      - uses: actions/checkout@v7

      - uses: docker/login-action@v4
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build, push, capture the digest
        run: |
          docker build -t "$IMAGE:$GITHUB_REF_NAME" .
          docker push "$IMAGE:$GITHUB_REF_NAME"
          DIGEST=$(docker buildx imagetools inspect "$IMAGE:$GITHUB_REF_NAME" \
                     --format '{{ .Manifest.Digest }}')
          echo "REF=$IMAGE@$DIGEST" >> "$GITHUB_ENV"

      - name: Pin the tools to fixed versions
        run: |
          curl -sSfL https://get.anchore.io/syft  | sh -s -- -b /usr/local/bin v1.51.0
          curl -sSfL https://get.anchore.io/grype | sh -s -- -b /usr/local/bin v0.117.0

      - uses: sigstore/cosign-installer@v4
        with:
          cosign-release: v3.1.3

      - name: Produce the SBOM in both formats
        run: |
          syft registry:"$REF" \
            -o cyclonedx-json=sbom.cdx.json \
            -o spdx-json=sbom.spdx.json

      - name: Check against CVE feeds, stop the build on anything critical
        run: grype "sbom:sbom.cdx.json" --fail-on critical

      - name: Bind the SBOM to the digest and sign it
        run: cosign attest --yes --type cyclonedx --predicate sbom.cdx.json "$REF"

      - uses: actions/upload-artifact@v7
        with:
          name: sbom-${{ github.ref_name }}
          path: sbom.*.json
          retention-days: 90       # GitHub's maximum, so only a buffer

The upload-artifact step is the weakest point and deliberately left that way: in production the SBOMs belong in object storage with versioning and object lock, queryable by component. GitHub artefacts are an intermediate step, not an archive. More on this in our work on CI/CD and supply chain.

The incident log that evidences your deadline

An incident log is not a ticket history but an append-only event stream with UTC timestamps. NDJSON is enough, one line per event, ts always first. What matters is the machine-recorded moment of awareness, which nobody has to reconstruct later from a Slack history. The revised Swiss DPA demands the same discipline for personal data; what an audit log that survives a subject access request looks like we have described separately.

{"ts":"2026-09-14T07:12:41Z","event":"aware","incident":"INC-2026-0007","cve":"CVE-2026-31337","product":"acme-gateway","affected_versions":["3.4.0","3.4.1"],"component":"pkg:golang/github.com/example/parser@1.8.2","evidence":"WAF signature 8841, 3 hits from 2 source ASNs","actively_exploited":true,"detected_by":"grype-nightly+SIEM","owner":"r.segi"}
{"ts":"2026-09-14T07:41:02Z","event":"triaged","incident":"INC-2026-0007","regime":["cra","isg"],"cra_trigger":"actively_exploited_vulnerability","due_early_warning":"2026-09-15T07:12:41Z","due_notification":"2026-09-17T07:12:41Z","csirt":"NCSC-NL","owner":"r.segi"}
{"ts":"2026-09-14T09:03:55Z","event":"reported","incident":"INC-2026-0007","channel":"eu-srp","stage":"early_warning","reference":"SRP-2026-114872","elapsed_h":1.85,"submitted_by":"r.segi"}
{"ts":"2026-09-14T10:26:33Z","event":"reported","incident":"INC-2026-0007","channel":"ch-bacs-csh","stage":"first_report","reference":"BACS-2026-3391","elapsed_h":3.23,"submitted_by":"r.segi"}
{"ts":"2026-09-14T11:48:07Z","event":"users_informed","incident":"INC-2026-0007","format":"csaf-2.0","url":"https://acme.example/security/ACME-SA-2026-004"}

The deadlines in the triaged event are computed, not typed. That is a function, not a calendar entry:

// Deadlines under Art. 14 CRA, computed from the moment of awareness in UTC.
type Deadlines struct {
	EarlyWarning time.Time // 24 h from awareness
	Notification time.Time // 72 h from awareness
	Final        time.Time // 14 days after a corrective measure is available
}

func CRADeadlines(awareAt, fixAvailableAt time.Time) Deadlines {
	awareAt = awareAt.UTC()
	return Deadlines{
		EarlyWarning: awareAt.Add(24 * time.Hour),
		Notification: awareAt.Add(72 * time.Hour),
		Final:        fixAvailableAt.UTC().AddDate(0, 0, 14),
	}
}

Why go to this trouble for a log that will hopefully never be needed: because in a dispute the burden of proof is yours. Anyone wanting to go deeper on the principle will find it worked out in observability you actually read and in documenting architecture decisions.

What not to do now

Do not buy a compliance tool before you have run the reporting chain once against a real vulnerability. This is the recommendation we get the most pushback on, and we are sticking with it.

The market for CRA platforms has been loud since spring 2026, and the products almost all solve the same problem: they produce documents. The problem that breaks your deadline is the hour between “an alert came in” and “somebody with access decided this is reportable”.

The trade-off, named honestly: a tool is procured in two weeks; the rehearsal costs an afternoon plus the corrections afterwards. Anyone with nothing at all in September 2026 is better off with a purchased tool plus a rehearsal.

Where our recommendation does not fit: with more than a handful of product lines with different authorised representatives in the EU, “which product reports to which CSIRT” becomes a data management question. Then a tool is right from day one. With one product and one CSIRT it is burning money.

The second thing not to do: postponing registration until the real event. Create the EU Login, determine the CSIRT, start the validation. One morning, and the only task that cannot be caught up on 11 September.

Frequently asked

From when does the CRA reporting obligation apply?

From 11 September 2026, through Article 14 of Regulation (EU) 2024/2847. Three deadlines then run: 24 hours to the early warning, 72 hours to the full notification, and 14 days after a corrective measure becomes available to the final report — one month for incidents.

The remaining manufacturer obligations only become applicable on 11 December 2027. Chapter IV on notified bodies has applied since 11 June 2026.

Who has to report under the CRA?

The manufacturer of the product with digital elements, regardless of where it is based, as soon as the product is placed on the market in the EU. Reportable are actively exploited vulnerabilities in the product and severe security incidents affecting its security. Existing products are included. Affected users must additionally be informed, under Article 14(8) in a structured, machine-processable format where possible.

What is an SBOM and what do I need it for?

An SBOM (software bill of materials) is a machine-readable inventory of all components of a software artefact, usually in CycloneDX or SPDX format. The CRA requires one in Annex I Part II point 1, at least for top-level dependencies. In practice you need it to answer, within hours, which shipped versions contain a component that has just become known to be vulnerable.

Does a Swiss company have to report twice?

Possibly yes, but to different places and for different reasons. The CRA addresses you as the manufacturer of an EU product and means its vulnerabilities. The ISG obligation addresses you as an operator of critical infrastructure and means attacks on your own systems. A ransomware incident in your build system can trigger both at once.

What happens if the Single Reporting Platform is not running on 11 September?

The obligation arises from Article 14, not from the availability of the platform. In mid-August 2026 the SRP was not yet live and its URL not yet published. Record the moment of awareness and every attempt to submit, with a note where submission was technically impossible. In that situation a complete log is the only thing you hold.

If the chain is not yet in place. Two weeks remain to 11 September, and probably longer to the first realistic report. If you want to know whether your chain from detection to submitted form holds: thirty minutes with an engineer who has built SBOM pipelines and worked in regulated environments such as the form service for the Swiss FOITT. No sales pitch, no slides.

Book a slot directly or write briefly through contact about what you are building. We will tell you where we see the deadline breaking.

All legal references verified on 19 August 2026 against EUR-Lex and Fedlex. This article describes the technical implementation; it is not legal advice.

A revDSG-compliant AI architecture: what actually counts

Robert Pupel — Tue, 11 Aug 2026 00:00:00 GMT

Under the revised Swiss Data Protection Act, liability for a breach falls on the natural person who acted, with a fine of up to CHF 250,000 — not on the company. That is the difference from the GDPR that shapes most architecture decisions, and it appears not in the catalogue of duties but in the criminal provisions.

That does not make the use of AI prohibited. The revised DPA requires four things: purpose-bound processing under the principles of Art. 6 DPA, transparency about collection under Art. 19, data security under Art. 8 in conjunction with the Data Protection Ordinance (DPO), and, for automated individual decisions, the right to review by a natural person under Art. 21.

The legal department asks about compliance. What you find on the subject are opinions: they say what applies, not which technical measure satisfies it. The second half is here.

Which four requirements does the revised DPA place on an AI system?

The revised DPA is the fully revised Federal Act on Data Protection of 25 September 2020 (SR 235.1), in force since 1 September 2023. Four of its provisions determine how an AI system has to be built. What binds is the statutory text on Fedlex, not a summary.

Art. 6 DPA, principles. Personal data may only be collected for a specific purpose that is evident, and must go as soon as they are no longer required for it. The purpose has to be recordable per processing step, not per product.
Art. 19 DPA, duty to inform. The data subject learns the identity of the controller, the purpose, and the categories of recipients. An inference provider is a recipient. Where data goes abroad, para. 4 adds the state and the safeguards under Art. 16 para. 2.
Art. 8 DPA, data security. The minimum requirements are in the DPO. Art. 2 DPO names four goals: confidentiality, availability, integrity, traceability. AI systems fail on the fourth.
Art. 21 DPA, automated individual decision. Where a decision is based exclusively on automated processing and has legal consequences or significantly affects the data subject, a duty to inform applies. The data subject can demand that a human review the decision.

To that add Art. 7 DPA: processing must be technically designed from the planning stage so that the rules are met. The article that turns the legal question into an architecture question.

Who pays the fine when an AI system breaches the revised DPA?

The natural person pays, not the company. Arts. 60 to 62 DPA make private persons liable to a fine of up to CHF 250,000. The business comes into it only subsidiarily: under Art. 64 para. 2 DPA the authority may sentence it instead of the persons acting, where a fine of at most CHF 50,000 is in question.

The provision relevant to an AI project is usually not Art. 60 but Art. 61 DPA, breach of duties of care. It catches precisely the three mistakes an architecture makes:

Disclosure abroad contrary to Art. 16 paras. 1 and 2, without the conditions of Art. 17 being met (lit. a)
Handover to a processor contrary to Art. 9 paras. 1 and 2 (lit. b)
Failure to meet the minimum data security requirements under Art. 8 para. 3 (lit. c)

The Federal Data Protection Commissioner does not impose these fines. Under Art. 65 para. 1 DPA, prosecution and adjudication fall to the cantons, generally to the public prosecutors. He can issue orders and file complaints, as he notes himself on his page on the criminal provisions.

Point	revised DPA	GDPR
Addressee of the sanction	the natural person who acted (Arts. 60–62 DPA); the business only subsidiarily (Art. 64 para. 2)	the controller or processor as an undertaking (Art. 83)
Level of fine	up to CHF 250,000; company fine up to CHF 50,000	up to EUR 20 m or 4 % of worldwide annual turnover, whichever is higher (Art. 83(5))
Fault	intent only; Arts. 60(1), 61 and 62 are prosecuted on complaint	negligence is sanctioned too (Art. 83(2)(b))
Who prosecutes	cantonal criminal prosecution authorities (Art. 65 para. 1); the Commissioner issues orders but does not sanction	the supervisory authority imposes the fine itself
Reporting a security breach	”as soon as possible” to the Commissioner where a high risk is likely (Art. 24 para. 1)	without undue delay, where feasible within 72 hours (Art. 33(1))
Automated individual decision	permitted; duty to inform, review by a human on request (Art. 21)	prohibited in principle, permitted only in the cases of Art. 22(2)
Processing on behalf	conditions in Art. 9; sub-processing only with prior authorisation (Art. 9 para. 3)	detailed catalogue of contractual obligations (Art. 28)
Limitation of prosecution	five years (Art. 66)	not regulated in the GDPR, governed by national law

The practical consequence: under the GDPR, compliance is a balance sheet risk and gets delegated. Under the revised DPA it is personal. Signing off an agent system means signing with your own name.

What changes with sensitive personal data?

With sensitive personal data three duties tighten. Art. 5 lit. c DPA lists the categories exhaustively: health, the intimate sphere and affiliation to a race or ethnicity, genetic data, biometric data uniquely identifying a person, religious, ideological, political or trade-union views, data on administrative and criminal proceedings, and data on social assistance measures.

Consent must be explicit (Art. 6 para. 7 lit. a DPA). A note in the terms of use is not enough.
Data protection impact assessment for large-scale processing (Art. 22 para. 2 lit. a DPA).
Logging, where they are processed automatically on a large scale or high-risk profiling takes place, and preventive measures cannot ensure data protection (Art. 4 para. 1 DPO). Both conditions have to coincide.
Processing regulations already where they are processed on a large scale or high-risk profiling takes place (Art. 5 para. 1 DPO). Without the restriction that applies to the logging duty.

The catch for an agent system is classification at runtime. A free-text prompt from an HR or support channel contains such data without any database field marking it. Failing to recognise them means logging too little. That is why the audit log below carries a data_classes field.

Where do personal data actually end up in an agent system?

Personal data end up in seven places, and the model is the most harmless of them. Sovereignty almost never breaks at the inference provider but at the periphery, because that is where nobody looks.

Prompt. What the user types. The only place most concepts look at.
System context. Retrieval results, few-shot examples, master data from the CRM. Often more personal data than in the prompt, and nobody put them there deliberately.
Tool calls. The agent calls an API with arguments. Those arguments are personal data and go to a second system.
Vector database. A vector index over customer correspondence is a collection of personal data in an unfamiliar file format, and it needs the same deletion paths as the source.
Logs. A stack trace contains the payload; a debug log the entire prompt.
Telemetry. OpenTelemetry’s GenAI semantic conventions define gen_ai.input.messages, gen_ai.output.messages and gen_ai.system_instructions as span attributes. Even after moving to their own repository with release v1.42.0 of 12 June 2026 they remain at status “Development” (attribute registry), and they carry the full content of the conversation.
Monitoring and eval SaaS. Error tracking, tracing, prompt evaluation. Three services that rarely appear in a contract review and often run in a third country.

The dotted edges are disclosures abroad that appear in no concept document. Anyone who draws their data flow this way usually finds two or three.

Draw your own flow like this once. It takes an hour and is the cheapest data protection measure we know. If you want somebody at the whiteboard who already knows the periphery: half an hour, no preparation.

How the same data flow can be built at the infrastructure level, with a provider comparison and GPU costs in CHF, is in sovereign AI inference in Switzerland.

What does “hosted in Switzerland” mean technically, and where does it stop?

“Hosted in Switzerland” describes the storage location, not the possibility of access. The two come apart as soon as the provider has a parent company in a third country, its support escalates from another time zone, or its control plane runs elsewhere. Access from outside is a disclosure abroad under Art. 16 DPA.

The test has two stages: is the recipient state in Annex 1 DPO? If not, a safeguard under Art. 16 para. 2 is required, for instance standard data protection clauses recognised by the Commissioner.

For the USA an intermediate position applies that is frequently misreported. Since 15 September 2024 it counts as a state with adequate data protection, but only for companies certified under the Swiss-U.S. Data Privacy Framework (Commissioner). Certification is per company, not per country.

Three technical consequences follow:

Egress is enforced, not agreed. A network-level allowlist is the only evidence that survives a review.
The inference endpoint belongs behind an abstraction of your own. Programming against a provider SDK means you cannot switch when the certification falls.
Every outbound connection needs a recorded jurisdiction. At AIgent that is a start-up condition: an endpoint without a jurisdiction entry does not come up.

Where does the human-in-the-loop gate sit in the agent graph?

The gate sits between decision and effect, not between model response and decision. Art. 21 para. 2 DPA requires review by a natural person, and a decision is only reviewable while it has not been carried out. An approval after the rejection letter has gone out does not satisfy the provision.

What decides it is the behaviour on timeout: a gate that lets things through after a timeout is not a gate.

package hitl

import (
	"context"
	"errors"
	"fmt"
	"time"
)

// Decision is the agent's proposal before it takes effect.
type Decision struct {
	RunID       string
	SubjectRef  string   // pseudonym of the data subject, never the real name
	Action      string   // e.g. "application.reject"
	Rationale   string   // reasoning for the reviewing person
	DataClasses []string // e.g. []string{"creditworthiness", "employment"}
}

// Review is the outcome of review by a natural person.
type Review struct {
	ReviewerID string
	Approved   bool
	Comment    string
	At         time.Time
}

type Auditor interface {
	Append(ctx context.Context, runID, event string, payload any) error
}

type ReviewQueue interface {
	Await(ctx context.Context, d Decision) (Review, error)
}

var (
	ErrExpired  = errors.New("hitl: no approval within the deadline, decision discarded")
	ErrRejected = errors.New("hitl: rejected by the reviewing person")
)

// Gate holds an automated individual decision under Art. 21 DPA until a
// natural person has confirmed it. If the deadline passes, the decision counts
// as not taken. There is no path on which a timeout leads to a silent
// approval.
func Gate(ctx context.Context, a Auditor, q ReviewQueue, d Decision, wait time.Duration) error {
	if err := a.Append(ctx, d.RunID, "decision.proposed", d); err != nil {
		return fmt.Errorf("audit: %w", err)
	}

	waitCtx, cancel := context.WithTimeout(ctx, wait)
	defer cancel()

	r, err := q.Await(waitCtx, d)
	if err != nil {
		// The reason for abandoning belongs in the log, even when the context is dead.
		_ = a.Append(context.WithoutCancel(ctx), d.RunID, "decision.expired", err.Error())
		return ErrExpired
	}

	event := "decision.rejected"
	if r.Approved {
		event = "decision.approved"
	}
	if err := a.Append(ctx, d.RunID, event, r); err != nil {
		return fmt.Errorf("audit: %w", err)
	}
	if !r.Approved {
		return fmt.Errorf("%w: %s", ErrRejected, r.ReviewerID)
	}
	return nil
}

Two things are set deliberately. The proposal is logged before anyone sees it; otherwise there is no way to evidence that a review took place. And Decision carries a pseudonym rather than a name: the reviewing person resolves the identity through their own authorisation. The same separation we treat as an interface question in documenting architecture decisions is a data protection question here.

What does an audit log that survives a subject access request look like?

An audit log fit for the revised DPA answers, per data subject, which personal data were processed when, by whom and for what purpose. Art. 4 para. 4 DPO names the mandatory fields: identity of the processing person, type, date and time, and where applicable the recipient. Para. 5 requires at least a year of retention, separated from the system in which the personal data are processed. Anyone supplying software into the EU needs a second, similarly built log from September 2026: the incident log for the CRA reporting obligation.

-- Its own database, its own credentials, its own backup cycle.
-- Art. 4 para. 5 DPO requires separation from the processing system.
CREATE TABLE agent_audit (
    id           bigserial PRIMARY KEY,
    occurred_at  timestamptz NOT NULL DEFAULT now(),  -- Art. 4 para. 4 DPO
    run_id       uuid        NOT NULL,
    actor        text        NOT NULL,  -- 'user:4711', 'agent:triage@2.3.1', 'reviewer:rp'
    operation    text        NOT NULL   -- the six operations from Art. 4 para. 1 DPO
        CHECK (operation IN ('store','modify','read',
                             'disclose','delete','destroy')),
    subject_ref  text        NOT NULL,  -- pseudonym, resolvable only in the identity service
    data_classes text[]      NOT NULL,  -- which categories, not which contents
    recipient    text,                  -- 'llm:apertus@ch-inference', 'crm:abacus'
    jurisdiction char(2)     NOT NULL,  -- 'CH', 'EU', 'US'
    purpose      text        NOT NULL,  -- keep Art. 6 para. 3 DPA demonstrable
    payload_sha  bytea       NOT NULL   -- hash instead of content
);

-- Make an access request under Art. 25 DPA answerable in one query.
CREATE INDEX ON agent_audit (subject_ref, occurred_at DESC);
CREATE INDEX ON agent_audit (run_id);

The line most often missing is payload_sha. An audit log with the prompt in cleartext is a second copy of the personal data that then has to sit there for a year. The trade-off: the hash evidences the processing, but nobody can read back what was in it.

Two provisions collide here. Art. 6 para. 4 DPA requires destruction as soon as the data are no longer required; Art. 4 para. 5 DPO requires a year of retention for the log. That only resolves with separate lifecycles, as in the form service for the Swiss FOITT.

What we advise against

An enterprise subscription as proof of compliance. An enterprise plan governs whether the provider uses your data for training. That is the only one of the four requirements it can meet for you. Purpose limitation, the duty to inform, traceability and reviewability under Art. 21 arise in your system, not in their contract.

Prompt contents in general observability. Writing gen_ai.input.messages into the same trace backend as your HTTP spans puts the conversation content in a system whose retention is tuned for cost. Prompts belong in the audit log, not in telemetry.

And the trade-off we will name openly: self-hosting the model costs speed. You operate GPU capacity, lag behind on model capabilities, and move effort from an invoice into a team.

An inference provider from a state in Annex 1 DPO, combined with strict control of the periphery, meets the same four requirements with less operational effort. Self-hosting is the right answer for sensitive personal data such as health data, and how to do it is in sovereign AI inference in Switzerland. For an internal knowledge assistant it is the wrong one.

As in who writes the architecture: the guardrails live in the repository, not in someone’s head.

Frequently asked

Do I need a processor agreement for an AI provider?

Yes, as soon as it processes personal data on your behalf, and every hosted inference service does. Art. 9 para. 1 DPA permits the transfer only where the data are processed as you would be permitted to process them yourself. What regularly gets broken is para. 3: sub-processing requires your prior authorisation. That is checkable through the versioned sub-processor list, not through the contract text.

May I put personal data into ChatGPT?

Legally possible, technically rarely clean. You need processing under the principles of Art. 6 DPA, a processor arrangement under Art. 9, the information under Art. 19 including the recipient state, and, where the provider is not Swiss-U.S. DPF certified, a safeguard under Art. 16.

Which criminal provision applies depends on what is missing: for the safeguard Art. 61 lit. a, for the processor arrangement Art. 61 lit. b, for the information Art. 60 para. 1 lit. b.

Is an enterprise subscription enough for revDSG compliance?

No. An enterprise subscription governs training use and usually data residency. It creates neither the log under Art. 4 DPO nor the reviewability under Art. 21 DPA, and it says nothing about your vector database, your logs and your monitoring.

Do we need a data protection impact assessment for an AI assistant?

Where the processing may entail a high risk to personality or fundamental rights, yes (Art. 22 para. 1 DPA). Para. 2 names two standard cases: large-scale processing of sensitive personal data, and systematic monitoring of extensive public areas. Where a high risk remains despite measures, the Commissioner must be consulted (Art. 23).

Does the EU AI Act apply to our Swiss company?

It can apply extraterritorially. Art. 2(1)(c) of the AI Regulation covers providers and deployers from third countries where the output of the AI system is used in the Union. The obligations for high-risk systems under Annex III apply, following Regulation (EU) 2026/1744, only from 2 December 2027, and for embedded systems under Annex I from 2 August 2028.

Take your architecture diagram and draw in the jurisdictional boundaries. If edges appear that you cannot explain, let’s talk about them.

Thirty minutes with an engineer about your agent architecture, no sales pitch: book a slot. Prefer writing? Through contact. What we build is under Artificial Intelligence & Machine Learning.

All legal references verified on 18 August 2026 against Fedlex and the Federal Data Protection Commissioner. This article is architecture advice, not legal advice.

Why we build critical backends in Go

Ralph Segi — Tue, 04 Aug 2026 00:00:00 GMT

When we are asked why a backend should be built in Go rather than Node, Java or Rust, the answer rarely comes from the benchmarks. Go is fast, yes. But plenty of things are fast. The reason is a different one: Go forces a kind of simplicity you can still read three years later.

The language has few opinions, and that is the opinion

Go has no inheritance, no exceptions, no generics acrobatics, no three ways to write a loop. What looks at first like a shortcoming is a gift in operation: code a junior writes looks almost like code a senior writes. Reviews are about the domain, not about style.

A backend you can no longer read is not a backend any more. It is a mortgage.

For systems meant to run for ten years — and with government, banks and infrastructure that is the rule — readability outweighs any feature list.

Errors are values, not surprises

if err != nil gets its share of eye-rolling. We like it. Every error is a visible path in the code that you either handle or deliberately pass on. There is no stack that surfaces three levels higher and swallows the request quietly.

order, err := repo.FindOrder(ctx, id)
if err != nil {
    return fmt.Errorf("find order %s: %w", id, err)
}

The error chain that results reads in the log like a sentence: handle payment: find order 4711: connection refused. That is observability you do not have to buy a tool for.

One binary, one container, no mystery

Go compiles to a static binary. The deployment is a FROM scratch container with one file in it — no runtime image, no package manager, hardly any attack surface. For Kubernetes environments that means small images, fast starts, little CVE noise. We carry the same pattern into new protocols, for instance when running MCP servers in Go in production. What we offer concretely as Go engineers from Switzerland is on the services page.

Concurrency you can explain

Goroutines and channels are not magic, but they let you write concurrent flows the way you draw them on a whiteboard: a worker pool, a pipeline, a fan-out. Once you have understood the model, you read someone else’s code without fear.

When we do not reach for Go

Honesty belongs here too: for data-heavy exploration and ML pipelines, Python remains the right choice. For frontends, TypeScript obviously. And where a team is already deep in an ecosystem and doing well with it, a change of language is rarely the most important decision available.

But where a system is a company’s critical infrastructure — payments, identity, administration — Go is for us the language that asks the smallest price for clarity.

AI writes the code. Who writes the architecture?

Robert Pupel — Tue, 21 Jul 2026 00:00:00 GMT

The amount of code a team can produce per week has multiplied with AI assistants. The amount of code a team can understand per week has not. The technical debt of the next few years is being created in exactly that gap.

The problem is not the AI. It is the missing brake.

An assistant told to “build me this” builds it. It does not ask whether this is the third repository pattern in the same service, whether the new dependency is necessary, or whether the function it is writing already exists. That is not a criticism of the tools. It is a description of their job. The brake has to come from outside.

Three rules we hold to

1. Architecture first, then prompt. Before a feature goes to an assistant, it is settled which module it belongs in, which interface it uses, and what it must not touch. Those guardrails live in the repository, not in someone’s head.

2. Every change is read by a human — all of it. Not skimmed. A review that only checks the diff statistics is not a review. If a diff is too large to read, the prompt was too large.

3. Deleting counts as progress. We do not measure how much code appears, but how much complexity is left per problem solved. An assistant is excellent at finding duplicates and merging them — when you ask it to.

What this changes

The developer’s role shifts from writing to deciding. That is harder, not easier: you have to know what a system should look like before you can describe it. Anyone who can do that gets a lever from AI unlike anything before it. Anyone who cannot gets a great deal of code very quickly.

Human intelligence steering the artificial kind. Not as a slogan, but as a division of labour.

An example from an ordinary week

A client needed an import for a new data format. The first AI proposal: a new parser, a new data model, 600 lines. After ten minutes of architecture conversation: an 80-line adapter feeding the existing model. Both would have worked. Only one of them will still be understood by somebody in a year.

Kubernetes is not a goal

Ralph Segi — Tue, 30 Jun 2026 00:00:00 GMT

Kubernetes is an excellent tool. It is also the most frequently misunderstood one. We regularly see clusters running three containers, maintained by two people, costing more than the application on top of them.

The honest question before any cluster

Not “can we do Kubernetes?” but: what happens when this service falls over at three in the morning, and who looks at it?

If the answer is “an alert, a runbook, a restart”, you do not need an orchestrator. If the answer is “twelve services have to come back in the right order, with rolling updates and zero downtime”, then you do.

When Kubernetes earns its keep

Several teams deploy into the same environment independently of each other.
Load spikes are unpredictable and scaling has to happen automatically.
Compliance demands reproducible, declarative infrastructure with an audit trail.
There are people who operate the cluster, not only use it.

When it does not

One application, one database, one team.
Traffic is known and fits on a well-sized machine.
Nobody on the team has time for upgrades, network policies and certificates.

In those cases a VM with systemd, a reverse proxy and a clean deploy script is not backward. It is the right size. If you want the decision backed by numbers, we have worked through what a cluster costs at Swiss providers, including the operational effort that appears on no price list. The numbers do not make the decision harder, they make it easier: they force you to name the goal before choosing the tool.

What we build first instead

Cluster or VM, three things always come first:

A deployment anyone can trigger. One command, one result, no knowledge living in one person’s head.
Observability you actually read. Few metrics, clear alerts, logs with context.
A rollback faster than the analysis. Roll back, then understand.

A team with those three can grow from a VM into a cluster whenever it needs to. A team without them just has a bigger problem with Kubernetes.

Decisions you can still understand in two years

Robert Pupel — Tue, 09 Jun 2026 00:00:00 GMT

Every system older than a year has places where a new team member asks: “why is this like this?” And the honest answer is too often: “the only person who knows has left.” The remedy costs almost nothing: document architecture decisions at the moment they are made, with the context that forced them. Not as prose for posterity, but as a short, dated note with three things in it: what was decided, which alternatives were on the table, what tipped it.

An ADR is a page, not a document

An Architecture Decision Record records what was decided, why, and what you accept in exchange. It has four sections and fits on one screen:

Context – what was the situation? What constraints were there?
Decision – what are we doing?
Alternatives – what did we reject, and why?
Consequences – what becomes easier, what becomes harder?

It lives in the repository, next to the code it explains. Not in the wiki, not in a ticket, not in a Slack message.

Why this beats any documentation

In practice the distinction is simple. Documentation describes how a system is. It goes out of date the moment the system changes. An ADR describes why it became that way. That never goes out of date — even when the decision is later reversed, the record stays true. You add a new one that references the old.

A system without a decision history is like a contract without a date. You can read it, but you cannot place it.

How we handle it day to day

Every decision that is hard to reverse gets an ADR. Database choice, module boundaries, auth model: yes. Button colour: no.
The ADR is written before implementation and reviewed in the same pull request.
Numbered, chronological, never deleted. A record is superseded by a new one, not by editing.

The cost: twenty minutes per decision. The return: a team that after the third round of staff changes still knows why the system looks the way it does.

Idempotency: the least conspicuous feature of a payments API

Ralph Segi — Tue, 19 May 2026 00:00:00 GMT

A request goes out and the response never comes back. Timeout. The client tries again. Has the payment now happened once, or twice? If an API cannot answer that question unambiguously, it is not fit for money. That holds for every payments API, whatever the provider and whatever the protocol.

The principle

An endpoint is idempotent when the same request, repeated any number of times, has the same effect as making it once. For GET that is a given. For POST /payments you have to build it.

The client sends a self-generated key with every write request:

POST /v1/payments
Idempotency-Key: 8f1c2a4e-3b7d-4c9e-a1f0-5d6e7f8a9b0c

The server remembers the result of the first processing under that key. Every repetition with the same key gets the same response, without executing the payment again.

What often gets missed

The key has to match the request. The same key with a different body is an error, not a retry. We check a hash of the body and answer with 422 when it differs.

Concurrent retries. Two identical requests arrive at the same moment. The key has to be reserved before processing — an INSERT ... ON CONFLICT DO NOTHING in the same transaction — otherwise both proceed.

Expiry. Keys do not live forever. Twenty-four hours is a good default; after that a repetition is a new request.

A fragment in Go

func (s *Service) CreatePayment(ctx context.Context, key string, req PaymentRequest) (Payment, error) {
    return s.idem.Run(ctx, key, req.Hash(), func(ctx context.Context) (Payment, error) {
        return s.payments.Create(ctx, req)
    })
}

The whole of the logic — reserve, execute, store the result, return it on a repeat — lives in one package that every write endpoint uses. No endpoint decides for itself whether it is idempotent.

Why this is the foundation

Retries are not an error case, they are the normal case: mobile networks, load balancers, timeouts, queues with at-least-once delivery. An API that does not recognise repetitions as repetitions moves the problem into the customer’s accounting department. It is more expensive there.

Three dashboards instead of thirty

Ralph Segi — Tue, 28 Apr 2026 00:00:00 GMT

Almost every environment we take over has Grafana. And almost every one has dashboards nobody has opened in months. The problem is not too little observation, it is too much of it with no question behind it. Observability you actually read therefore starts not with the tool but with the question of which three statements about the system have to be answerable at any moment: is it running, is it getting slower, and where is it stuck right now. Anything that does not answer one of those three is decoration, however pretty the panel.

Every dashboard answers exactly one question

Before a panel exists, it has to be clear which decision it supports. “Is the service healthy?” is a question. “CPU usage across all pods” is not — it is a number.

We almost always get by with three views:

Are users all right? Error rate, latency at the edge, successful core actions per minute.
Is the system all right? Saturation of the scarce resources: connections, queue length, memory.
What changed recently? Deployments, configuration changes, feature flags — as markers on the timeline.

Everything beyond that is diagnosis. Diagnosis belongs in ad-hoc queries, not on a dashboard.

Alerts you can take seriously

An alert that misfires weekly gets muted. At that point it is no longer an alert. Our rule: every alert has a name, a threshold derived from the promise made to users, and a runbook. If one of those is missing, the alert is deleted rather than extended.

An alert is a request for human attention. You send those sparingly.

Logs with context, not with volume

Structured, with a request ID, with the why rather than the what. payment declined: limit exceeded, limit=500 amount=620 says everything. error in handler says nothing, and it is nonetheless in every second log we see.

What is left at the end

Fewer panels, fewer alerts, fewer log lines — and a team that during an incident knows within thirty seconds where to look. That is observability. The rest is disk space.

devs group blog

Kubernetes v1.37: upgrading without downtime

Static pods may no longer reference secrets and config maps

The kubelet will not start when old cAdvisor flags are set

containerd 2.0 under Kubernetes: is the move mandatory for v1.37?

cgroup v1 was settled in v1.35, not now

kube-proxy IPVS: the clock is running, but slowly

Which Kubernetes version still has support

The upgrade order we recommend

When you should not upgrade

Frequently asked

How does a Kubernetes cluster upgrade without downtime work?

Which Kubernetes version is still supported?

How do I check which kube-proxy mode my cluster uses?

Do I have to move to containerd 2.x for Kubernetes v1.37?

What Kubernetes really costs in Switzerland

Why searching for Kubernetes prices in Switzerland comes up empty

The four cost blocks the bill is made of

What managed Kubernetes costs: the Swiss provider comparison

The model calculation: the same cluster at five providers

What Kubernetes costs on Azure and AWS in Switzerland

What operations cost: Swiss hourly rates as the unit

Managed, self-operated, or operated for you

Where the over-provisioning nobody sees is hiding

When the cluster does not pay for itself

What changes on the bill over twelve months

Frequently asked

What does a managed Kubernetes cluster cost per month in Switzerland?

Isn’t Kubernetes free?

What does Kubernetes cost on Azure and AWS in Switzerland?

As an SME do I need Kubernetes at all, or is Docker Compose enough?

Does my data stay in Switzerland with a Swiss Kubernetes provider?

Let’s work through your cluster

Sovereign AI inference in Switzerland: the architecture

What sovereign AI inference means technically

Which Swiss cloud providers offer sovereign AI inference

Apertus 1.5: what the Swiss model can do today

Running Apertus yourself: Hugging Face, Ollama or Apertus Mini

What inference on your own infrastructure costs

GPU scheduling on Kubernetes: DRA rather than device plugins

Inference serving: what belongs between model and application

Where sovereignty actually breaks

When sovereign inference is the wrong answer

The decision matrix

Frequently asked

What Swiss alternatives to ChatGPT are there?

What does a self-hosted LLM cost compared with the API?

What hardware do I need for my own LLM?

Does Swiss hosting protect against the US CLOUD Act?

The agents nobody approved

A repository with 386,890 stars that never went through procurement

What rights an agent like this actually has

What local operation triggers under the revised Swiss DPA

Three permission classes rather than one approval

How to detect use without hunting anyone

Tool lock-in is the second, quieter risk

What belongs in the policy, and what we advise against

Frequently asked

Is OpenClaw fundamentally unsuitable for companies?

How do I tell whether an agent has sent personal data to a model?

Is a container enough protection?

What do we do with an agent that has been running unnoticed for months?

The next step

Running MCP servers in Go in production

What the specification of 28 July 2026 changes

Why an MCP server gets built in Go

Stateless means the state gets a name

Authentication: how a tool call is bound to a user identity

Tool design: the mistakes we see most often

Operations: timeouts, rate limits, and what belongs in the logs

Is a pod the right unit for an agent?

What we advise against

Frequently asked

What is the Model Context Protocol?

How do I build an MCP server in Go?

How do I authenticate an AI agent’s tool calls?

Do I have to migrate my existing MCP server now?

Guardrails for coding agents: never its own reviewer

Three sources arriving independently at the same conclusion

What 932,791 agent-generated pull requests show