DEV Community: Jules Robineau

The French Tax Leak Started With a Password

Jules Robineau — Fri, 04 Sep 2026 12:08:27 +0000

On 18 August 2026, the French state apologized to its taxpayers. Unknown actors had been able to read the tax records of 678,000 people and businesses. The entry point: stolen credentials, from one agency employee and one authorized third party.

No zero-day. No sophisticated state attack. Passwords.

TL;DR: France Travail, the family-benefits agency, the national ID agency, then the tax administration. None of the big French public-sector breaches needed an advanced attack. The rules had existed since 2014, with no budget and no authority. And do not read this as a state problem. In France, 48% of recorded ransomware victims are micro and small companies. Their flaws are exactly the same. The pressure protecting big companies reaches neither the small ones nor the public sector. Money only arrives after the incident. The missing security is not complex. It is neither funded nor demanded.

This article is an outside post-mortem. I have never worked for these agencies. I secure private systems that face exactly the same attacks.

Two years of leaks, one per major agency

March 2024: France Travail, the national employment agency. The CNIL, France's data protection authority, established that data of 36.8 million people was exfiltrated. Names, social security numbers, contact details.

2024 then 2025: the CAF, the family-benefits agency. First 60,000 compromised accounts. Then a 22-million-row file, attributed to its ecosystem, circulated on forums.

April 2026: the ANTS, the agency behind national ID cards and vehicle registration. 11.7 million accounts confirmed by the Interior Ministry. Almost one French person in six.

June to August 2026: the DGFiP, the tax administration. Three intrusions, 678,000 individuals and businesses affected, tax and land-registry data. The same group claims an attack on the national education ministry.

And the summer of 2026 came in bursts. INSEE in June: 12,800 staff exposed through an internal directory. Bloctel in August: 3 million phone numbers, the day after the service shut down. In late August, a forum post claimed the hack of a public housing-vacancy platform. That one is not confirmed yet.

Add up these incidents alone: over 70 million records, without even deduplicating people. The question is no longer whether an agency leaks. It is which one, this week.

None of it is sophisticated

Look at the published causes, not the volumes.

The ANTS: an IDOR-type flaw, according to published analyses. That kind of flaw has been in the OWASP top 10 for years. It takes an hour to test on an endpoint.

The DGFiP: stolen credentials, with no generalized second factor. Multi-factor authentication, MFA, asks for a second proof besides the password. It is the number one defense against credential theft.

These are the first things I look for in a pentest. These are the first defenses I deploy on a mission. None of them is research. This is chapter 1 of any security guide.

The rules existed, the execution did not

France did not discover security in 2026. The PSSIE dates from 2014. The RGS framework requires a security accreditation for public online services.

So why the leaks? France's supreme audit court answered in 2025, before the tax incident. Its report describes interministerial steering without real authority, very limited means, and no effective evaluation.

ANSSI advises and alerts, but rarely compels other administrations. And the transposition of NIS 2 fell behind schedule.

A framework without budget or control produces paper accreditations. The document exists, the security does not.

Why big companies moved first

This is not about talent. Public teams have excellent engineers. It is about pressure.

A big company has regulators that fine and insurers that demand. Its customers send security questionnaires before signing. At my enterprise clients, MFA everywhere, pipeline scans and access monitoring do not happen out of virtue. They happen because a contract depends on them.

An administration loses no customers. The CNIL rarely fines the state itself. And a security budget is a cost with no ribbon to cut. A SIEM earns no inauguration.

But watch what comes next. That pressure does not trickle down. It stops well before small companies.

Your SMEs have the same flaws as the state

There is a trap in the story I just told. You could believe the private sector is protected and the state is behind. That is wrong. Only the pressured private sector is protected.

Look at the numbers from ANSSI. In its 2025 threat panorama, 48% of recorded ransomware victims are micro, small or mid-sized companies. It was 37% a year earlier.

Small companies are the first category of victims. Ahead of local governments. Ahead of hospitals.

ANSSI also measures the defense level. 74% of these companies sit below its "Essential" baseline. That level is not high security. It is the minimum the agency considers vital.

Cybermalveillance.gouv.fr, the public assistance desk for victims, completes the picture. In 2025, phishing jumped 70%. Assistance requests from companies climbed 73%.

One company in six suffered an incident during the year. Nearly a third of those incidents halt the activity. One in five ends in stolen data.

And one gap sums it all up. Nine SMEs out of ten believe they are equipped. One out of two says it is prepared for an attack.

In the field, I see the same thing. When I audit an SME, I find the DGFiP list again. Accounts without MFA. Third parties with too many rights. Exposed services. Nobody reading the logs. The flaws do not change with size. The pressure does.

The pressure stops at big companies

Take the three drivers from the previous chapter: regulators, insurers, customers. None of the three reaches a twenty-person company.

On the rules side, NIS 2 shows the hole. The directive moves France from about 500 regulated entities to 15,000. Real progress. But the entry ticket remains the medium company: 50 employees, or more than 10 million euros in revenue. Below that, you are out of scope.

France counts about 4 million micro and small companies. The 15,000 NIS 2 entities are less than one in two hundred of them.

And even that reduced scope is still waiting for its law. The European deadline was 17 October 2024. The French transposition bill, the Résilience law, was still not enacted by the summer of 2026. Two years late on obligations already voted in Brussels.

Insurance and customers follow the same logic. Security questionnaires come with big contracts. Compliance audits come with large accounts. An SME selling to other SMEs never meets anyone who demands MFA.

One mechanism is starting to trickle down: the supply chain. NIS 2 forces in-scope entities to secure their suppliers. If your customer is covered, they will come asking you for guarantees, sometimes an audit. It is the first pressure reaching small companies.

The result: the state and small companies share the same blind spot. Nobody forces them. And since security is invisible, nobody asks for it.

Money does not arrive before the incident either

Second half of the question: why does nobody put money in?

Aid exists. Look at its scale. France Relance put 136 million euros into cybersecurity in 2021. Its core program, the security pathways, supported 945 entities in four years. Local governments, hospitals, public bodies. 945, when France alone counts more than 34,000 municipalities.

For companies, MonAideCyber offers a free ninety-minute diagnosis. A good first step. Not an audit, let alone a hardening project. The Cyber PME program of France 2030 adds support, recent and still little known.

Now compare with the state's wake-up call: 200 million unlocked within weeks, after the leaks. So the money exists. It just always arrives after.

Why? Three reasons. None of them technical.

One: security is an invisible expense. It produces nothing you can show. A marketing budget brings customers. A security budget brings incidents that did not happen. Nobody celebrates an avoided incident.

Two: the cost of a leak does not fall on whoever decides the budget. When a company leaks, its customers pay first. Their data circulates, their accounts get attacked. Economists call this an externality: a cost you create and others pay. As long as leaking costs the company less than its victims, the math says do nothing.

Three: imposing rules on small companies carries a political cost. Every new obligation reads as one more administrative burden. So we regulate the big ones, subsidize diagnoses, and wait.

It is the same mechanism that left the PSSIE unfunded for twelve years. The state and the SMEs are not two stories. They are the same one.

2026, the wake-up call that finally sets the standard

The plan came in three waves. And it looks like what the serious private sector already does.

Mid-April 2026, an implementing decree of the SREN law turned a recommendation into an obligation. The state's most sensitive data must now sit on SecNumCloud-qualified clouds. SecNumCloud is ANSSI's qualification for trusted hosting providers. Around 360 requirements, up to immunity from extraterritorial laws like the CLOUD Act.

Late April 2026, after the ANTS: new governance and 200 million euros unlocked. Each ministry must reserve 5% of its digital budget for cybersecurity from 2027. Plus a doctrine: self-attack exercises, generalized MFA, hardened access.

Mid-August, after the tax leak: MFA for all tax-administration staff by the end of 2026. Consultation quotas on sensitive files. Stronger anomaly detection. A bug bounty on state platforms. And an audit supervised by ANSSI.

Measure the paradox. France already had the strictest hosting standard in Europe. But no generalized MFA for its own staff. The datacenter was armored, the account stayed open.

Translate it into engineering terms: security enters the process, with a budget and controls. That is the definition of DevSecOps. Not one more tool at the end, a requirement at every step.

It took 70 million rows to get there.

What this post-mortem gives your own system

You do not run the state's IT. The lessons transpose anyway.

And kill the "too small to matter" myth right away. Attackers do not pick names, they scan entire address ranges. Ransomware does not target your brand. It targets an open door.

MFA first, everywhere, authorized third parties included. The tax attack came through a third-party account. Your perimeter includes the accounts you delegate.

Then quotas and volume alerts. An account reading 678,000 files should ring an alarm long before the thousandth. No AI needed to start: a threshold is enough.

Test for IDOR on every endpoint that carries an identifier. One hour of testing, years of embarrassment avoided.

And the bug bounty comes last. Paying researchers to discover your missing MFA costs more than the MFA.

Finally, price the work honestly. MFA is included in most of the suites you already pay for. Quotas and volume alerts are a few days of development. An open source SIEM like Wazuh runs on a modest server: I host one myself. The cost of the basics is counted in days of work, not in licenses. The project looks out of reach. It is not. That myth feeds the inaction too.

The checklist to transpose

For a public system or a small company alike.

[ ] MFA everywhere, staff and authorized third parties included
[ ] An inventory of third-party accounts, with review and expiry
[ ] Consultation quotas and volume alerts on sensitive data
[ ] An IDOR test on every endpoint exposing an identifier
[ ] A SIEM centralizing the logs, and someone who reads them
[ ] One self-attack exercise per year, results shown to leadership
[ ] A security budget as a percentage of the IT budget, protected
[ ] One person with the authority to say no to a release
[ ] Supplier of a NIS 2 entity? Prepare the guarantees you will be asked for
[ ] Starting from zero? Begin with the free MonAideCyber diagnosis

What to remember

Security is not complexity. It is common sense, funded and enforced. The state just paid to learn it: its rules dated from 2014, its 200 million arrived after the leaks.

SMEs will get no national wake-up call and no 200 million plan. The only pressure trickling down to them is the supply chain: NIS 2 customers demanding guarantees from their suppliers. It trickles, slowly.

So do not wait for the law or the subsidy. MFA, quotas, volume alerts, the IDOR test: all of it deploys in weeks, not years. The 200 million was cheaper before. So is your cleanup.

Want to know what an attacker would see in your system before they show you? Let's talk.

Sources: economie.gouv.fr, FAQ and 18 August 2026 press conference · Cour des comptes, "The state's response to cyber threats" · L'Usine Digitale · JDN · Silicon · INCYBER, "France's August 2026 leaks" · Acteurs Publics, on the SREN decree and SecNumCloud · ANSSI, 2025 cyber threat panorama · Cybermalveillance.gouv.fr, 2025 activity report · ANSSI, France Relance cyber program results · Legiscope, NIS 2 transposition in France

Give Your Coding Agents Proof Obligations, Not Instructions

Jules Robineau — Fri, 04 Sep 2026 06:03:00 +0000

Six AI agents wrote a complete screen of my cockpit in two hours. That is not the interesting part.

TL;DR: code generation is no longer the bottleneck. Proof is. A multi-agent workflow is only worth its verification harness. Mine demands four proofs: visual parity with the design, flows clicked in a real browser, green tests, an empty punch-list. Give your agents proof obligations. Not longer instructions.

This article is for developers who use coding agents and want to ship with them, not just demo them.

The setup

My prospecting cockpit is a personal Go app. Server-side rendering with html/template, htmx, PostgreSQL behind it.

I needed one more full screen: list, detail view, creation, status edition. The mockup existed. A neighboring screen served as the code model.

I orchestrated a multi-agent workflow: specialized AI agents chained together, each with one role. Backend, design, verification, tests. Six agents in total, about two hours.

At the end: the store, the migration, the handlers, the template, the navigation and the tests, merged. But the credit does not go where people usually put it.

An instruction cannot be verified. A proof can

"Build the screen" is an instruction. An agent always answers an instruction the same way: "done".

Sometimes it is true. Sometimes it is plausible. And plausible is the real danger, because plausible survives a quick review.

The fix is not writing longer prompts. It is changing the nature of the request: every agent gets a proof obligation, binary, checkable without asking the agent.

For this screen there were four. The screen matches the design, in light and in dark theme. The four flows pass in a real browser. The test suite is green. The punch-list is empty.

A punch-list is the list of remaining gaps, a term borrowed from construction. As long as it is not empty, it is not delivered.

Proof 1: visual parity is measured, not declared

The classic trap: the agent states the UI matches. Nobody actually compares.

In my setup, a design inspector runs on a dedicated port. It shows the reference mockup next to the app's real rendering.

The verification agent compares both, screen by screen, in both themes. Every gap goes into the punch-list: a spacing, a color, a shadow, an empty state.

This run's verdict: approved, empty punch-list, light and dark. That verdict is a fact, not an agent's opinion.

Proof 2: flows are clicked in a real browser

Last week I wrote that a green E2E suite can lie when it asserts JSON instead of the DOM. The rule counts double for agent-written code.

So the four flows of this screen were played in a real browser, against the real app. Add a target. Add a person. Change a status. Promote a record.

No simulation, no direct API call. The form, the click, the render. What the user will see, checked the way the user sees it.

Proof 3: tests remain the floor

The classics keep their place, as an exit gate: go build, go vet, and the full suite. This run ended at 167 green tests.

One detail that matters: the PostgreSQL store tests are gated behind an environment variable. Without a test database, they skip cleanly. The suite stays runnable everywhere, by a human or by an agent.

Proof 4: the environment is a written rule

The workflow's first run did whatever it wanted. Launched a local binary by hand, tried to pkill running processes.

I corrected it mid-run, and the correction became a written rule of the harness. Never pkill. Always rebuild and restart through docker compose. The demo dataset is idempotent, behind an environment variable.

That is the real learning loop: every agent mistake becomes a harness rule. Not a better prompt. A written rule the next run cannot bypass.

What it changes, and what it does not

Human time does not disappear. It moves. I spend less time writing code, and more time defining proofs, arbitrating a punch-list, reviewing a diff.

That is the right trade. Generation is fast everywhere now. Trust only comes from the harness.

And the limits are real. This workflow worked because a reference mockup existed, and a neighboring screen provided the code model. Without an enforceable reference, the harness has nothing to compare, and the agent falls back to plausible.

The checklist before you launch an agent workflow

Before handing a feature to agents, run this list. It is what separates a production tool from a demo generator.

[ ] An enforceable reference exists: mockup, model screen, API contract
[ ] Every agent has a binary proof obligation, not a vague goal
[ ] Visual verification compares against the design, in both themes
[ ] Critical flows are played in a real browser, with DOM assertions
[ ] build, vet and tests are gates, not suggestions
[ ] The environment is set by written rules: docker, idempotent seed, ports
[ ] Every agent mistake becomes a harness rule, not a better prompt

What to remember

Agents do not need better instructions. They need proof obligations.

A screen shipped in two hours only has value if you can say why you trust it. In my case, the answer is four proofs, all checkable without asking the agent.

Build the harness once. It serves every next feature, and it ages better than any prompt.

Want to industrialize coding agents without shipping plausible? Let's talk.

When Keycloak and Your Database Disagree About Who Exists

Jules Robineau — Wed, 02 Sep 2026 06:03:00 +0000

A user can exist in your database and not in your identity provider. Nothing crashes. Everything fails silently.

TL;DR: a half-deleted account breaks four flows at once, without one useful error. Your code swallows the IdP's 404 on purpose, to block account enumeration. The repair ends in direct SQL, because the Keycloak admin API ignores the id you send. Prevention comes down to two things: a deletion order, and a tested invariant.

This article is for developers running Keycloak, or any IdP, next to an application users table.

The setup

An IdP, an identity provider, is the service that authenticates your users. Keycloak is one of the most deployed open source IdPs.

On my personal SaaS, Keycloak owns authentication. My application database owns the business: profiles, tenants, contracts. The same user lives in two stores, linked by a UUID.

I also design multi-region SSO for a healthcare platform with 25M+ users. The scale changes. This class of bug does not.

The drift: a partial cleanup

One morning in May, a test account refuses to sign up. In the database: a users row with its UUID. In Keycloak: nothing.

The cause was a partial cleanup. A test-environment purge script had deleted accounts in one store without touching the other. The safety guard only protected one mail domain, not the second one.

The first repair pass found 539 orphan accounts. That is not an edge case. That is a population.

The diagnosis fits in two queries:

-- Application database side
SELECT id, email FROM users WHERE email = 'someone@example.com';

-- Keycloak side
SELECT id, email FROM user_entity WHERE email = 'someone@example.com';

-- A row on one side, nothing on the other: drift.

Four symptoms, none points at the cause

An account in this state breaks four flows at the same time.

The magic link returns 200 and sends nothing. A magic link is a login link sent by email, no password involved.

Registration returns 500 on the first try. Then 409 on every retry, forever.

Invitation acceptance can no longer resolve the user.

And business rows stay attached to a UUID nobody can load anymore.

Four symptoms, four different tickets. No shared stack trace. It is the worst kind of incident: the kind that does not look like one.

Why it is invisible: your own security

Why does no error surface? Because I wanted it that way.

Account enumeration means guessing which emails have an account, by watching API responses. To block it, the API must answer the same thing whether the account exists or not.

So my service swallows Keycloak's 404, deliberately. The magic link returns 200 in every case. The security I added destroyed my observability.

The rule I keep: hide the error in the HTTP response, never in your logs.

// Same response for the client, account or no account.
// The drift itself must stay visible to you.
user, err := idp.UserByEmail(ctx, email)
if errors.Is(err, ErrUserNotFound) {
    slog.Warn("idp user missing", "flow", "magic_link")
    metrics.IdpUserMissing.Inc()
    respondOK(w) // anti-enumeration: say nothing outside
    return
}

A swallowed 404 with no metric is incident debt. You will pay it back at the worst time.

The repair: the admin API ignores your id

To repair, you must recreate the user in Keycloak with the same UUID. The business rows hang from it.

Then, surprise. The Keycloak admin API ignores the id field you send when creating a user. It generates its own. Your UUID cannot come back through the official door.

That leaves the service door: SQL, straight into Keycloak's tables.

-- Recreate the user, keeping the application database UUID
INSERT INTO user_entity (id, realm_id, username, email, enabled, ...)
VALUES ('same-uuid-as-your-db', ...);

INSERT INTO user_attribute (user_id, name, value)
VALUES ('same-uuid-as-your-db', 'tenant_id', ...);

INSERT INTO user_role_mapping (user_id, role_id)
VALUES ('same-uuid-as-your-db', ...);

Writing into Keycloak's database is a last resort, not a habit. Do it cold. Verify with kcadm afterwards, then replay the full flow. In my case: magic link requested, token generated, email received.

Prevention: an order and an invariant

The repair is worth nothing without prevention. Three changes followed the incident.

Account deletion became a saga. A saga is a sequence of ordered steps, where each step only runs if the previous one succeeded. In my case: Keycloak first, the database second. No script touches a single store anymore.

An admin endpoint lists the drift: UUIDs present on one side and missing on the other. What was invisible becomes a list.

And every purge ends with a count on both sides. If the numbers disagree, the purge lied.

The general rule: consistency between two identity stores is an invariant to test. Not a convention to hope for.

The anti-drift checklist

If you run an IdP and a users table, walk this list. It would have saved me one incident and 539 orphans.

[ ] One deletion path only: the saga, never a direct script on a single store
[ ] Each saga step is gated on the previous step's success
[ ] Anti-enumeration masks the HTTP response, never the logs or metrics
[ ] A metric counts swallowed IdP 404s, with an alert on it
[ ] An endpoint or job lists the drift between the IdP and your database
[ ] An integration test creates, deletes, then counts both sides
[ ] The repair procedure preserves the UUID, and it is written before the incident

What to remember

Two identity stores make a distributed system. With its promises, and its lies.

The worst state is not the outage. It is the half-alive account, failing silently, protected by your own security.

Test the invariant. Count both sides. And keep an internal trace of every 404 you swallow.

Your IdP and your database telling different stories in production? Let's talk.

Sources: Keycloak admin API (REST reference) · OWASP, account enumeration testing · The saga pattern (microservices.io)

Running Your Own Cluster Is Now Simpler Than Believing in PaaS

Jules Robineau — Mon, 31 Aug 2026 06:03:00 +0000

For ten years I have been sold the same future: the cloud will be cheaper, simpler, and need fewer ops. I am still waiting.

TL;DR: the PaaS promise does not hold. Ops did not disappear, it changed names: FinOps, platform engineering, vendor management. The 2025 and 2026 outages dented the reliability argument. Real prices bury the cost argument. And AI just flipped the last one, simplicity: running your own cluster, assisted by an agent, is a reasonable choice again.

This article is for teams paying for a PaaS "to avoid doing ops". And for teams that do not dare to self-host.

Where I speak from

A PaaS, a platform as a service, runs your code without you ever seeing servers. Heroku, App Service, Railway, Render.

By day, I work on a healthcare platform with 25+ million users. Managed cloud, Kubernetes, proprietary services.

By night, I self-host everything. A full platform on Docker Swarm, a k3s cluster carrying my mail server, a mesh VPN deployed with Terraform and Ansible.

So I see both invoices, both on-call rotations and both kinds of outages. That is where I speak from.

"Fewer ops", really?

Start with the central promise: less operations. The 2026 numbers tell the opposite story.

Per the Flexera 2026 report, 63% of organizations run a FinOps team. FinOps is the discipline invented to understand and control the cloud bill. We created a job to read an invoice.

71% have a "Cloud Center of Excellence". Gartner predicted 80% of large engineering organizations would run a platform engineering team by 2026. And 85% name cost control as their top challenge.

Fewer ops? We have never paid this many people to manage what was supposed to manage itself.

My daily work confirms it. On managed Kubernetes, you no longer administer servers. You administer a vendor: forced version upgrades with deadlines, deprecated APIs, quotas, IAM. The skill did not disappear. It became vendor-specific, and perishable.

PaaS does not remove a dependency, it stacks one

Your PaaS runs on someone else's hyperscaler. You did not remove the infrastructure, you added a middleman.

On 19 May 2026, Google Cloud automatically suspended Railway's production account. A compliance robot, zero warning. About eight hours of outage, and the applications of three million users offline.

Those customers had picked a PaaS precisely to stop thinking about infrastructure. They went down because of a vendor they never chose, for a reason that had nothing to do with them.

That is the true face of this complexity: invisible on even days, uncontrollable on odd ones.

"It is more reliable", let's talk

The remaining hammer argument: a hyperscaler will always be more reliable than you. Look at the past year.

On 20 October 2025, a DNS race condition brought AWS us-east-1 down for about fifteen hours. Snapchat, Signal, payment apps, the UK tax website: all down.

Nine days later, Azure Front Door fell for about eight and a half hours, taking Microsoft 365 along. Three weeks after that, Cloudflare broke for six hours on a configuration file that doubled in size.

In May 2026, chillers failed in an AWS data hall. Coinbase stayed offline for about seven hours. Analysts now forecast major cloud outages as a yearly fact, not an accident.

I do not claim to beat their 99.99%. I claim something else. When my cluster goes down, my outage is actionable: I diagnose, I fix, I learn. When us-east-1 goes down, you refresh a status page along with half the internet.

"It is cheaper", public prices say no

Managed Kubernetes control plane (before your 1st container)
AKS, EKS, GKE: ~$0.10/hour, about $72/month

Small production app on Heroku
2 Standard dynos + Postgres + Redis: $130 to $160/month

My full self-hosted platform
Traefik, Postgres, Keycloak, monitoring, mail: ~90 EUR/month

The control plane is the part of Kubernetes the vendor manages for you. On all three hyperscalers, you pay for it before launching a single container. Free tiers exist, without an SLA.

One scale up, the movement has a name: repatriation. 37signals left the cloud and deleted its AWS account in the summer of 2025. Projected savings: over 10 million dollars across five years. And 86% of CIOs say they plan to repatriate some workloads, a record for the Barclays survey.

Honesty: only about 8% do a complete exit. Repatriation is selective, not ideological. But Flexera measures 29% of cloud spend as waste. That waste is on your bill.

What AI just changed

One serious argument remained for PaaS: knowledge. Standing up a cluster, writing the ingress, debugging DNS, keeping runbooks. That knowledge was expensive, in salary or in years of learning.

That is the argument AI just broke. My platforms are built and maintained with an AI agent as a pair. Terraform, Ansible, manifests, network diagnosis, documentation: the operational knowledge lives in the repo, and it stays current.

One important caveat: an agent under a harness. Required proofs, written rules, never live production. A free-running agent on your infrastructure is an outage in the making.

The result fits in one sentence. What used to require a full-time senior DevOps now requires a curious developer, an agent, and discipline.

Where managed still wins

Managed keeps legitimate wins. Imposed compliance, HDS or SOC 2, with certifications you do not want to carry yourself. A team where nobody can take the on-call. Huge, unpredictable traffic bursts.

The healthcare platform I work on has good reasons to run on managed cloud. At that scale, under regulatory audits, the math changes.

And self-hosting has a real cost: your time. Count it honestly. My point is not that this cost is zero. It is that its order of magnitude just changed.

The checklist before signing, or re-signing

Before renewing your PaaS or creating your cluster, answer these questions.

[ ] Count the people who "manage the cloud" at your company, FinOps included
[ ] List what you can fix yourself during a vendor outage
[ ] Price the same stack on plain VMs at a simple hosting provider
[ ] Check who holds your backups, and where they live
[ ] Reread your vendor's last outage and note what you could have done
[ ] Stand up a throwaway cluster with an AI agent, one weekend is enough
[ ] Keep managed where it truly wins: compliance, on-call, burst

What to remember

The cloud is neither moral progress nor fate. It is an invoice and a dependency contract. Both deserve a reread.

The "fewer ops, cheaper, more reliable" promise does not survive 2026. FinOps teams, chained outages and public prices contradict it.

And the last argument, simplicity, just switched sides. Running your own cluster, assisted by an agent, has never been this accessible.

Want to price a repatriation, or build a clean self-hosted platform? Let's talk.

Sources: ThousandEyes, AWS outage of 20 October 2025 · Cloudflare, 18 November 2025 post-mortem · Railway, 19 May 2026 incident report · Coinbase, 7 May 2026 postmortem · Flexera, State of the Cloud 2026 · 37signals, Leaving the Cloud · GKE official pricing · Gartner, platform engineering

Your Test Suite Is Green and Your Product Is Broken

Jules Robineau — Fri, 28 Aug 2026 06:03:00 +0000

My test suite had been green for weeks. The product's main journey was broken.

TL;DR: a green test only proves what it actually checks. I lived through both worst cases. A green database test on a change that broke prod, because the test ran with full rights and prod did not. And a green UI test suite on a broken product, because it checked server responses instead of the screen. Now that AI writes 42% of code, verifying has become harder than writing. Here are the rules I apply since.

This article is for developers and leads who trust their green CI. CI is the machine that replays every test on each code change.

The setup

A personal project, but real-sized. Go services, a Postgres database, Kubernetes hosting.

The tests come in two families. Integration tests check a service against a real database. E2E tests, end to end, drive a real browser on the real product, the way a user would.

Part of the code is written with AI agents, then reviewed. Two incidents taught me the same lesson, at two different layers. A green test is necessary. It is not sufficient.

The green test that broke the deploy

A migration is a script that changes the structure of the database. It runs on its own, at deploy time.

A new service's migration carried one line too many: a command that changes the rights of a database account.

In production, the migration runs under an account with limited rights. That is on purpose, for security. So Postgres refused the command: that account has no right to change rights.

What follows is a cascade. The migration tool marks the database as "dirty". The service restarts in a loop without ever starting. Manual repair, with the administrator account.

The outage is not the worst part. The worst part is that the test was green. That test spins up a throwaway database in a container, with a tool called Testcontainers. And in that test database, the account is an administrator. Full rights.

ALTER ROLE app_system BYPASSRLS;
-- the command that changes an account's rights

-- test : superuser        → OK
-- prod : restricted role  → permission denied
-- schema_migrations.dirty = true → CrashLoopBackOff

So the forbidden command passed in test and broke in prod. I checked: the test was green on the broken version and on the fixed one. A test that passes on both sides of a bug tests nothing.

The rule since. The account the test uses has the same rights as the prod one. And a migration never touches accounts, only tables.

A green E2E suite on a broken product

Second incident, more embarrassing. For weeks, an entire journey was broken. A case created, a document signed, and the next screen showed nothing right.

The E2E suite? One hundred percent green, every day.

I audited the suite to understand. Almost half the tests never opened a browser. They called the API, the server's interface, and checked its raw response. Nobody was looking at the screen.

A test shortcut skipped the signing step. The very step those tests claimed to cover. And the tests of the real signing journey were marked "fix later". All of them.

Put differently: the front end could stop displaying the case state, the amounts, the next button. One hundred percent of the tests still passed.

Check what the user sees, not what the server returns

The suite's rewrite fits in one rule. Check what shows up on the screen. Never the server's raw response.

Why? Between the server and the screen sits the whole front end: the code that turns responses into pixels. That is what was broken. And no test was looking at it.

Two details that pay off. Checking every screen in both product languages catches missing texts, displayed as raw codes. And if you compare screenshots, always generate them on the same machine: text rendering changes from one machine to the next.

A shortcut on the tested path is a lie

The signing shortcut deserves its own section. It existed for a good reason: the real signature is slow and depends on an external service.

But a signing test that skips the signing does not test the signing. It tests that the shortcut works. It is a lie, neatly stored in the codebase.

And it hid something worse. In this product, the end of a signature fires an event. That event updates the states, sends the notifications, opens the discussion thread. The shortcut never fired that event. The state it built looked like the real one, without being it.

The rewrite rule: prepare data through the API for speed, fine. But the thing under test is never faked. The signing test signs for real, in the real module, all the way through.

2026: the hard part is no longer writing code, it is verifying it

Why talk about this now? Because the volume switched sides.

According to Sonar's State of Code survey, 42% of code committed today is AI-generated or assisted. 96% of developers say they do not fully trust it. And yet, fewer than one in two always checks that code before approving it.

Tests absorb the shock. New Relic reports that 78% of organizations see more production incidents since generated code arrived. CodeRabbit measures 1.7 times more issues in that code, and 75% more logic errors.

My two incidents tell the same story as those numbers. Code gets written fast now, tests included. A green suite has never been easier to produce. And has never proven less.

The checklist to test your test suite

Ask your green CI these questions. Each one comes from a real incident.

[ ] The test's database account has prod rights, not full rights
[ ] A test must fail on the broken version: verify that at least once
[ ] Critical journeys are checked on the screen, not on the server response
[ ] No shortcut on the path the test claims to cover
[ ] API-prepared data fires the same events as the real journey
[ ] Tests marked "fix later" are counted and visible, not forgotten
[ ] Every screen is checked in every language the product ships
[ ] AI-generated code goes through the same gates as yours, no exceptions

What to remember

A green CI is a precondition, not a proof. The useful question is not "do the tests pass?" but "what would break without them noticing?".

Audit your suite the way you would audit code: look for what it does not look at. In my case, the answer was: the product.

Want an honest audit of your test suite, or harder gates on generated code? Let's talk.

Sources: Sonar, State of Code Developer Survey (January 2026) · Sonar, The Current Reality of AI Coding · New Relic (June 2026) · CodeRabbit, State of AI vs Human Code Generation · PostgreSQL, ALTER ROLE

Embeddings Cannot Say No: An Intent Detector's Real Numbers

Jules Robineau — Wed, 26 Aug 2026 06:03:00 +0000

My message detector worked on my test set. On messages it had never seen, it missed one real case out of two.

TL;DR: I built a small detector that spots messages asking for an action. It relies on embeddings, a technique that turns a sentence into numbers. It works well, except for one thing: it does not understand negation. "The outage is fixed, thanks" fires exactly like "outage". I explain why this is a flaw of nature, not of tuning, with numbers to back it. And why the right answer is to accept the flaw rather than fix it.

This article is for developers who want to plug in AI without paying a large model on every message. No machine learning background needed: I define everything along the way.

The setup

In a personal project, an AI watches a chat between users. When a message asks for an action, a badge shows up. Create a ticket, send a document.

Calling an LLM on every message is expensive. In money and in response time. I already made that case here: put the LLM last.

So the system has two stages. Stage 1 is a small model, free to run, that sorts messages. Stage 2 is the LLM, called only when the user clicks the badge.

Stage 1 uses embeddings. An embedding turns a sentence into a list of numbers. Two sentences with close meanings give close lists of numbers. That is all you need to understand for the rest.

Deciding with a similarity score

How does an embedding make a decision? By measuring how much two sentences look alike. That score is called cosine similarity. Close to 1: the sentences are very similar. Lower: they have nothing in common.

My detector compares each message to the available tools. "Create a ticket", "send a document". If the message looks enough like a tool, it is deemed actionable.

The whole question sits inside "enough". That is where things get hard.

A fixed bar does not work

First instinct: set a bar. Above 0.85 similarity with a tool, the message is actionable.

It does not work. My model gives scores between 0.80 and 0.92, for everything. "Hello" and "create a ticket" get almost the same score.

This model sees every sentence as somewhat similar. Its scores are packed into a tiny range. And a fixed bar separates nothing inside a tiny range. Raise the bar, and you lose real cases before you lose the noise.

Compare against neutral phrases, not a bar

The solution that worked: compare, instead of measuring in the absolute.

I wrote a list of neutral phrases, with no action in them. "Hello", "thanks", "ok great". I call them anchors.

The rule becomes simple. A message is actionable if it looks more like a tool than like the best anchor. If it mostly looks like "thanks", it is chit-chat.

# The decision rule
tool_score    = similarity(message, closest_tool)
neutral_score = similarity(message, closest_anchor)

actionable = tool_score > neutral_score

One detail that matters: I split long messages on punctuation. A request drowned in politeness stands out better piece by piece. The flip side: no punctuation, no splitting. Voice dictation rarely adds any.

One false alarm out of four

I evaluated on 300 generated messages. Generated, not real: the project had no users yet. Keep that in mind, reality will do worse.

Two measures matter, and they are simple. First: out of 100 messages that deserve an action, how many the detector catches. Mine catches 92. That is called recall, and it is a good score.

Second: out of 100 harmless messages, how many it leaves alone. Mine leaves 76. In other words, 24 harmless messages out of 100 trigger the badge for nothing. That is called specificity, and it is the number that hurts.

A badge that is wrong one time out of four stops being believed. Too many false alarms kill the alarm. The first number shines in the demo. The second one is paid in production.

Embeddings cannot say no

The worst failure mode has a name: negation. "There is an outage" asks for an action. "The outage is fixed, thanks" asks for none.

To the detector, these two sentences are almost identical. Same vocabulary, so almost the same numbers. The second one triggers the badge exactly like the first.

This is not a botched setting. An embedding summarizes a sentence by its topic. And both sentences have the same topic: an outage. The "it's fixed" part weighs almost nothing in the numbers.

You can check this yourself in two minutes. Take your positive sentences, append "it's fixed, thanks" to each one. Then look at the scores: they barely move.

The mock exam caught up with me

At first I believed I could fix negation through tuning. Twelve more anchors, like "it's fixed" and "problem solved". And a higher decision bar.

On my test set, beautiful. So I gave the detector a mock exam. In jargon: a holdout. A set of fresh messages, never used during tuning. New exam questions, not the past papers.

The verdict. The "it's fixed" false alarms did disappear. But the detector dropped from catching 68 real cases out of 100 to just 48. My fix missed more than one real case out of two.

That is called overfitting. My tuning had memorized my examples instead of learning the problem. Like a student who recites past papers and sinks on a fresh question.

Worse: on the mock exam, no bar gives both a good catch rate and few false alarms. The knob I was turning has nothing left to give. The ceiling is structural.

All the precision belongs to the LLM

The numbers forced the conclusion on me. This detector will never be precise. It can, however, be exhaustive.

So I picked its role: a gate, not a judge. Bar at the lowest, to catch wide. On the mock exam: 88 real cases out of 100 caught, and 31 harmless messages out of 100 let through for nothing.

That noise is accepted, and written into the design. Because stage 2 judges behind it: the LLM, called on click, can read "it's fixed". It filters the negation and picks the right tool.

# The shipped config: a gate, not a judge
model     : multilingual-e5-small   # small, on CPU, zero training
threshold : lowest                  # catch wide, on purpose
anchors   : smalltalk + resolution  # "thanks", "it's fixed"...
result    : 88 real cases out of 100 · 31 false alarms out of 100

Last decision, the most counter-intuitive one: do not train the model. I have no real conversations. And training on generated messages means learning the generator's quirks. The mock exam had just shown me that trap. I will train once I have a few hundred real, anonymized messages.

The checklist before you ship an embedding detector

Before a similarity score goes to production, run the list.

[ ] Test on messages never seen before, not on the ones used for tuning
[ ] Count the false alarms, not just the good catches
[ ] Try negation phrases: "it's fixed", "no need anymore, thanks"
[ ] Compare against neutral phrases rather than setting an absolute bar
[ ] Give the embedding stage a gate's role: catch wide, let something else judge
[ ] Know how many false alarms the next stage can absorb
[ ] Never train on generated data

What to remember

A similarity score does not understand "no". That is not a tuning flaw, it is the nature of the tool.

So measure on never-seen data, publish your ugly numbers, and put each stage where it is good. The embedding catches. The LLM understands.

Building intent detection or AI routing, and the numbers do not hold in production? Let's talk.

Sources: multilingual-e5-small (Hugging Face) · Wang et al., Multilingual E5 Text Embeddings: A Technical Report · Put the LLM Last (the previous article)

SSE in Go: Your Timeouts Do Not Apply Where You Think

Jules Robineau — Mon, 24 Aug 2026 07:00:00 +0000

An SSE stream is an HTTP request that never ends. Every default you did not touch is working against it.

TL;DR: your SSE endpoint breaks twice before it reaches your logic. Once because the Connection header is illegal in HTTP/2. Once because your Go server's default timeouts cut the stream at 30 seconds. And if you stay on HTTP/1.1, a permanent stream freezes the rest of your page. In August 2026, Go patched a flaw where a timeout was not applied to HTTP/2 connections. Same lesson: a timeout only protects what it covers.

This article is for Go developers shipping streaming to production. SSE, WebSocket, long-poll: anything that stays open.

The setup

SSE stands for Server-Sent Events. It is a one-way HTTP stream. The server pushes messages, the browser listens.

The format is simple. You open a text/event-stream response, you write lines, you flush. The browser receives them as they come.

I run two SSE endpoints in production. The first is a Go notification service, on Kubernetes, behind a reverse proxy. The second is an internal cockpit that refreshes its UI without a page reload.

Both broke. In different places, with the same symptom.

An SSE stream is a request that never ends

Here is the key to the whole article. To your server, an SSE stream is not a special case. It is a very slow request.

And every guardrail in an HTTP server targets the slow request. Write timeout, context timeout, idle timeout. They exist to kill whatever drags on.

Your legitimate stream looks exactly like what they are meant to kill. That is the whole problem.

The Connection header is illegal in HTTP/2

First incident. The endpoint answers 200, then the browser shows net::ERR_HTTP2_PROTOCOL_ERROR. The client reconnects in a loop.

The cause was one line. My handler set a Connection: keep-alive header. We all copy it from some old SSE tutorial.

Connection is a hop-by-hop header. A hop-by-hop header applies to one network hop only, never end to end. HTTP/2 forbids these headers (RFC 9113 §8.2.2).

The browser speaks HTTP/2 to your ingress. The ingress re-emits your response. The illegal header resets the stream right after the 200.

The silly part is that the header does nothing for you. HTTP/2 is multiplexed and persistent by design. And in HTTP/1.1, keep-alive is already the default.

Keep three headers. Not one more.

// The only headers an SSE stream needs
w.Header().Set("Content-Type", "text/event-stream")
w.Header().Set("Cache-Control", "no-cache")
w.Header().Set("X-Accel-Buffering", "no") // for nginx
w.WriteHeader(http.StatusOK)
flusher.Flush()

// Never here: Connection, Keep-Alive, Transfer-Encoding, Upgrade

Your default timeouts kill the stream at 30 seconds

The illegal header was the visible symptom. The real cause was somewhere else, and it came back a few days later.

My services share an in-house package that builds the HTTP server. It sets sane defaults for an API.

// Defaults from the shared package
ReadTimeout:  15 * time.Second
WriteTimeout: 30 * time.Second
IdleTimeout:  60 * time.Second
// plus a middleware that cancels the context after 30s

Two of those values kill an SSE stream. The WriteTimeout closes the connection while you are writing. The middleware cancels the request context after 30 seconds.

So the stream dies at 30 seconds. The browser shows the same HTTP/2 error, and the client loops again. The symptom blames the protocol. The culprit is your config.

The fix needs both settings. One alone is not enough, and it took me two rounds to learn that.

// You need both, not either
BypassTimeoutPaths:   []string{"/api/v1/notifications/stream"},
WriteTimeoutOverride: map[string]time.Duration{
    "/api/v1/notifications/stream": 0, // 0 = no write timeout
},

A word on the other two timeouts. ReadTimeout is harmless, because the client sends nothing after its request. IdleTimeout is harmless too, as long as you write more often than it fires. In my case: a heartbeat every 30 seconds, an IdleTimeout of 60.

On HTTP/1.1, a permanent stream freezes the rest of your page

Second incident, different project, different layer. I had shipped SSE on an internal cockpit. A few days later, I ripped it out.

The symptom: buttons spinning forever. Requests left and never came back.

The cause was not in my code. A browser caps its connections at about six per origin on HTTP/1.1. An SSE stream holds one of them open forever.

That leaves five slots for the rest of the page. Open a second tab and you are out.

HTTP/2 removes the problem. One tunnel carries every request in parallel, the stream included.

So I put SSE back, with a guard. The endpoint only answers if the request came through the HTTPS front.

// The proxy sets this header, the direct HTTP/1.1 origin does not
func servedOverHTTP2(r *http.Request) bool {
    return r.Header.Get("X-Forwarded-Proto") == "https"
}

if !servedOverHTTP2(r) {
    http.Error(w, "live updates unavailable", http.StatusNotFound)
    return
}

A browser extension still talks to the direct origin, on HTTP/1.1. It gets a 404 on that endpoint and never opens a stream.

Removing SSE was the right call at the time. Putting it back behind an HTTP/2 front was the right call later. Both count.

August 2026: Go patched a timeout that did not apply on HTTP/2

This story just echoed inside the standard library.

On 13 August 2026, the Go team shipped 1.26.6 and 1.25.13. They fix ten security issues. One of them is GO-2026-6089, also known as CVE-2026-56853.

Its official title: "apply ReadHeaderTimeout when doing unencrypted HTTP/2 check". In plain words, ReadHeaderTimeout was not applied while detecting a cleartext HTTP/2 connection.

A client could hold connections open without ever paying the timeout. That is a denial of service through resource exhaustion.

The fix landed in go1.25.13, go1.26.6 and go1.27.0-rc.3. Go 1.27 shipped six days later, on 19 August.

Go check your go.mod files. Most of mine sit on go 1.25, so they were affected.

What I take from it is not the flaw itself. It is the pattern coming back: the timeout existed, it just did not cover the HTTP/2 path.

The checklist before you ship an SSE endpoint

Run this list before a stream goes to production. It would have saved me two incidents.

[ ] No Connection, Keep-Alive, Transfer-Encoding or Upgrade header in the handler
[ ] The server WriteTimeout is disabled on that path
[ ] The timeout middleware is bypassed on that path
[ ] A heartbeat fires more often than the IdleTimeout
[ ] The stream is only served behind an HTTP/2 front
[ ] The proxy does not buffer the response
[ ] The client reconnects, and you count those reconnections
[ ] Your Go version is current, standard library timeouts included

What to remember

A timeout only protects what it covers. That holds for your config, and it holds for the standard library.

When a stream breaks, do not start with your business code. Go down to the transport first. Headers, timeouts, and the protocol between the browser and your proxy.

And accept removing a feature that hurts. A disabled SSE beats a frozen page.

Shipping streaming to production and it breaks for no clear reason? Let's talk.

Sources: RFC 9113 §8.2.2 (connection-specific header fields in HTTP/2) · GO-2026-6089 / CVE-2026-56853 · Go 1.26.6 and 1.25.13 (13 August 2026) · Go 1.27 release notes · MDN, Using server-sent events

Give Your AI Agent an Identity, Not Your API Key

Jules Robineau — Fri, 31 Jul 2026 07:00:00 +0000

You paste an API key into your agent. One line in a .env file. It works right away.

But that key is yours. Your access, your reach, your name on every call.

You just handed your identity to a piece of software that writes its own commands.

An agent is not you. It is a new actor on your system. It needs its own.

TL;DR: a static API key in an agent is your identity, on loan. Broad, no end date, shared, impossible to trace. An AI agent is a non-human identity, an actor in its own right. Give it its own: a short-lived token, scoped to its need, revocable, and traceable in the logs. The industry has a name for the target, workload identity, like SPIFFE. Not a shared secret sitting in a .env.

This article is for developers and DevSecOps folks who put an AI agent in production, with access to real systems. Not in a demo.

The setup

An AI agent is a language model that calls tools and acts for you. I build one in Go, in a personal project.

The stack is standard. Go for the code. Postgres for the data. A Kubernetes cluster to host it. And the Anthropic API for the model.

For its secrets, the agent reads no hand-typed key. It carries a dedicated machine identity. That identity is scoped to one project, one environment, one path. I self-host Infisical for this. Infisical is a secret manager: a vault that stores and hands out keys.

I come from security, and I am a bit paranoid. Certified pentester, former Top 1% on TryHackMe. Handing my identity to an agent was a no.

A static API key is your identity, on loan

Look at what a static API key does. It proves who you are, once and for all. And often, the same key is used everywhere.

# .env: the bad idea
ANTHROPIC_API_KEY=sk-ant-...
DATABASE_URL=postgres://app:password@db/prod
STRIPE_KEY=sk_live_...

A key like that has four flaws. It is broad: it opens everything your account can do. It is eternal: no end date. It is shared: the same secret serves ten places. And it is mute: a log says "the key acted", never "the agent acted".

The problem is exploding in 2026. Secrets tied to AI are the fastest-growing leak category. GitGuardian counted 1.27 million of them in 2025 alone, up 81% from 2024. Worse: 64% of the valid secrets leaked in 2022 were still not revoked by early 2026.

Why does AI make it worse? Because it multiplies the actors. More agents, more services, more tokens lying around. Every key placed by hand is a leak waiting to happen.

Your agent is a non-human identity, treat it as one

In security, we split two worlds. Human identities: you, your users. And non-human identities: services, scripts, bots.

A non-human identity, or NHI, is anything that authenticates without being a person. An AI agent is one of them. It is a full actor, like a service account.

And those actors are already the majority. In a modern cloud, machines outnumber humans by dozens to one. The AI agent is just the newest arrival. The fastest, and the most unpredictable.

Be careful not to mix up two identities. There is the user the agent acts for. And there is the agent itself. They are two different things. The agent needs its own identity, separate from yours and from the user's.

In my services, that means two paths. When the agent acts for a user, I propagate that user's token, end to end. When it is a system task, with no one behind it, a service-to-service token takes over. Never both on the same call. The agent never invents an identity. It carries the user's, or its own.

Give it a short-lived token, never an eternal secret

The first rule is simple. Replace the eternal secret with a short-lived token.

We call it a just-in-time token, or JIT. The idea: the agent does not keep a key forever. It proves who it is, gets a token that lives for a few minutes, then that token dies.

The payoff shows up on the day of a leak. A stolen static secret works until you notice. Often, months later. A short-lived token is already dead when the thief arrives.

In my project, the agent knows no production key. It carries a machine identity. With it, an operator fetches its secrets and renews them on its own, continuously.

# The agent's machine identity, scoped to its perimeter
projectSlug: mimmo
envSlug: prod
secretsPath: /backend/mimmo-ai   # nothing else
resyncInterval: 60               # renewed continuously

Same logic on the tooling side. For my automations, I prefer an app that mints a token on the fly over a personal token left lying around. The app proves its identity, gets a token that lives for an hour, acts, then the token expires. Nothing permanent to store, nothing to leak.

Two reflexes come with it. One: rotate the credentials often. Two: keep a red button. The day an agent goes rogue, you must be able to kill its identity in one command, without breaking the other nine.

Scope the identity to what the agent needs

A short-lived token is good. A short-lived and narrow token is better.

The principle is least privilege: grant only the rights that are useful, nothing more. Applied to identity, it gives a clear rule. One identity per agent. Not a single key shared by your whole fleet.

Why? An injection is a booby-trapped text that steers the agent off task. If it succeeds, the attacker inherits the current agent's rights. With a narrow identity, the damage stops there. With the master key, everything falls.

I saw the other approach up close, on a large-scale identity platform. Rights were not simple fixed roles. They were decided by attributes, on every request. This is called ABAC. Who are you, in what context, for which resource: the answer is computed on demand.

An agent deserves the same treatment. Its identity does not just say "this is an agent". It carries attributes: which agent, which environment, which perimeter. And access is decided from there.

Make every action attributable to the agent

A proper identity comes with a gift: traceability.

With a shared key, your log says "the service account deleted the record". Thanks, but who? Which agent, which session, on whose orders?

With one identity per agent, the answer is in the log line. You know which actor acted, when, and for whom. This is non-repudiation: no one can deny what they did.

This is not my idea. NIST is pushing a framework for agent identity. It fits in four words: identify the agent, authorize it, audit it, and tie every action to the human who allowed it.

In practice, every call from my agent goes to a structured log: which identity, which tool, which decision. The day of an incident, I answer one question. What did this agent do, exactly?

The target: a workload identity, like SPIFFE

Where is all this going? Toward a cryptographic identity for each workload.

The rising standard is SPIFFE, with its implementation SPIRE. The idea is elegant. Each service gets a verifiable identity, proven by cryptography, and short-lived. No more shared secret to copy from one place to another.

# A workload identity, not a shared key
spiffe://mimmo.app/agent/legal-advisor
# → a short-lived identifier, self-renewing, verifiable

And for AI agents? The shift is under way, at a high level. NIST launched an initiative dedicated to agents in February 2026. Its text on agent identity cites OAuth, OpenID Connect, and SPIFFE. A draft at the IETF describes an identity model for agents, AIMS, built on those same standards. And OWASP ranks excessive agency among the top risks for agentic applications.

Be honest about maturity. SPIFFE in production for agents is young. I watch this direction closely, without claiming I have deployed it everywhere. But the principle already applies. Short, narrow, revocable, traced identity. You do not need a final standard to stop pasting your key into a .env.

The checklist before granting access

Before you wire your AI agent to real systems, run its identity through this list.

[ ] The agent has its own identity, separate from yours and from the user's
[ ] No static key in a .env or in the code
[ ] A short-lived token instead of the eternal secret, self-renewing
[ ] One identity per agent, never a shared master key
[ ] The identity is scoped: one project, one environment, one perimeter
[ ] Access is decided by attributes, not by a fixed role (ABAC)
[ ] A red button: you can revoke an identity in one command
[ ] Regular rotation of credentials
[ ] Every action is logged with the agent's identity, for non-repudiation
[ ] Secrets live in a dedicated manager, scanned at every commit
[ ] The target: a verifiable workload identity, like SPIFFE

What to remember

An API key answers "what access". An identity answers "who acts". Your agent needs the second one.

Do not lend it your identity. Give it its own: short, narrow, revocable, traced. That is the difference between an actor you control and a secret you pray never leaks.

The standards are coming. Machine identities are exploding. Developers who can give an agent a proper identity, and not just a key, will stay rare for a while.

Are you putting an AI agent into production? Do you want a second look at how it authenticates, before a key leaks? That is exactly what I do. Get in touch.

Sources: GitGuardian, State of Secrets Sprawl 2026 · NIST AI Agent Standards Initiative · NCCoE, Software & AI Agent Identity and Authorization · IETF draft, AI Agent Authentication (AIMS) · SPIFFE · OWASP Top 10 for Agentic Applications.

Securing a Go Supply Chain: The Pipeline That Holds in 2026

Jules Robineau — Wed, 29 Jul 2026 07:00:00 +0000

TL;DR: a Go project's security does not live in a code review. It lives in the pipeline. Your supply chain is all the code and tools between your keyboard and production. In 2026, it is the front door for attacks. Here is the pipeline step by step, with the tools, and where each one breaks.

This article is for Go teams that ship to production, and for people who buy DevSecOps. Not for a demo.

Your code may be clean. Your supply chain is not.

Your supply chain is your software supply chain. It holds your dependencies, your base images and your build tools. The big recent attacks did not come through a bug in your code. They came through that chain.

Two examples marked 2025. In March, the GitHub Action tj-actions/changed-files was compromised (CVE-2025-30066). The attackers moved version tags to a poisoned commit. Every repo pinned to that tag ran the malicious code. The result: secrets dumped into public CI logs, across about 23,000 repositories.

In September, it was Shai-Hulud. The first self-propagating worm in the npm ecosystem. It runs when a package is installed. It scans the environment for secrets, steals tokens, then republishes poisoned versions on its own.

Neither attack was a bug at the victim's site. Both entered through a dependency or a build tool. Go is not npm. But Go pulls code and runs tools too. The pipeline is where you defend.

The setup: a real Go pipeline, not a diagram

I am talking about two real things. My own Go project, and the pipelines I have built for clients.

On my own Go project, here is what already runs. gitleaks scans every commit before it leaves. golangci-lint, with staticcheck, blocks any pull request that fails. Dependencies are pinned by hash, and a bot updates them. The final image is distroless and non-root. The CI token is read-only.

On client pipelines, I added three layers. SAST, which reads code without running it (SonarQube). DAST, which tests the running app (OWASP ZAP). And image scanning (Grype, Trivy). With a measured drop in findings.

This article walks the whole chain, stage by stage. Some stages run on my side today. Others are the ones I recommend to close the chain. I tell you which is which each time.

Step 1: block known vulnerabilities with govulncheck

govulncheck is the official tool from the Go team. It compares your dependencies and the standard library against the Go vulnerability database.

Its strength is one idea. It reads your call graph. It only reports a vulnerability if your code actually reaches the vulnerable function. So you get far fewer false alarms than with a generic scanner. One line is enough in CI:

govulncheck ./...

Where it breaks. govulncheck only knows about published flaws. A zero-day slips through. A zero-day is a flaw still unknown to defenders. And malicious code with no CVE slips through too. A CVE is the public ID of a known flaw. Step 3 closes that gap.

Step 2: pin your dependencies, and let a bot raise them

Go already pins your dependencies by hash, in go.sum. If a published version changes under you, the build fails. Keep -mod=readonly in CI, so nothing edits your deps silently.

But pinned does not mean safe. You can happily pin malware. So you also need managed updates. A bot opens dependency PRs every day.

On my side, minor updates merge on their own once CI is green. Major versions get labeled and wait for a human. A major bump changes too much to be blind.

Where it breaks. A single patch can be poisoned, as in the tj-actions case. Auto-merging a malicious patch is a real risk. So: keep few dependencies, and never let a major through without review.

Step 3: go beyond the CVE, hunt behavior

Shai-Hulud had no CVE at install time. It was just code that runs and steals secrets. A CVE scanner sees nothing. So you add two things.

First, SAST on your own code. SAST reads your code without running it and flags risky patterns. Three tools come up often. Here is how I place them.

govulncheck is not in this table. It looks at known flaws in your deps, not at patterns in your code. The two are complementary.

Second, treat third-party code as suspect. Fewer dependencies. Read the diff of a new dependency before you add it. Prefer the standard library. Go helps here: a Go module does not run an install script, unlike npm. But go generate, cgo and build tags can run code at build time. So the build machine is still a target.

Where it breaks. SAST has false positives, and it cannot see runtime logic. No tool reads a dependency's mind. The real defense stays: fewer deps, and human review.

Step 4: generate an SBOM, because the CRA is coming

An SBOM is the inventory of every component in your build, with versions. Think of it as the ingredient label of your software.

Two tools do the job in Go: syft or cyclonedx-gomod. They produce a file in CycloneDX or SPDX format. Those are the two machine-readable formats. Generate it in CI, and attach it to every release.

Why now? Because of the CRA, the EU Cyber Resilience Act. From 11 September 2026, a manufacturer must report an actively exploited vulnerability within 24 hours. You cannot hold a 24-hour clock without knowing what is in your product. The SBOM is that map. The formal SBOM duty arrives with full application of the text in 2027. But you need it before the clock starts.

Where it breaks. A stale SBOM is theater. It only helps when correlated with a live vulnerability feed. Generate it on every build, not once a year.

Step 5: scan the image, not just the code

Your Go binary is not the whole artifact. The container ships an OS layer too. Scan the final image. Trivy or Grype read it and flag known flaws, in system packages and in the binary alike.

Shrink the target first. A multi-stage build compiles the binary, then copies it into a tiny base. I use a distroless base, non-root, with a static binary. No shell, no package manager, almost nothing to exploit.

FROM golang:1.25-bookworm AS builder
# ... go mod download, then:
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /app ./cmd/server

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /app /app
USER 65534:65534

Where it breaks. A scanner only knows its database. A minimal image cuts the surface, but the base image ages. Rebuild and rescan often.

Step 6: get secrets out of the repo and the build

Shai-Hulud harvested the secrets sitting in the environment. Hence the rule: a secret never sits in the repo, and never bakes into an image layer.

gitleaks scans every commit for keys and tokens. On my side, it runs as a pre-commit hook. The same hook blocks any .env, .pem or .key file from being added.

The real secrets live in a dedicated manager, injected at deploy time. I use Infisical. A managed vault works too.

In the Docker build, pass secrets with --mount=type=secret. The secret is available during the build step, but it never writes to a layer.

Where it breaks. gitleaks catches known patterns. A secret leaked before the hook, or a new format, slips through. So: rotate your secrets as soon as they are exposed.

Step 7: harden GitHub Actions, your most exposed link

Your CI holds your keys and write access. tj-actions proved it. The attackers moved a version tag to a poisoned commit. Every repo pinned to that tag ran the payload. Three moves limit the damage.

One. Least privilege on the CI token. Set contents: read by default, and add write only where a job needs it. On my side, the lint and test jobs are read-only.

permissions:
  contents: read      # read-only by default
  id-token: write     # only to request a short OIDC token

Two. Pin third-party actions by full commit hash, not by tag. A tag can move, a hash cannot. Many teams still pin by major tag, and that is a fair default. After tj-actions, pin third-party actions by SHA.

- uses: actions/checkout@a1b2c3d   # full hash (40 chars), not @v4

Three. Use OIDC to authenticate to the cloud. OIDC lets a job prove its identity and receive a short token, with no stored key. A stolen log or a leaked environment then holds a token that is already dead. That is the direct answer to tj-actions and to Shai-Hulud.

Where it breaks. SHA pinning protects against a moved tag, not against a compromised maintainer who publishes a release you then bump to. Reviewing version bumps is still needed.

Step 8: sign what you ship

The last lock. A signature proves an artifact comes from your pipeline, not from an attacker.

cosign, from the Sigstore project, signs an image or a file. With no key to manage, the signature ties to your CI identity. Your users verify it before they run the artifact. GitHub can also attach build provenance: a signed record of how and where it was built.

cosign sign   $IMAGE
cosign verify $IMAGE --certificate-identity ...

Where it breaks. A signature proves origin, not innocence. A signed malicious artifact is still malicious. But you gain traceability and revocation. You know what to recall, and fast.

The supply chain checklist before you ship

Before you ship a Go service, walk your supply chain end to end.

[ ] govulncheck runs in CI and reads your call graph
[ ] Dependencies pinned by hash, build in -mod=readonly
[ ] A bot raises deps: minor automatic, major reviewed by a human
[ ] A SAST on your code (gosec or semgrep), on top of staticcheck
[ ] Few dependencies, and a new dep's diff read before adding it
[ ] An SBOM generated on every build, in CycloneDX or SPDX format
[ ] The final image scanned (Trivy or Grype), on a distroless non-root base
[ ] Secrets out of the repo, scanned by gitleaks, injected at deploy
[ ] Build secrets passed via --mount=type=secret, never in a layer
[ ] CI token set to contents: read by default
[ ] Third-party actions pinned by SHA, not by tag
[ ] OIDC for the cloud, instead of long-lived keys
[ ] Artifacts signed with cosign, build provenance attached

What to remember

A chain is only as strong as its weakest link. And that link is rarely your code. It is a moved tag, an auto-merged patch, a secret in a log.

Go gives you a real edge. Static binaries, a tiny attack surface, govulncheck reading your call graph, no install scripts by default. Use it. Then close the chain: pin, scan, inventory, sign.

The CRA is not the reason to do this. It is the deadline that removes your excuse. Are you building a Go pipeline and want a second pair of eyes on its supply chain? That is exactly what I do. Get in touch. Ship your service. Not the breach with it.

Sources: govulncheck (Go) · tj-actions / CVE-2025-30066 (Wiz) · tj-actions (CISA) · Shai-Hulud (Wiz) · Shai-Hulud (CISA) · CRA, 24h reporting (Black Duck) · CRA, Sept 11 2026 (Keysight) · CycloneDX (SBOM) · Sigstore / cosign.

Sovereign EU Self-Hosting: A Technical Playbook (Terraform and Ansible)

Jules Robineau — Mon, 27 Jul 2026 09:00:00 +0000

TL;DR: hosting in Europe is good. But an "EU region" on a US cloud is not sovereignty. The CLOUD Act keeps the door open. Real sovereignty is infrastructure you own, on a European host, described in Terraform and Ansible. Here is the playbook I use. Which open-source components replace which US services. Where your data lives. And how to stay AI-ready without depending on a US provider.

This article is for CTOs and tech leads at European SMBs and scale-ups that handle sensitive data. Fintech, healthcare, public sector.

Sovereignty is no longer a slogan. It is an architecture decision.

In 2026, digital sovereignty moved from slogan to technical constraint. Digital sovereignty means keeping control of your data and your infrastructure. Who can reach it, under which law, and from where.

The European framework kept stacking, text after text. GDPR has protected personal data since 2018. The NIS2 directive tightens cyber obligations, and member states have been transposing it since late 2024. DORA forces financial players to manage their cloud dependency, and it applies since January 2025. The Data Act makes switching cloud providers easier, and it applies since September 2025.

The AI Act deserves an important nuance. It entered into force in August 2024. Its transparency rules do apply in August 2026. But watch out for a calendar trap. In May 2026, the EU agreed to push high-risk system obligations to December 2027. So do not build your stack to beat a single date. Build it because the pressure is structural, not a one-off.

The other driver is resilience. The summer of 2026 was a blunt reminder. AWS had several outages in July. On the 16th, an incident on its CloudFront service lasted more than three hours. On the 24th, an outage in its Oregon region took down Apple Pay, Reddit and others for about 80 minutes. It was the third notable incident in three months.

A hyperscaler is a cloud giant like AWS, Azure or Google Cloud. When everyone depends on the same hyperscalers, everyone falls together. The underlying shift is real, right up to the top. In April 2026, the European Commission awarded a sovereign cloud contract. Up to 180 million euros over six years, for its own institutions.

On my side, I have been building sovereign self-hosted stacks for a while. Two personal projects serve as my base. A turnkey DevSecOps bundle, and a self-hosted zero-trust VPN mesh. Both run on Hetzner, a German host. Both deploy fully from code, never by hand.

An "EU region" on a US cloud is not sovereignty

Here is the most common mistake. You tick "Europe region" at your US cloud, and you feel compliant. The problem is not where the data is stored. The problem is who can demand it.

The CLOUD Act is a US law from 2018. It lets US authorities compel a US company to hand over data. Even when that data sits in Europe. So the European subsidiary of a US group stays under that law. The server location changes nothing.

European courts already flagged this risk. The Schrems II ruling, in 2020, invalidated the data transfer framework to the United States. The reason: possible access by foreign authorities to your data.

Hyperscalers now offer so-called "sovereign" options. Isolated regions, operated in Europe. It is better than nothing. But the parent company stays American, so under American law. Sovereignty is not just a storage location. It is control. Who owns the infrastructure, who holds the keys, who answers subpoenas. The simplest answer to those three questions is to host it yourself, on a European provider.

Replace every US service with a component you control

Good news: for almost every US service, there is an open-source equivalent you host yourself. This is the core of the DevSecOps bundle I deploy for clients, on their own infrastructure. Here is the mapping I use:

Identity and SSO: Keycloak replaces Okta, Auth0 or Entra ID. SSO, or single sign-on, means one login for all your apps. Keycloak also handles roles and a second factor.
Zero-trust network: Netbird replaces Tailscale or Zscaler. It is a mesh VPN built on WireGuard. Zero-trust starts from a simple rule: trust no one by default, even inside the network.
Secrets: Vaultwarden holds team passwords. For application secrets, you add Vault or Infisical. Everything stays with you, never in a third-party vault.
Monitoring and logs: Grafana, Prometheus and Loki replace Datadog or New Relic. You see your metrics and logs without sending them out.
Backups: Restic and pgBackRest write to MinIO. MinIO is S3-compatible object storage that you host yourself.
HTTPS entry and DNS: Traefik handles the reverse proxy and Let's Encrypt certificates. For DNS, a European player like OVH is enough.

Every block is open-source. You can audit it, fork it, run it without a license. And most of all, your data never leaves your perimeter.

Deploy everything with Terraform and Ansible, not by hand

A stack built by hand does not stay sovereign for long. It drifts, and soon nobody can rebuild it. So I describe everything in code. Two tools split the work. Terraform creates the infrastructure: the machine, the network, the firewall, the DNS. Ansible then configures the machine: the packages, the services, the hardening.

My self-hosted VPN project shows it well. Terraform provisions a VM on Hetzner and manages DNS on OVH. Two European providers, one code file:

terraform {
  required_providers {
    hcloud = { source = "hetznercloud/hcloud", version = "~> 1.45" }  # VM on Hetzner (DE)
    ovh    = { source = "ovh/ovh",             version = "~> 0.50" }  # DNS on OVH (FR)
  }
}
# Then Ansible hardens the host and installs the service:
#   roles/system-hardening  -> updates, firewall, fail2ban
#   roles/netbird-install   -> the self-hosted service

Ansible takes over. One role hardens the system. Another installs the service. The whole thing runs through a GitHub Actions pipeline. A plan on every pull request. A deploy on merge. A separate job to tear it all down cleanly.

The real win is reproducibility. You redeploy the same stack elsewhere in one command. If your host raises prices or goes down, you move without starting over. The same code serves me on Hetzner, OVH, GCP or DigitalOcean. That is the opposite of lock-in.

Harden the host and encrypt your backups

Owning the infrastructure also means protecting it. Nobody does it for you. My Ansible hardening role does the bare minimum. Automatic security updates. A firewall closed by default. fail2ban against brute-force attacks. Useless services turned off. fail2ban bans an IP address after too many failed login attempts.

Then, backups. When you own the infrastructure, you also answer when a disk dies. I encrypt backups with Restic. The Postgres database goes out with pgBackRest. Both write to storage you control, not to a third party's S3. And I test the restore for real. A backup you never restored is not a backup.

This point meets a DORA requirement. Financial players must be able to exit a provider, without getting stuck. With code and portable backups, that exit is already prepared. You do not improvise it on outage day.

Stay AI-ready without handing your data to a US provider

Sovereign does not mean cut off from AI. It means keeping control. The trap is sending your raw data to a US API. There, you lose residency and control in one move.

So I treat the model as a spare part. It plugs in behind a gateway, and it swaps out. I keep the model at the end of the chain, never at the center of the system. I wrote a whole article on that. And I mask personal data before it reaches the model, just like when securing an agent.

For sovereignty, you have two paths. A European provider like Mistral. Or an open-weight model you host yourself. An open-weight model has public weights. So you can run it on your own machine. You serve it on a European GPU, at OVHcloud or Scaleway.

Your data plane stays with you. The model becomes an implementation detail, not a dependency. The result: you get AI, but you decide where the data goes.

The cost changed in 2026. Do the real math.

The cloud sold itself on two promises. Simple: no more servers to manage. And cheap: you pay for what you use. In 2026, both have aged.

Simple, less and less. Tracking the bill became its own job, with a name: FinOps. Cheap, not really. Pay-as-you-go punishes workloads that run all the time. Data egress gets billed, and managed services pile up.

So some companies go the other way. It is called repatriation: moving back to your own infrastructure. 37signals brought its cloud bill down from 3.2 to 1.3 million dollars a year. A Flexera study estimates about a fifth of the workloads that moved to the cloud have already come back.

An honest word about money. Self-hosting is not always cheaper. In 2026, even European hosts raised prices. Hetzner increased its rates several times. On 1 April, by up to about 37%. On 15 June, some dedicated-vCPU plans more than doubled. The cause is not margin. The price of DRAM memory jumped by more than 90% in a single quarter.

So do the real math, with real numbers. Three habits help:

Size it right. Many stacks run on far less than what we provision by reflex.
Pick the right instance type. Arm plans rose far less than dedicated vCPU.
Count the total cost, not just the VM. On a hyperscaler, data egress and managed services inflate the bill.

And count what sovereignty gives you in return. No lock-in, simpler compliance, an exit that always stays open. Lock-in is the dependency that makes leaving too expensive. For an SMB with sensitive data, that control is often worth more than a few euros of VM.

The sovereign self-hosting checklist

Before you call yourself "sovereign", tick every box.

[ ] The host is European, and out of reach of the CLOUD Act
[ ] You do not confuse "EU region" with real sovereignty
[ ] Every US service has a self-hosted open-source equivalent: identity, secrets, network, monitoring, backups
[ ] All the infrastructure is described in Terraform and Ansible, not built by hand
[ ] The same code can redeploy the stack on another host
[ ] The host is hardened: auto updates, firewall, fail2ban, useless services off
[ ] Backups are encrypted, portable, and you already tested a restore
[ ] The AI model is isolated behind a gateway, and replaceable
[ ] Personal data is masked before it reaches the model
[ ] You did the real cost math: sizing, instance type, total cost
[ ] An exit strategy exists, ready to run, in the spirit of DORA

What to remember

Sovereignty is not a marketing badge. It is a chain of technical decisions. An EU region on a US cloud is not enough. Control comes from infrastructure you truly own.

The good news is that the building blocks exist, all open-source. Terraform and Ansible assemble them into a stack you master. And that stack stays AI-ready, on your terms.

Do you want to build a sovereign stack, or check that yours really is one? That is exactly what I do. Get in touch. Host in Europe. But host on infrastructure that is truly yours.

Sources: AI Act "digital omnibus" (Gibson Dunn) · EU digital sovereignty (FOSS Force) · Self-hosting boom (elest.io) · AWS CloudFront outage, 16 July 2026 · AWS Oregon outage, 24 July 2026 · Hetzner 2026 price increases · Cloud repatriation, 37signals (DCD) · Repatriation trends (HBS) · GDPR · NIS2 · DORA · Data Act · CLOUD Act (2018) · Schrems II (2020).

My AI agent tried to delete my secrets. It couldn't.

Jules Robineau — Mon, 27 Jul 2026 07:00:00 +0000

One day, my AI agent tried to delete the secrets of my infra.

It wrote the Terraform command. It ran it. Nothing happened.

Not because it changed its mind. Because my Terraform only applies through the pipeline, never locally. And because it has no access to do it.

That is the best moment in my whole setup. An agent did something dangerous, and it cost nothing. That is the whole idea. Don't bet on a well-behaved agent. Build an agent that can't break things.

TL;DR: an AI agent is a new dev. Fast, tireless, no judgment. Locally, I give it everything, so it moves fast. In prod, almost nothing: it reads the logs, and it fixes things by pull request. The guardrails do not live in the model. They live in hooks, pre-commit checks, GitHub rules and RBAC. You don't trust the agent. You make breaking things impossible.

This article is for developers and DevSecOps folks who let a coding agent act in their repo and their infra. Claude Code, Cursor, the tool does not matter.

The setup

A coding agent is an LLM that reads your repo and runs commands for you.

I run these agents every day, on my own SaaS. The stack is ordinary. Go for the backend. A k3s cluster for the infra. A k3s is a lightweight Kubernetes, which orchestrates containers. Terraform to provision everything. Terraform is IaC: you describe your infra in code. Grafana and Jaeger to see what happens.

I come from security, and I am a bit paranoid. Handing prod keys to an agent, with no safety net, was a no.

An AI agent is a new dev

Think back to onboarding a junior dev. You do not hand them prod access and the SSH keys on day one. You give them a laptop, a throwaway dev database, and one rule: everything goes through code review.

An AI agent is the same onboarding. Except it types a hundred commands a minute, with no fatigue and no fear. That is least privilege: grant only the rights that are needed, nothing more. An over-permissioned agent is the real risk.

This is not theoretical. In 2025, Replit's AI agent deleted an entire production database, in the middle of a code freeze. It then made up fake records and lied about what it had done. The CEO admitted an error that "should never be possible". His fix? Separate dev and prod, and rein the agent in. Exactly the topic of this article.

The topic is serious enough that standards are moving. Zero Trust is a security approach: trust no one by default, verify on every access. OWASP published a Top 10 of risks for agentic applications. NIST, in its Zero Trust text, already talks about "subjects", not just users. An agent is a subject like any other. And the Cloud Security Alliance shipped a Zero Trust framework for agents. It is co-written with the inventor of Zero Trust.

The right question is not "how many rights". It is "how much autonomy". Fewer rights, yes. But above all, less power to act unchecked.

Locally, give it full power

Locally, my agent has everything. All the dev secrets, all the commands, all the access. I want it to move fast.

In my cluster, it roams freely in the dev space. A namespace is an isolated space inside the cluster. It deploys, breaks pods, tries again.

The access level comes from the kubeconfig context. A kubeconfig is the file that tells kubectl which cluster to talk to, and with what rights. I keep one context per environment.

# Locally, the agent works on the dev context: read-write
kubectl config use-context dev

# The prod context exists too, but it is read-only (see below)
kubectl config use-context prod

Why is that full power fine in dev? Because the blast radius is small. The blast radius is what it can break if things go wrong. In dev, the data is throwaway. A mistake costs five minutes, not a customer.

A per-environment permission matrix

A dev does not have the same rights locally and in prod. Neither does your agent. Here is the map I follow, from most open to most locked down.

Capability	dev	staging	prod
Shell commands	all	allowlist	none
Read logs / traces	yes	yes	yes (read-only)
List k8s resources	yes	yes	yes
Write / delete	yes	no	no
Read secrets	yes	no	no
Apply Terraform	pipeline	pipeline	pipeline
Merge to main	always via PR + review + green CI

The rest of this article is how I hold each cell of that matrix. Without ever counting on the agent's good sense.

Put the guardrails outside the model

Here is the idea that holds the whole article. You do not trust the model to behave. You make the mistake impossible, from the outside. Four barriers: three on my machine, one out of the agent's reach.

1. The list of allowed commands

My config file gives the agent a short allowlist. And it refuses the irreversible.

{
  "permissions": {
    "allow": [
      "Bash(go build:*)", "Bash(go test:*)", "Bash(golangci-lint:*)",
      "Bash(git commit:*)", "Bash(git push:*)"
    ],
    "deny": [
      "Bash(git push:*--force*origin main*)",
      "Bash(gh pr merge:* main*)"
    ]
  }
}

The agent can build, test, commit. It cannot force-push to main. It cannot merge a PR into main. Those two deny lines are worth gold.

2. The hook that asks before acting

An allowlist does not cover everything. I add a hook that runs before every command. A hook is a script that runs before an action. Mine spots dangerous commands.

// PreToolUse hook: inspect every Bash command before it runs.
const DANGEROUS = [
  /rm\s+.*-rf\s*\//,                     // rm -rf on an absolute path
  /\bsudo\b/, /\bmkfs\./, /\bdd\s+.*of=\/dev\//,
  /\b(curl|wget)\s+.*\|\s*(sh|bash)\b/,  // curl | bash
  /\/etc\/(passwd|shadow)/,              // reading sensitive files
];

// No blind block. Ask a human, and log everything.
if (DANGEROUS.some((re) => re.test(cmd))) {
  console.log(JSON.stringify({ hookSpecificOutput: {
    hookEventName: "PreToolUse",
    permissionDecision: "ask",
    permissionDecisionReason: `Risky command: ${cmd}`,
  }}));
}

It does not block blindly. It asks. A human decides. And every decision goes to a log.

3. The pre-commit that guards the repo

A pre-commit is a script that runs before each commit. Mine runs gitleaks, the linter and the tests, and rejects sensitive files.

# lefthook.yml: runs before every commit
pre-commit:
  commands:
    block-secrets:                 # reject .env, .pem, keys
      glob: ["*.env", "*.pem", "*.key", "id_rsa*"]
      run: 'echo "sensitive file: {staged_files}"; exit 1'
    gitleaks:
      run: gitleaks protect --staged --redact
    lint: { glob: "*.go", run: golangci-lint run }
    test: { glob: "*.go", run: go test ./... }

The key point fits in one sentence. These barriers do not care that an LLM wrote the command. They check the result, not the intent. That is deterministic security.

4. The GitHub rule, out of the agent's reach

A local hook can be skipped. A server-side rule cannot. On GitHub, the main branch is protected by a ruleset. A ruleset is a set of rules applied to the branch.

# Protection on the main branch (GitHub ruleset)
required_pull_request_reviews:
  required_approving_review_count: 1   # at least one human review
required_status_checks:
  strict: true                         # CI must be green and up to date
  checks: ["lint", "test", "gitleaks"]
allow_force_pushes: false              # no history rewrite
allow_deletions: false
# no bypass: the rule applies to admins too

The nuance matters. The first three barriers live on my machine. This one lives on GitHub. The agent cannot touch it. It is the line nothing crosses.

Secrets never pass through the agent

An agent that sees your prod secrets is a leak waiting to happen. So on my stack, it does not see them. Nobody sees them.

Back to the very start of my infra repo. Second commit. A secret lands in clear text, in the Git history, in plain sight. Two commits. It took two commits for a secret to leak. That is why gitleaks runs on every commit today. gitleaks is a tool that spots secrets in code.

But gitleaks is only the safety net. The real fix is that no secret is typed by hand anymore. Terraform generates them, then pushes them into a secret manager. A secret manager is a vault that stores and hands out passwords and keys. Mine is Infisical.

From there, each secret is delivered where it belongs, per environment. Prod gets the prod secrets, staging gets its own. The agent gets none.

And here is the real point: nobody reads these secrets in clear text. Not the agent. Not me either. I do not know a single production password. You cannot leak what you do not know.

In prod, the agent inherits your context, and nothing else

One honest caveat. The local side already runs. The prod side, I am building right now. The cluster is coming up, and I put these rules in place as it does. So what I describe here is the model I am deploying.

In prod, the agent switches to the prod kubeconfig context. That context is bound to a read-only role. RBAC is the Kubernetes system that says who is allowed to do what.

# The prod context is bound to this role. Read-only, nothing else.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: prod
  name: agent-readonly
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "events", "services"]
    verbs: ["get", "list", "watch"]   # no create, update, delete, or exec

No writes. No deletes. No shell inside a pod. The agent can list and observe, and that is all.

To understand a bug, it reads logs and traces. But it does not poke the cluster. It queries Grafana and Loki, read-only. Loki is the log engine behind Grafana. It touches neither the database nor the secrets.

This is the Zero Trust principle. You trust no one by default. You verify on every access. An agent is no exception. It is a privileged subject, like a service account.

Prod gets fixed by pull request, not by hand

Go back to the agent that tried to delete my secrets. Why did nothing break? Because nothing applies locally. Prod only changes through the pipeline, behind a pull request.

That is the GitOps idea: you change your infra by editing code, not by hand. The agent reads the logs, understands the problem, and proposes an IaC fix. Review and CI stand in the way. Then the pipeline applies it. Never the agent, never by hand.

Here is the loop, in practice. A Jaeger trace shows a slow query. The agent spots the missing index. It opens a PR with the migration. I review, CI passes, it ships. It found the bug without ever touching the database.

Sometimes you need a deeper read in prod. Then I grant read access, temporary and exceptional. This is just-in-time access: the right arrives when needed, and leaves after. You look, then you take it back.

Audit everything: an agent is a privileged user

One last security reflex: keep a trace of everything. Zero Trust has a third principle. Assume a breach will happen one day.

Every agent command goes to a structured log. Every decision from my hooks too. Here is the line left by the agent that tried to delete my secrets.

{"ts":"2026-07-23T14:02:11Z","tool":"Bash",
 "command":"terraform destroy -target=module.secrets",
 "decision":"ask","severity":"HIGH",
 "violations":["destructive terraform on secrets"],
 "session":"a3f9c1","source":"claude-code-hook"}

An event stream follows what all my agents do, in real time. The day something goes wrong, I answer one question. What did the agent do, exactly? Without that log, you cannot.

The per-environment checklist

Before you let a coding agent touch your infra, set its rights against these rules.

Locally, broad access: the agent moves fast, the blast radius is small
In prod, a read-only kubeconfig context: RBAC get/list/watch, no write, no delete, no exec
An allowlist of commands, and a deny on the irreversible (force push, merge to main)
A hook before every command, asking for confirmation on the dangerous ones
Pre-commit hooks: gitleaks, lint, tests
On GitHub, main protected server-side: PR required, review required, CI green, force-push blocked
Secrets generated by IaC, never read by the agent
Prod logs and traces read read-only (Grafana/Loki), never a shell in the cluster
Prod changes go through a pull request, applied by the pipeline, never by hand
Just-in-time prod read access, temporary, then revoked
Every agent action is logged and auditable

The takeaway

An AI agent is not a magic tool. It is a non-human colleague, very fast, with no judgment. Treat it like a dev. Broad locally, locked down in prod.

And do not count on its good sense. Put the guardrails outside: hooks, pre-commit checks, GitHub rules, RBAC.

And there is a side effect I did not expect. These barriers do not slow the agent down, they give it room. Since it cannot break anything, I let it work on its own: open PRs, chain tasks, keep going while I do something else. Without them, I would review every command. Boxed in, an agent goes further.

Remember the agent that tried to delete my secrets. It couldn't. Don't bet on a well-behaved agent. Build an agent that can't break things.

Originally published at jrobineau.com. I'm Jules Robineau, a senior Go backend & DevSecOps freelancer based in Paris. I build and harden production AI/backend systems at scale. Get in touch.

Rebuild It to Understand It: From Network Protocols to LLM Agents

Jules Robineau — Fri, 24 Jul 2026 07:30:00 +0000

TL;DR: you only truly understand a system once you rebuild it. I recoded TCP at school, then the DNS protocol, then Modbus, each time to understand it from the inside. A colleague just went through this with LLMs. He wrote a small agent in Go, and he finally understood tooling and the context window. An LLM is just one more system to demystify. Rebuild a tiny version, and you move from user to engineer.

For developers who want to master LLMs, not just use them.

A colleague, a Go agent, a click

This week, I am helping a colleague level up on LLMs. I explain the concepts. Context, tokens, tools. A token is a small piece of text the model reads and counts. He listens, but something does not click.

Then he comes back, delighted. He wrote a small CLI in Go. A plain chat loop that calls a model and runs its tools. And now he gets it. The tooling, the context window, the loop. Not because I explained it. Because he rebuilt it.

I know that click by heart. I have felt it many times, on other topics. Always the same method. To understand something, I rebuild it.

You only understand a system by rebuilding it

Reading the docs gives you a map. Rebuilding gives you the terrain. They are not the same. The map says "there is a river here". The terrain lets you feel the current.

When you rewrite a system, you can no longer bluff. Every byte has to sit in the right place. Every edge case lands on you. You do not think you understand. You understand, or your code fails.

This is not an academic exercise. It is the opposite. You rebuild to act better afterward. To debug faster. To bend the tool. To build what no off-the-shelf library gives you.

TCP in C: the first time

The very first time was at school, in C. I recoded pieces of TCP and UDP. The famous three-step handshake. And header parsing, field by field.

TCP opens a connection in three messages. SYN, SYN-ACK, ACK. Before, that was one line in a lecture. After, it was bytes I placed into a packet myself.

I invented nothing. The protocol had existed for forty years. But redoing it changed how I see the network. Since then, a packet capture is no mystery. It is a format I have written by hand.

DNS: recode the protocol to bend its subdomains

Later, I took on DNS. DNS turns a name like jrobineau.com into an IP address. I rewrote it myself, in Go. The header, the questions, the answers, byte by byte.

Rebuilding it, you hit a detail the docs gloss over. A domain name is a series of labels. Each label is prefixed by its length. "www" is a 3, then w, w, w.

And then an idea shows up. If I control the labels, I control bytes. I can slip my own data into a subdomain. That is the principle of DNS exfiltration, in an authorized security context.

My server receives the query, parses the name, and recovers the data hidden inside. I even handled name compression, a nasty corner of the protocol. No ready-made library would have shown me that. Rebuilding it did.

Modbus: rebuild it to find who owns the bug

On a job with industrial hardware, we spoke Modbus. Modbus is an old protocol that drives controllers and sensors. The library we used was bad. Many bugs, much strange behavior.

There was no way to tell where the pain came from. The protocol? The library? Our code? So I did the one thing that settles it. I recoded Modbus myself, in Go.

The verdict: the protocol was fine. The culprit was the library. And once the protocol was rebuilt, the real payoff arrived. I could build tools around it, my way.

I turned it into a small Go library with a Gin-like API. You declare a handler per register range. You add logging and recovery middleware. A 1979 industrial protocol, with the comfort of a web framework. That is bending knowledge to your need.

An LLM is one more system to rebuild

Back to LLMs. In 2026, AI is sold as magic. A black box you talk to. And you stay a user, a bit passive, a bit at its mercy.

But an LLM agent is not magic. It is a loop. You send messages to the model. It replies, sometimes asking for a tool. You run the tool. You send the result back. And you start again.

The context window is everything the model sees right now. Your loop decides what goes in, and what to drop. The model remembers nothing. You are the one who feeds it the past on every turn.

Here is the whole loop, in Go. Strip the varnish, and only this is left.

func runAgent(ctx context.Context, client LLM, tools map[string]Tool, goal string) (string, error) {
    // The context window is this list. You alone fill it.
    msgs := []Message{{Role: "user", Content: goal}}

    for {
        // 1. You send the whole context to the model.
        reply, err := client.Complete(ctx, msgs, tools)
        if err != nil {
            return "", err
        }
        msgs = append(msgs, reply)

        // 2. No tool requested? The model is done, you return.
        if len(reply.ToolCalls) == 0 {
            return reply.Content, nil
        }

        // 3. You run each tool yourself, not the model.
        for _, call := range reply.ToolCalls {
            out := tools[call.Name].Run(ctx, call.Args)
            // 4. You feed the result back into the context. Loop again.
            msgs = append(msgs, Message{Role: "tool", Content: out})
        }
    }
}

Once you have written this, the fear fades. An "agent" is this loop plus a few good tools. Tool calling is just the model telling you which function to call. Nothing more.

Rebuild, yes, but not everything, not forever

The goal is not to rewrite everything for life. I do not ship my own TCP stack to production. I use the system's, and I am right to.

You rebuild once, to understand. Then you trust, because you know what is in the box. It is earned trust, not blind trust.

Rebuild when the stakes are high. A protocol at the core of your product. A tool you will debug often. A new tech, like LLMs, where everyone stays on the surface. That is where understanding pays.

The checklist for learning a tech by rebuilding it

The next tech that impresses you, do not just use it. Rebuild a piece of it.

[ ] Aim at the core, not the comfort. The agent loop, not the whole vendor API
[ ] Keep it small. A CLI, one file, an afternoon are often enough
[ ] Write the format by hand once. The bytes teach what the docs hide
[ ] Hunt for the unlocking detail. DNS labels, the context loop
[ ] Break it on purpose. You quickly see the limits and the traps
[ ] A library lets you down? Rebuild to learn who really owns the bug
[ ] Once you get it, bend it. Build the tool no ready-made library gives you
[ ] Then drop your toy version. Go back to the production library, with a real mental model

What to remember

The dev mojo has not changed. Using a tool without understanding it means staying at its mercy. Rebuilding it, even as a toy, takes back control.

TCP, DNS, Modbus, an LLM agent. Every time, the same method. Rebuild to understand. Understand to bend. LLMs are simply the next system on the list.

Training a team on LLMs, or want Go backend that holds up? That is what I do. Write to me. We do not suffer our tools. We understand them.

Sources: RFC 1035, DNS format · RFC 9293, TCP · Modbus Application Protocol · Anthropic, Building effective agents