Security · 2026-04-10
Agent Attestation Fatigue: When Too Many Trust Checks Become the Vulnerability
By J. W. Bouckaert
More checks can mean weaker checks
AI agents that act for people call APIs far more often than people do, and each call may need proof that the agent is still allowed to act. If that proof is expensive to get, engineers look for ways to get it less often. They cache a result for longer than intended, batch checks on a timer or skip them for operations that seem low risk. We call this pattern attestation fatigue: the cost of frequent trust checks leads a system to weaken them.
This article describes how it happens, the risks it creates and the design choices that avoid it.
Sources of cost
An attestation check for an agent can involve several steps: presenting a credential or token, checking a signature, looking up whether the delegation was revoked or has expired, confirming the requested scope, and recording the call. When each step needs a network round trip or a cryptographic operation, the cost per check adds up across many agents making many calls.
The cost is rarely a problem for a single request. It becomes one when an agent makes hundreds of calls in a task and each call waits on a full check.
Three ways checks get weaker
Stale cached results
The most common shortcut is to cache a successful check and reuse it. A cached result is only as current as the moment it was produced. If the delegation is revoked or its scope narrowed after that moment, the agent keeps acting on the old answer until the cache entry expires.
Predictable schedules
A system that re-checks agents on a fixed timer, such as every five minutes, gives an attacker who controls an agent a known window between checks. An action that starts 50ms after attestation has almost the full interval, close to five minutes, before the next check can catch it.
Skipped checks
Teams under pressure to reduce latency sometimes exempt operations they consider low risk. The exemption list tends to grow, and an attacker only needs one exempt operation that leads somewhere useful.
Design choices that avoid fatigue
Make the check cheap enough to run every time
If verifying an agent is a single lookup of server-held state, there is little reason to cache it. The agent presents its token, the server checks that the delegation is active, unexpired and covers the requested scope, and answers.
Keep authority on the server
When scopes and revocation status live on the server, a change takes effect on the agent's next call. When they live in a long-lived signed token the agent carries, a change takes effect only when the token expires or every verifier learns of the revocation.
Check on events, not only on a timer
A re-check triggered by what happens, such as a SIM swap on the delegating user's number, a burst of failed calls or a request for a scope the agent does not hold, removes the predictable gap a timer leaves.
Record every call, including refusals
Refused calls are evidence. An agent that keeps asking for scopes it does not have, or keeps calling after its delegation expired, should lose trust. That works only if the refusals are recorded.
Record without slowing the answer
Writing the record asynchronously keeps the check fast, so the record does not become a reason to skip the check.
Agent verification in PasskeyBridge
PasskeyBridge agent delegation follows the choices above:
- An agent presents its delegation token and, optionally, the scope it wants to use. PasskeyBridge looks up the active delegation on the server, refuses the call if the delegation is unknown, revoked or expired, and refuses a scope the delegation does not include.
- Scopes are held on the server, so revoking or narrowing a delegation applies to the agent's next call.
- Every call from a known delegate is recorded for trust scoring, refusals included: a scope the agent does not hold is recorded as a scope violation, and a call after expiry as a failure. The record is written without delaying the answer to the agent.
- The trust engine lowers a delegate's score in response to signals such as bursts of errors and scope violations. By default a delegate keeps its full scopes at a score of 0.7 or higher, is narrowed to read-only scopes below 0.7, to verify-only below 0.4, and is revoked below 0.2. A tenant can set its own levels.
- Hard signals about the delegating user, such as a SIM swap or a number port, revoke the delegation immediately, whatever the score.
With this design there is no fixed attestation schedule for an attacker to learn, and no cached result for a revocation to wait behind.
Attestation fatigue and alert fatigue
Alert fatigue affects people: operators who receive too many alerts start to ignore them. Attestation fatigue affects systems and the engineers who build them: the cost of checks leads to design shortcuts such as longer caches, skipped checks and fixed schedules. Both are fixed the same way, by making each check or alert worth its cost.