The Request That Emptied the AccountHad a Valid Key

It is a few minutes past three in the morning, and a request arrives at an API gateway somewhere in the cloud.

It is a good request. The token is valid and was issued that afternoon. The signature checks out. The format is correct to the last bracket. It is well inside the rate limit, and it looks exactly like the ten thousand requests that came before it. It asks for one customer record, and the server, doing precisely what it was built to do, hands the record over.

The only thing wrong with it is the number at the end. The caller asked for record 48213. They were only ever entitled to 48212. Nobody wrote a rule for that, because nobody could. And the machine behind the token is not going to stop at 48213.

By breakfast it has walked through the entire table, one polite, valid, perfectly formed request at a time, and there is not a single line in the logs that looks like an attack.

I know how that sounds. It sounds like an authorisation bug. Find it, fix it, move on.

But a modern organisation runs thousands of APIs, written by dozens of teams, changing every week, and increasingly called not by people but by other software. You cannot fix every door, and the doors are multiplying. So the real question is not how to write better locks. It is how to notice an intruder who came in with a valid key and behaved, on every rule you had thought to write, exactly like a customer.

Where the engineering runs out

The industry has two honest answers to that question, and both of them are engineering answers.

The first is signatures: describe the attack in advance and watch for it. That works until the attack is one nobody has described yet, which, in the example above, is the whole point.

The second is machine learning: collect months of traffic, teach a model what normal looks like, and flag whatever falls outside it. That works better, but it needs a long history of data before it can say anything, it cannot usually tell you why it raised an alarm, and it drifts as the estate changes underneath it. In the AI era there is a sharper problem still. The attacker is now often a machine as well, one that adapts faster than a model can be retrained. An arms race between two pieces of software, one of which needs a quarter’s worth of data to learn a new trick, has an obvious winner.

What bothers me about this is not that the engineering is bad. Much of it is excellent. It is that the whole contest is being fought on the attacker’s terms. Every defence is a description of behaviour, and behaviour is exactly the thing an intelligent adversary is free to change.

What an intruder cannot forge

As a physicist, here is what I see when I look at API traffic.

I do not see requests. I see a physical system. Traffic has rhythms, it has quantities that are conserved when the system is behaving as designed, and it has a measurable structure that comes from the way the underlying process works, not from any rule a developer wrote. An intruder can forge a credential. They can copy the format, respect the rate limit and mimic a customer well enough to fool any description of a customer. What they cannot do is move through that system without disturbing its physics, because the disturbance is not a choice they make. It is a consequence of what they are doing.

That reframes the whole problem. The bottleneck in API security is not that we lack rules or lack data. It is that we have been measuring the wrong quantity. We have been looking for the intruder’s behaviour, which they control, instead of the intruder’s effect on the system, which they do not.

SOTEVIS

Sotevis is what that idea became. It is our API and machine-to-machine security framework, and it is built on a simple discipline: look at the same traffic through several independent physical lenses, and trust an alert only when they agree.

Each lens sees something the others cannot. On their own, any one of them can be fooled, or can misread an unusual but harmless day. Together, they corroborate. An intruder who evades one has to evade all of them simultaneously, while still getting the job done, and that is the part they cannot control. The result is detection that catches the breaches any single method would miss, including the quiet, valid-key intrusions like the one at three in the morning.

Three consequences follow from doing it this way, and each of them answers a complaint I have heard from security teams for years.

It explains itself. Because the severity of an alert comes from measured physical effect rather than from a learned weight, Sotevis can say what it saw and why it mattered. An analyst gets a reason, not a score.

It does not need a history of attacks to learn from. There is no training set to collect, so it can be calibrated to a new estate in minutes rather than months, and it does not go stale when the estate changes.

It is auditable. Every judgement rests on quantities that can be recorded and checked afterwards, which is what a regulator, an insurer or a board actually needs when the question is “how did you know?”

I want to be precise about where Sotevis stands, because our own guiding principle is to say when we do not know. It is patent-filed, and it has been validated in simulation. We have not yet run it on a live production estate, and until we have, we will not claim more than that.

Why this is part of a bigger picture

In an earlier article I argued that every industry moving into the AI and quantum era hits three walls: secure enough, scalable enough and efficient enough, and that all three sit below the software, in physics. Sotevis is what that argument looks like at the API layer, and the API layer is where the three walls are arriving fastest.

Secure, because post-quantum cryptography will protect the channel but not the door. The three-in-the-morning request would have sailed through a perfectly quantum-safe connection; it was encrypted, authenticated and wrong. Cryptography tells you the caller is who they say they are. It cannot tell you whether they should be asking.

Scalable, because AI agents are about to multiply API calls by orders of magnitude, at machine speed, with behaviours no human has seen before. A defence that needs a human to write a rule, or a quarter of data to learn one, cannot stand in that traffic. A defence rooted in the physics of the system scales with the system, because the physics does not change when the volume does.

Efficient, because the true cost of API security today is not the tool. It is the analysts drowning in alerts that cannot explain themselves. Detection that comes with a reason attached, and that does not cry wolf every time the estate changes shape, is worth more than another dashboard.

That is what we mean when we say Physivitis works at the floor. The PQC suite measures and migrates the cryptography beneath your systems. Sotevis measures the physics of the traffic moving through them. Different layers, same method: find the quantity that actually decides the outcome, then measure it instead of assuming it.

The claim I am prepared to make

I am careful with the word “only”. So I will put it this way. To the best of our knowledge, Sotevis is the only API security framework that derives both its detection and its severity from the physics of the traffic itself, rather than from signatures or learned patterns. That is why it can work without a training set, why it can explain every alert, and why an adversary who changes their behaviour does not escape it. If someone shows me another tool that does this, I will say so publicly. Until then, that is the space Sotevis occupies.

The request, again

Go back to three in the morning. The request had a valid key. It had the right format, the right rate and the right signature, and it fooled every rule that had ever been written for that gateway.

What it did not have was a way to pass through the system without touching the physics. That is the one thing an intruder cannot forge, and it is the one thing we decided to measure.

Sotevis will run on real traffic for the first time with a small number of early partners. If you run an API estate that other machines are increasingly calling, and you would like to be one of them, I would like to hear from you.