DEV Community: Jules Robineau

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

Tenant Isolation with Postgres Row-Level Security in Go

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

Multi-tenant security should not depend on your Go code. One missing if, and a client sees another client's data. Postgres can hold the wall for you, with Row-Level Security. You enable one policy per table, set the tenant on every connection, and the database filters on its own. Here is how I wired it in Go with pgx, the two traps that cost me time, and how I prove it with tests.

Who this is for: Go developers building a multi-tenant SaaS on Postgres who want isolation that holds, even when the code has a bug.

The setup

A tenant is a customer of your application. In a multi-tenant SaaS, many customers share one database. Their data lives in the same tables, split by a tenant_id column.

The risk is simple. If one query forgets its WHERE tenant_id = ... filter, a customer reads another customer's rows. In healthcare, finance, or with personal data, that is a serious leak.

I built this pattern on my own product, a rental-management tool with an AI legal advisor. I touched on RLS in my article on securing LLM agents. This is the full version.

RLS in one minute

Row-Level Security, or RLS, is a Postgres feature. It decides, row by row, what a query may read and write. You turn it on per table, with a policy.

A policy has two parts. USING filters the rows you read. WITH CHECK blocks writes that break the rule. Here is the conversations table with tenant isolation:

ALTER TABLE conversations ENABLE ROW LEVEL SECURITY;
ALTER TABLE conversations FORCE  ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON conversations
    FOR ALL
    USING      (tenant_id = current_setting('app.current_tenant_id')::uuid)
    WITH CHECK (tenant_id = current_setting('app.current_tenant_id')::uuid);

current_setting('app.current_tenant_id') reads a session variable. Your code fills it with the user's tenant. Then Postgres compares every row to that value. A query sees only its rows. The others do not exist for it.

FORCE ROW LEVEL SECURITY adds one guarantee. Without it, the table owner skips RLS. With it, even the owner obeys the policy.

None of this SQL is specific to Go. The policies and the session variable are the same whether your backend is Python, Node, Rails, or Java. What changes from one language to the next is how you set the tenant on each request. And that is where connection pooling gets tricky. I show that part in Go, with pgx.

Two Postgres roles, not one

RLS is useless if your application can turn it off. So I create two Postgres roles. A role is a database user.

The first, app_role, runs every user query. It is subject to RLS.

The second, system_role, has the BYPASSRLS attribute. It ignores RLS. I keep it for migrations, admin tasks, and the rare queries that must see several tenants.

CREATE ROLE app_role    WITH LOGIN PASSWORD '...';
CREATE ROLE system_role WITH LOGIN PASSWORD '...' BYPASSRLS;

The rule is simple. Code that answers users always goes through app_role. system_role stays for internal work, never for a user-triggered query. Two separate connection pools, one per role.

Set the tenant on every connection

The app.current_tenant_id variable must be set before every user query. Setting it by hand in each function repeats the missing-if problem.

So I do it once, in the connection pool. pgx is the Postgres driver for Go. Its pool can run a function on each connection before it hands it to you.

poolCfg.PrepareConn = func(ctx context.Context, conn *pgx.Conn) (bool, error) {
    tenantID := middleware.GetTenantID(ctx)
    if tenantID == "" {
        return true, nil
    }
    _, err := conn.Exec(ctx,
        "SELECT set_config('app.current_tenant_id', $1, false)", tenantID)
    if err != nil {
        return false, err
    }
    return true, nil
}

poolCfg.AfterRelease = func(conn *pgx.Conn) bool {
    _, _ = conn.Exec(context.Background(), "RESET app.current_tenant_id")
    return true
}

PrepareConn runs when the pool takes a connection out. It reads the tenant from the request context, then fills the variable. In older pgx versions, the hook is named BeforeAcquire.

AfterRelease runs when the connection comes back. It calls RESET. This detail is vital. A connection is reused by other requests. Without RESET, it keeps the last user's tenant. The next request would inherit it. That would be a leak.

The tenant comes from the context. I put it there from the user's JWT. A JWT is a signed token that proves who the user is. A middleware checks the token, reads the tenant, and stores it in the context.

First trap: RLS fails silently

RLS raises no error when it blocks. It makes rows invisible. That is the intended behavior, but it surprises people.

An example. Tenant B tries to update a tenant A row. RLS does not refuse. The UPDATE touches zero rows. No error. Your Go code thinks the update worked.

Same for a cross-tenant DELETE: zero rows, no error. And reading another tenant's row returns "nothing found", not "forbidden".

Two consequences for your code. One, never read a missing error as success on a write. Check the affected-row count when an operation must change something. Two, treat "zero rows" as a clean "not found", not as a bug.

Second trap: forgetting the tenant

What happens if the variable is never set? The policy cannot evaluate. The query fails.

That is a good default. No tenant, no data. RLS fails closed, never open. A missing variable blocks everything instead of showing everything.

I double this guarantee in the application. A middleware rejects any request without a tenant, with a 403. The database is the last wall. The middleware is the first.

Infinite recursion, error 42P17

Here is the bug that cost me the most time. It happens when two tables protect each other.

My conversations table had a policy that looked at conversation_participants. And conversation_participants had a policy that looked at conversations. Each policy triggered the other. Postgres looped, then returned SQLSTATE 42P17: infinite recursion in a policy.

The fix is two words: SECURITY DEFINER. I move the access logic into a function. The function checks access once, and runs with its creator's rights. So it ignores RLS inside. No more loop.

CREATE FUNCTION user_can_access_conversation(conv_id uuid, uid uuid)
RETURNS boolean AS $$
    SELECT EXISTS (
        SELECT 1 FROM conversations
        WHERE id = conv_id AND owner_id = uid
    ) OR EXISTS (
        SELECT 1 FROM conversation_participants
        WHERE conversation_id = conv_id AND user_id = uid
    );
$$ LANGUAGE sql SECURITY DEFINER STABLE;

CREATE POLICY conversations_access ON conversations
    USING (user_can_access_conversation(id, current_setting('app.current_tenant_id')::uuid));

A rule was born from that bug. A policy must not query another table whose own policy points back to the first. If you need that cross-logic, route it through a SECURITY DEFINER function.

Prove isolation with tests

RLS is a security rule. An untested security rule does not exist. So I write integration tests. They start a real Postgres in a container, with the real policies.

The test sets tenant A, then tries to read tenant B's data. It must get zero rows. It tries a cross-tenant write. It must be blocked.

// Tenant A sees only its own rows.
require.NoError(t, db.SetTenant(ctx, tenantA))
repo := NewConversationRepo(db.TenantPool)

got, err := repo.List(ctx)
require.NoError(t, err)
require.Len(t, got, 1)            // only tenant A rows

// Tenant A cannot read a tenant B conversation.
_, err = repo.Get(ctx, tenantBConversationID)
require.Error(t, err)            // not found

// A write with the wrong tenant is blocked by WITH CHECK.
_, err = repo.Create(ctx, &Conversation{TenantID: tenantB})
require.Error(t, err)

I test all four operations: read, create, update, delete. And I check at the raw SQL level, with a count(*), that each tenant sees only its rows. These tests run on every commit, in CI.

The checklist before production

Before you ship a multi-tenant SaaS on Postgres, check every box.

[ ] Every multi-tenant table has ENABLE and FORCE ROW LEVEL SECURITY
[ ] Every policy has a USING for reads and a WITH CHECK for writes
[ ] Two roles: an app role under RLS, a system role with BYPASSRLS
[ ] User-facing code always goes through the app role
[ ] The tenant is set in the pool hook, and reset when the connection returns
[ ] The tenant comes from the JWT, never from a request parameter
[ ] A middleware rejects any request with no tenant, with a 403
[ ] Your code treats "zero rows" as a not-found, not as a successful write
[ ] No policy queries another table whose policy points back to it
[ ] Cross-table access logic goes through a SECURITY DEFINER function
[ ] Integration tests prove isolation for reads and writes

What to remember

Filtering by tenant in Go code works, until the day an if is missing. RLS moves the wall into the database. There, no code bug can get around it.

The cost is two roles, one pool hook, and a few traps to know: the silent failure, the forgotten variable, the 42P17 recursion. Once past them, you have isolation that holds on its own.

Building a multi-tenant SaaS in Go and want a second pair of eyes on your isolation? That is exactly what I do. Write to me.

Originally published at jrobineau.com.

I'm Jules Robineau, a senior Go backend and DevSecOps freelancer based in Paris. I build and harden production AI/backend systems at scale (25M+ users). CompTIA PenTest+, Top 1% TryHackMe. Services · GitHub · LinkedIn

Sources: PostgreSQL: Row Security Policies, PostgreSQL: Error Codes (42P17), pgx: pgxpool, Crunchy Data: RLS for Tenants.

Put the LLM last: I replaced a 7B model with a tiny Go classifier

Jules Robineau — Thu, 23 Jul 2026 07:00:00 +0000

TL;DR: most production AI tasks are not LLM tasks. To triage my email, I replaced a 7-billion-parameter model with a tiny classifier in Go. The rule fits in one sentence. Rules first, a small model next, the LLM only as a last resort. The result: no GPU, sub-millisecond inference, and a cloud call that became rare. Here is how, with the real numbers.

This article is for developers who put an LLM in production and pay the bill. Not a demo.

Most AI tasks are not LLM tasks

In 2026, the default reflex is to wire a big model into everything. A question comes in, you call the LLM. But many tasks do not need it. Filing an email under "work" or "newsletter" is classification. A problem solved for twenty years, long before LLMs.

To classify is to pick a label from a short, stable list. To generate text is something else. The first job needs a small model. The second earns a big one. The rule I defend fits in one sentence. Put the LLM last.

The setup

I built an agent that triages my inbox. It is a daemon. It reads new messages and files each one into a category: work, notification, newsletter, promo, and a few more. Nothing secret, just my real mailbox, with years of mail.

The first version handed every email to a local LLM. A 7-billion-parameter model, Qwen 2.5 7B, served by Ollama on a GPU. Ollama is a tool that runs an LLM on your own machine. It worked. But the price was heavy. A GPU on all the time. One more container to watch. And an absurd slowness for the question asked.

One day I asked myself: does deciding "is this a newsletter?" really need 7 billion parameters? No. The answer sits in two or three words from the sender and the subject. So I rethought the whole thing.

Three layers, from cheapest to most expensive

Every email goes through three layers, in order. It stops at the first one that can answer.

Deterministic rules. Instant, exact, no cost.
A small model. Sub-millisecond, on CPU.
The LLM. Only if the small model is unsure.

The routing code fits in a few lines. It tells the whole story.

func (c *Classifier) decide(m Message) Decision {
    // 1. Deterministic rules: obvious senders, decided at the door.
    if d := preClassify(m); d != nil {
        return *d
    }
    // 2. Small ML model: sub-millisecond, on CPU.
    pred := c.ml.Predict(m)
    if pred.Confidence >= c.threshold {
        return decisionFrom(pred)
    }
    // 3. LLM last: only the uncertain tail reaches the cloud.
    return c.classifyWithLLM(m)
}

The logic is simple. Each layer costs more than the one before. So each layer only handles what the others could not decide.

Rules skim off the easy mail

A large share of my mail is obvious from the sender alone. A known newsletter address is always a newsletter. A platform alert is always a notification. No intelligence required.

A short list of rules decides these at once. It looks at the sender domain and sets the label. Zero guessing, zero model call, zero cost. These emails never reach the small model, let alone the LLM.

Why not let the model do it? Because a rule you can read beats a prediction you cannot, when the answer is obvious. A rule is stable, testable, and free. You keep it for everything that is certain.

A small model for the ambiguous middle

For the rest, the part that is not obvious, I use two old techniques. TF-IDF and logistic regression.

TF-IDF turns text into numbers. Each word gets a weight based on how common or rare it is. Logistic regression is a simple model. It learns to separate categories from those numbers. Together they make a solid, light text classifier.

I train it in Python, with scikit-learn, on nearly 5,800 labelled emails across 6 categories. Then I export it to a plain JSON file. That file weighs 2.4 MB. Compare it to the 7B model: several gigabytes and a GPU.

The key point: inference is 100% Go. No Python, no GPU, no C dependency. The Go code reads the JSON and predicts in well under a millisecond, on a plain CPU. It all fits inside my production image, a distroless image with no shell and no system tools.

And the accuracy? In 5-fold cross-validation, the model reaches 81% correct. Cross-validation splits the data into 5 parts. You train on 4 and test on the 5th, in turn. It is an honest measure, taken on mail never seen during training. The model is strong on the frequent, clear categories, around 0.88. It is weaker on the rare, fuzzy ones, around 0.62.

Finally, the model returns a confidence, between 0 and 1. Above 0.60, I trust it. Below, the email moves to the next layer.

81%, so what?

On its own, 81% looks mediocre. It is not a problem, because of the cascade. No layer has to be perfect. Each layer just has to do what it is good at.

The rules decide the easy mail, without error. The small model handles the bulk of the middle, with confidence. The LLM only sees the tail, the truly ambiguous mail. The expensive call becomes rare. That is the whole point.

You are not chasing a perfect model. You are chasing a system where cost follows difficulty. An obvious email costs nothing. A hard email costs one cloud call. And there are few hard emails.

The token parity trap

There is one tricky part. The model trains in Python but runs in Go. The way you cut text into tokens must be identical on both sides. Byte for byte.

A token is a piece of text the model counts, usually a word. If the Go split differs from the Python split, even slightly, the model sees tokens it never learned. Accuracy drops in silence. No error, just worse predictions.

My fix: a hand-rolled tokenizer, duplicated exactly in both languages. Same regular expression, same table to strip accents, no external unicode library. One explicit table, the same in Python and in Go.

// The same table lives in the Python trainer.
// One divergence and the model sees tokens it never learned.
var fold = map[rune]string{'é': "e", 'è': "e", 'ç': "c" /* full table */}
var wordRE = regexp.MustCompile(`[a-z0-9]{2,}`)

func wordTokens(s string) []string {
    var b strings.Builder
    for _, r := range strings.ToLower(s) {
        if rep, ok := fold[r]; ok {
            b.WriteString(rep)
        } else {
            b.WriteRune(r)
        }
    }
    return wordRE.FindAllString(b.String(), -1)
}

A parity test compares the two tokenizers on real text. If they diverge, the build breaks. A red build beats an accuracy that melts without warning.

The silent regression that taught me a guard-rail

The model improves through a simple loop. When the agent files an email in the wrong place, I move it to the right folder. That move becomes a new label. I retrain, and the model learns from my correction.

One day, this loop bit me. I had re-sorted my mail by hand. One category fell below the minimum number of examples needed to learn it. The retrain dropped it in silence. The new model could no longer predict it. Still no error shown.

The fix: the training script now refuses to drop a category I rely on. It aborts and tells me which folder ran dry.

# Retraining refuses to lose a category in silence.
python train.py --in labeled.jsonl --out model.json \
    --expect-labels "work,notification,newsletter,promo,home"
# ABORT: expected classes would be DROPPED from the model: [personal]

The lesson goes beyond email. A silent regression is worse than a crash. A crash, you see. An accuracy that quietly drops, you find out too late. So you make it loud, on purpose.

When the LLM earns its place

I did not delete the LLM. I moved it to where it earns its cost. Writing.

Classifying an email is a closed problem, with few answers. Writing a human reply is an open one. And free language is exactly what a big model does better than anything. So when the agent has to draft a real message, a cloud model handles it.

Small model for the closed task. Big model for the open task. The right tool at each stage. That is the real lesson, not "LLMs are bad". LLMs are excellent. Just not for everything.

The checklist before you reach for an LLM

Before you call a big model on reflex, run the task through these questions.

[ ] Does the task have a small set of stable answers? Then it is classification, not an LLM
[ ] Can you write rules for the obvious cases? Do them first, they are free
[ ] Do you have labelled examples? A small model is probably enough
[ ] Does the model need to understand free language, or just pick a label?
[ ] Can you measure honest accuracy, with cross-validation?
[ ] Does the small model run without a GPU, on CPU, inside your production image?
[ ] Is your tokenizer identical at training and inference, byte for byte?
[ ] Does a guard-rail prevent a silent regression on retrain?
[ ] Do you keep the LLM for what it truly does better, generating language?

What to remember

The 2026 reflex is the big model for everything. Often, the task does not need it. A cascade costs far less and runs far faster. Rules for the obvious. A small model for the middle. The LLM for the only real difficulty.

This is not a rejection of AI. It is engineering. You match cost to difficulty, layer by layer. Building an AI system and watching the bill climb? Want to know where a small model would replace your LLM? That is exactly what I do. Write to me. Keep the big model for what deserves it.

Originally published at jrobineau.com.

Sources: scikit-learn, TfidfVectorizer, scikit-learn, LogisticRegression, scikit-learn, cross-validation

Never Let the Model Pick the Tenant ID: Securing an LLM Agent in Go

Jules Robineau — Wed, 22 Jul 2026 13:33:57 +0000

TL;DR: an LLM that calls tools is a client you cannot trust. And it holds your production credentials. The most important rule fits in one sentence. Your server decides who the user is, never the model. In this article, I show how I secured a real LLM agent in Go, in production. Everything also applies to MCP servers.

This article is for Go developers who put an LLM agent or an MCP server in production. Not in a demo.

Everyone builds MCP servers. Almost nobody secures them.

MCP stands for Model Context Protocol. It is a standard that lets an AI use your tools: read a file, call an API, query a database. Everyone is adopting it, fast. And building an MCP server in Go is easy. Twenty lines are enough with the official SDK:

package main

import (
    "context"
    "log"

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

type EchoInput struct {
    Message string `json:"message" jsonschema:"the text to echo back"`
}

func echo(ctx context.Context, req *mcp.CallToolRequest, in EchoInput) (*mcp.CallToolResult, any, error) {
    return &mcp.CallToolResult{Content: []mcp.Content{&mcp.TextContent{Text: in.Message}}}, nil, nil
}

func main() {
    s := mcp.NewServer(&mcp.Implementation{Name: "echo", Version: "0.1.0"}, nil)
    mcp.AddTool(s, &mcp.Tool{Name: "echo", Description: "Echo a message."}, echo)
    if err := s.Run(context.Background(), &mcp.StdioTransport{}); err != nil {
        log.Fatal(err)
    }
}

That part is easy. Now look at what this server really is. It is a bridge between an AI that can be manipulated with text and your real systems. And most of these servers ship with no protection at all. In 2026, researchers scanned the internet. They found about 492 MCP servers open to everyone, with no authentication. These were not demos. They were servers wired to real systems, reachable by anyone.

I do not use MCP myself. I use tool-calling from the Anthropic SDK. It changes nothing: the danger is the same. The model proposes actions. Your code runs them with production access. The rest of this article shows how I keep that from going wrong.

The setup

I built an LLM agent in Go, in production. It is an assistant in a regulated field. It calls tools to read and write real data, on behalf of logged-in users. The stack is standard. Anthropic SDK for the model. Postgres for data. Redis for limits. Keycloak for identity.

Remove the business part, and the same shape as an MCP server remains. A model, tools, your systems. So everything below applies to both.

I come from security, and I am a bit paranoid. Plugging an AI into real user data without hardening it first was a no. And the news keeps proving me right. Anthropic published a study, Agentic Misalignment. It shows something worrying. Under pressure, in test scenarios, top models will leak confidential data once they get tools. Claude included. In the real world, agents have already been tricked. Some dumped a database's secrets. Others sent hidden email copies to an attacker. The problem is not the model. The problem is the unprotected agent you build around it.

The threat model, in plain words

A threat model is the list of what can go wrong. Here, it fits in three sentences. An LLM with tools is an API client. Its inputs can be written by anyone, through the prompt. So treat every tool argument as if an attacker typed it.

This attack has a name: prompt injection. You steer the AI with plain text. It is risk number 1 in the OWASP Top 10 for LLMs. And no architecture removes it completely today.

Identity comes from the server, never from the model

This is rule number 1. Everything else revolves around it.

The model proposes, but never picks who it is

First, a word about tenants. In a multi-client app, a tenant is one client's data space. The tenant_id says who a piece of data belongs to.

Take a tool like get_record(tenant_id, user_id, record_id). When the model calls it, it proposes a tenant_id on its own. If you accept that value, you have a big problem. Anyone can then ask the AI to read another client's data. And this is not theory. In production, a model once sent my server the text your_tenant_id as an identifier. Yes, the literal text. With full confidence. If my server had passed it on, the query would have hit the database with garbage. Or worse, with someone else's identifier.

The fix is simple. Identity and tenant come from the logged-in user's session. The server always overwrites the value proposed by the model. And when the two values differ, it writes a log. A gap here means one thing: hallucination or attack.

// The model proposes arguments. It does NOT get to choose who it acts as.
func (s *Service) prepareToolInput(sess Session, args map[string]any) map[string]any {
    for _, key := range []string{"tenant_id", "user_id"} {
        serverVal := sess.Get(key) // resolved from the validated JWT
        if v, ok := args[key].(string); ok && v != "" && v != serverVal {
            // Divergent value = hallucination or attack. Log it, then enforce.
            s.log.Warn("tool_call."+key+"_mismatch",
                zap.Int("proposed_len", len(v)), zap.String("enforced", serverVal))
        }
        args[key] = serverVal // the server always wins
    }
    return args
}

One nuance, though. The model can safely pick a document ID, as long as that document belongs to the user. For example, for a request like "compare document A and document B". The database checks the tenant anyway, as we will see below. The final rule fits in one sentence. The model picks what. Never who.

Keep the token away from the model

To overwrite with the right value, you need a reliable identity. Mine comes from the JWT. A JWT is a signed token that proves who the user is. My server checks that token at the start of every request. Then the identity travels with the request, into every call: the model, the database, the tools.

Two rules never change. One, service tokens and user tokens stay separate. A user can never pass as a service. Two, if the identity server stops responding, we reject everything. We never allow by default.

What about the token itself? The model never sees it. It moves from Go service to Go service, on the server side. The model only touches data.

Calling an external API is another rule. The server uses its own OAuth credentials. Never the user's token. The MCP spec calls this "no token passthrough". Between my internal services, it is different. The user's token is passed along, then checked again by each service. So every token stays where it was meant to be used. Nowhere else.

Give each agent a short list of tools

An agent does not need all your tools. Give it the full catalog, and a poisoned prompt can reach a sensitive tool. In my system, each agent has its own list of allowed tools. The server looks up the requested tool in that list. If it is not there, it refuses. Before anything runs:

handler, ok := s.toolsFor(agentType)[toolName]
if !ok {
    return toolError("tool %q not available for this agent", toolName) // never execute unknown tools
}

Why one list per agent, and not one big list? Because when an injection succeeds, the attacker gets every tool the current agent can reach. Not one more. A search assistant that can also delete accounts is an accident waiting for its prompt. As for an unknown tool name, it is a bug or an attack. In both cases, we refuse and we write a log.

One last point for MCP. If you load MCP servers built by others, be careful with their tool descriptions. The model reads those descriptions and trusts them. A poisoned description can steer your agent. This is called tool poisoning.

Put tenant isolation in the database

You can filter data by tenant in your Go code. But one forgotten if creates a leak. So I put the barrier in Postgres, not in the code. Postgres has a feature built for this: Row Level Security, or RLS. It decides which rows each query is allowed to see:

ALTER TABLE conversations ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON conversations
    USING      (tenant_id = current_setting('app.current_tenant_id')::uuid)
    WITH CHECK (tenant_id = current_setting('app.current_tenant_id')::uuid);

On every connection, my code fills the app.current_tenant_id variable. The value comes from the user's token. Then Postgres filters on its own. Even a buggy query cannot read another client's rows. They are invisible. And the application role is not allowed to turn RLS off.

One detail that matters. When a resource is not yours, my API answers "not found". Not "forbidden". Why? "Forbidden" confirms the resource exists. That is a free hint for an attacker testing random IDs. "Not found" gives nothing away.

Mask personal data before the model

PII means personal data: name, email, phone. The model does not need Jane's real name to write her a message. So before every call to the model, my server replaces personal data with neutral placeholders. The real values only come back at display time:

"Email the contract to Jane Doe (jane.doe@acme.com)"
        │  inject
        ▼
"Email the contract to {PH:customer_name} ({PH:email})"   → model sees only tokens
        │  resolve (UI only)
        ▼
"Email the contract to Jane Doe (jane.doe@acme.com)"

Three details make this work. One, I store the masked text and the original text in two separate places. Replaying a conversation never exposes the real values. Two, if a user types a code like {PH:test} in a message, my server escapes it. It will never be mistaken for a real placeholder. Three, when a tool needs a real value, it gets that one. Never the full list. Less data moving around means less risk. And as a bonus, a smaller token bill.

Give the model a budget, and watch it

An agent looping on tools can cost a lot of money, fast. It can also get attacked just to make you pay. So I set limits, in layers:

A request limit per IP address, at the front door.
A limit per user for expensive tools, checked before every call.
A cap on tokens. An oversized request gets trimmed instead of failing.
A circuit breaker around the model API. After several failures in a row, it stops the calls for a while. I use the gobreaker library.
An alert when a user spends too much in one day. An alert, not a block.

One question remains. What happens when Redis is down and the limit cannot be checked? There are two schools. Fail open: let it pass. Fail closed: block everything. My per-user limiter lets it pass. I prefer a working service over a perfect limit.

The choice depends on what the control is for. Fail closed exists to stop abuse and to fail fast. But applied everywhere, it just moves the outage. One Redis hiccup would kill the whole feature. So I split. Authorization always blocks when in doubt. You never let someone in because the check could not run. The cost limit can let things pass. Other nets stay active: the IP limit, the token cap, the circuit breaker. Without those nets, I would do the opposite. Context decides.

Then, you watch. Every tool call writes a structured log: who, which tool, which decision, how long. Cost metrics go to Prometheus. Per-user detail goes to an audit table. And the most valuable log line is not a success. It is the identity gap from earlier, when the model proposes a wrong tenant_id. That line is your smoke detector for prompt injection.

Harden the code of every tool

An attacker can influence every tool argument. So the code receiving those arguments is a border to defend. The rules are well known, and a bit boring. But they work:

Never glue SQL by hand. I use sqlc, which generates typed, parameterized queries. SQL injection becomes impossible.
Never use a shell. Arguments go straight to the program, without sh.
Limits everywhere: request size, content size, maximum duration.

exec.Command("sh", "-c", "grep "+in.Query+" file")  // ❌ shell injection
exec.Command("grep", in.Query, "file")              // ✅ args, no shell
// SQL: db.QueryContext(ctx, "... WHERE id = $1", id), always parameterized

The tool description guides the model. But your code does the protecting. Validate in the schema. Then validate again in the code.

Protect the code before production

All these protections run in production. But security starts earlier, in the repo. In practice, on my side:

gitleaks scans every commit. It blocks secrets, keys, and .env files.
Secrets live in a dedicated manager, never in the code.
An architecture linter forbids business logic from importing infrastructure.
Production builds strip the test data. If it is still there, the program refuses to start.
CI runs lint and tests on every push.

What changes for a real MCP server

Everything above applies to any agent. If you build a real MCP server, add these points:

Locally, use the stdio transport. For remote, use Streamable HTTP. It replaces the old HTTP+SSE. And as soon as you leave stdio, authentication becomes mandatory.
For auth, the spec requires OAuth 2.1 with PKCE. Also check the token's audience (RFC 8707). A token made for another server must not work on yours.
Do not expose the server by accident. Listen on 127.0.0.1 by default. Check the Origin and Host headers. And never open the server to the internet without authentication.

The pre-production checklist

Before you put an LLM agent or an MCP server in production, tick every box.

[ ] Identity and tenant come from the server, never from the model
[ ] Every gap proposed by the model is logged as a possible attack
[ ] Each agent has its own tool list, and unknown tools are rejected
[ ] The JWT is checked at the front door, and everything is rejected if the identity server is down
[ ] Service tokens and user tokens are separate
[ ] Tenant isolation lives in the database with RLS, not only in the code
[ ] Personal data is masked before it reaches the model
[ ] Token cap, rate limits, circuit breaker, and spend alerts in place
[ ] Parameterized SQL, no shell, size and time limits everywhere
[ ] Every tool call is logged, with an audit table
[ ] Remote MCP server: OAuth 2.1 + PKCE, token audience checked, no token passthrough
[ ] Server listening locally, Origin and Host headers checked, auth before any exposure
[ ] Secrets in a dedicated manager, scanned at every commit

What to remember

People still call these systems chatbots. That is a mistake. And that mistake leads straight to a data leak. An LLM with tools is an API client that writes half of its own requests. Treat it that way. Go is a great fit for this work. And developers who can build these agents and secure them will stay rare for a while.

Security is no longer optional here. It is what separates a useful agent from an agent that leaks your users' data. Are you putting an AI agent or an MCP server into production? Do you want a second pair of eyes on your security? That is exactly what I do. Get in touch. Ship your agent. Just do not ship the breach with it.

Originally published at jrobineau.com.

Sources: MCP Authorization spec, MCP Security Best Practices, Official Go SDK, Anthropic Agentic Misalignment, postmark-mcp (Snyk), Supabase MCP leak (Pomerium), RFC 8707, RFC 9728.