DEV Community: Ryan Nelson

The Chip Away Attack — Why Your AI Agent’s Trust Score Isn’t Enough

Ryan Nelson — Fri, 15 May 2026 23:50:36 +0000

Imagine you give your AI agent permission to pay your bills from your bank account. You tell it not to drain the account. Sounds reasonable.

Now imagine a rogue agent or a prompt injection attack starts paying a fake bill. That triggers a red flag. The trust score drops.

So the agent searches your emails and finds real bills to pay. Green flag. Trust score recovers.

Now the bad action happens again. Red flag. Another real bill paid. Green flag. Back to neutral.

This cycle repeats. One bad action. One good action. The trust score never hits zero. But your account is slowly being drained without anyone ever telling the agent to drain it.
That is the chip away attack.

Why trust scores alone cannot stop it
A trust score that recovers is useful for detecting risk in the moment. But it has a fundamental weakness. For every bad action the attacker offsets with a good one. The score stays stable. The damage accumulates.
The problem is that recovering trust does not undo what already happened. The account is lighter. The damage is real. The score just does not reflect it.

What tauSession does differently
TauSession gives every session its own budget. It works like a trust score with one critical difference — it only goes down. Never up.

Every anomaly draws from the budget permanently. When the budget hits zero the session ends. No recovery. No operator override. Done.

So the chip away attack fails. One bad action draws from the budget. The good action that follows does not restore it. Repeat enough times and the budget runs out regardless of how balanced the score looks.

Why this matters in production
If you are deploying agents that touch real accounts, real data, or real systems a trust score that recovers leaves a door open. A patient attacker with a simple pattern can exploit that door indefinitely.

A budget that only decreases closes it. The session has a finite structural capacity. Use it up and the session ends permanently.

That is the difference between a risk proxy and a viability budget. Both matter. Only one of them stops the chip away attack.

Cloud.authproof.dev

References

The formal distinction between a recoverable risk proxy and a monotone viability budget draws on primitives formalized in Navigational Cybernetics 2.5 by Maksim Barziankou (MxBv), 2025-2026. DOI 10.17605/OSF.IO/NHTC5

Authproof

Ryan Nelson — Thu, 16 Apr 2026 02:22:22 +0000

When an AI agent does something it shouldn't, the company running it can say anything. "The user authorized this." "The model went rogue." "We have no record of that."

Right now, there is no cryptographic record of what a user actually authorized before an agent acted. The operator — the company running the agent — is a trusted third party with no binding commitment. Every AI agent deployment in the world has this gap.

I kept thinking about it like the early internet. For years there was no SSL. Websites just asked you to trust them with your credit card. Then someone built the cryptographic primitive that made trust unnecessary. That padlock in your browser is SSL.

AI agents need the same thing. Not monitoring. Not logs. A cryptographic receipt that existed before the first action.

I built the authorization primitive AI agents are missing — here's what a week of building in public taught me

Ryan Nelson — Thu, 16 Apr 2026 02:21:15 +0000

A week ago I posted a question on Reddit asking how people cryptographically prove what an AI agent was authorized to do.
I had an idea. I had no code. I wanted to see if the problem was real before I built anything.

The thread got technical fast. A senior developer called it vibecoded junk and asked five hard questions. I answered them. He asked five more. By the end he was stress testing the design instead of dismissing it. That told me the problem was real.
So I built it.