Most of my API accepts small JSON payloads, so a strict global limit is a sane default. File uploads need a couple of orders of magnitude more. And the obvious solution – overriding the limit with another middleware on that route – fails in exactly the same way. Silently.

A production agent is a long-running, concurrent, I/O-bound process that spends most of its time waiting on a model, a tool, or a human. That shape fits Go's runtime. This post explains why, surveys the Go framework options, and shows how to build an agent without one.

Gopls includes an experimental built-in server for the Model Context Protocol (MCP), allowing it to expose a subset of its functionality to AI assistants in the form of MCP tools.

HASP is a local secret broker for coding agents.

Agents need credentials to run tests, call APIs, and deploy code. Copying those credentials into prompts, shell history, .env files, or repo-local notes makes the agent faster today and harder to trust tomorrow. HASP keeps secrets in a local encrypted vault and gives commands only the values they are allowed to use at runtime.

The core rule is:

Managed secret values must not enter agent context.

Model router for agentic systems. Routes every prompt to the right model in <50ms. Cut costs 40-70% with just an endpoint change.

TL;DR: Shard your locks. A 256-way striped map (sharded) was the all-around winner — up to 8× faster than a single sync.Mutex at 8 cores — and it’s about 15 lines of code. sync.RWMutex, the reflexive fix for “reads are contended,” is a trap: it barely helps reads past two cores and is slower than a plain mutex for writes.

Let’s talk about nil pointer checks in Go. You want to prevent panics in production, but that doesn’t start with a deferred recover. It starts with defensive programming. Check your inputs, check your bounds, and check pointers for nil before dereferencing them.

I’ve started to see more nil checks in Go code. In the right place, they are necessary for writing safe code. In the wrong place, they are a sign that the code has stopped being clear about what can and cannot be nil. I have noticed this pattern more in generated code, but this symptom is not new and is not limited to AI.

When a nil check is cheap and prevents a panic, why not add it? Your reflex may be, let’s just be safe. But the check also tells the next reader something, and often the wrong thing.

I ran into the classic “range over a channel” leak while working on a custom cron scheduler. I’ve debugged it on prod many times before, but writing one myself in a small piece of code reminded me how easy it is to write bugs like this even when you know about it.

We have a giant test suite at work, mostly in Go. The test coverage is great, but it means that it's not that fast to run, and it only will get slower over time as new tests are added. Almost every test needs a pristine database. We are spending a ton of CPU time just applying again and again the same SQL migrations at the start of each test.

What happens if I just point a git server at an object storage bucket?
Back when I was porting agent sandboxes to Go, I built everything on top of billy, a filesystem abstraction for Go. The whole trick of the project was teaching a Tigris bucket to act enough like a filesystem that a shell interpreter and its tools couldn’t tell the difference. Billy was the key layer that made the entire façade fall into place.

After I had gotten things working, I learned that I’m using billy way outside its normal usecase. It was originally made for go-git, a pure-Go implementation of git’s protocols and data formats. It doesn’t rely on the /usr/bin/git binary existing at all. Every method on billy’s filesystem interface exists purely because go-git needs it. This gave me a terrible idea: I already have a bucket that can quack like a filesystem and go-git’s native language is “filesystem”.

Can this Just Work™? Let's find out.

A fault-tolerant, API-agnostic RPC load balancer for blockchain APIs.

How to make systemd run a Go HTTP service only when needed to save cpu/memory.

Our 64-bit Intel and AMD processors have evolved over decades. When you compile a Go program for a 64-bit Intel or AMD processor, the compiler targets, by default, a nearly 20-year-old instruction set. The binary that comes out runs on essentially any x64 chip, but it also leaves on the table every instruction that was added since 2003.

A couple of years ago we published a blog post with the intention to create a resource that code auditors and security-minded engineers can refer to when auditing or developing Golang projects.
In that post we covered some bug classes that we have often seen during our own Golang code auditing projects.

Thanks to the second law of thermodynamics time only keeps moving forward, and as any decently supported modern programming language, Go has seen a lot of changes and improvements since our first blog post.

So we decided to create this follow-up post with the same idea in mind.

Since out first post, automated tooling and AI assistants have raised the floor for code review: a lot of the obvious bugs now get caught on the first pass, by anyone. But that floor is also where most reviewers stop, because the tooling stops there too — the rules only flag what they already know to look for. What separates an experienced auditor is knowing the language's sharp edges that no rule covers yet, and going looking for them deliberately.

In this post, first we will start with a quick look at what changes have been made to the language to make security easier and more intuitive for folks (with no particular selection criteria on what we're going to cover).

Then we have a bunch of new footguns we would like to highlight, hopefully to the benefit of everyone auditing or developing Golang projects.

Finally, we are also releasing a couple of semgrep rules to close the gap regarding these risky coding patterns.

The rules can be found in our Semgrep rules repository.

With the introduction out of the way, first let's see what are some of the features that were introduced Golang with a major impact on its security landscape.

If you've ever needed your script or your Go program to read the SSID, BSSID, signal strength, or channel of the Wi-Fi network a Mac is on, the last two years have not been kind.

One interesting compiler directive is linkname, which allows us to declare a symbol in one package, which happens to be an alias for a symbol in another package. The symbol to which we link can even be an unexported symbol, allowing us to break the encapsulation rules as a whole and make a package-internal symbol exported via another symbol in a different package.

Golang is often touted as a “simple” language by design, deliberately eschewing features that would add complexity. The language design is openly opinionated but avoids baking those opinions into the spec. It’s why core design patterns like errors and context objects are implemented in the standard library instead of being built into the language. While special syntax for these types could decrease boilerplate, it would also make the language more complex in a way that violates the design philosophy of the language.

The language designers would argue that there’s elegance in simplicity. That Golang doesn’t need special cases.

But that’s not the complete story. It turns out that Golang actually does have “special cases” in order to allow for behavior that can’t otherwise be expressed in the language.

Today we’re going to look at some of those special cases.