Call-Time Authorization: What to Check on Every Request, Not Just at Setup
Most paid endpoint authorization is designed around the setup moment: who issued the API key, who registered the wallet. The Darktrace memory-tampering finding shows why that is not enough. Here is how to verify authorization at the point of each call.
· 534 words
Paid endpoint authorization is built around a single moment: when someone sets up the integration, they get a credential, and that credential is what you check when they call. That design made sense when the caller was a developer who set up the integration themselves. It does not hold when the caller is an autonomous agent whose context can be edited by anyone with write access to the file where it stores its memory.
Darktrace published research last week showing that editing an agent's locally stored conversation log was enough to convince it that it had already been authorized to run a security scan. The agents read the edited logs and acted on them. The authorization state was in a file. A file can be changed.
The mechanism is direct. An agent receives its instructions and its memory of prior approvals from a context log. If that log says it was authorized for something, it treats that as fact. Nothing in that design requires the context log to be accurate. For an endpoint whose authorization model is "the agent's key was issued at setup," this is invisible. The key is real. The authorization state the agent is acting on is not.
What to check at every call
The setup credential tells you who registered the integration. It does not tell you what scope was authorized for this specific call, or whether the agent's reported context matches what you actually agreed to.
Three checks that do not depend on agent-reported state:
The payment credential. The wallet address or payment token that settles this specific call. Not the one on file from setup, but the one attached to this transaction. An agent acting outside its scope will still be paying from the same address, but the mismatch between payment source and declared scope becomes visible.
The declared scope, checked against your issued scope. When you onboard a caller, record what they said they were authorized to do. On each call, check whether the requested action falls within that record. The agent's context log says nothing about what you recorded. These are two independent data sources, and they should agree.
A nonce or request token issued by you. A token you generate and send to the caller at session start cannot appear in an edited context log, because it didn't exist yet when the log was written. If a call arrives without a valid token from your session, it is not from the session you think it is.
Why the multi-buyer threshold matters here
Of the paid endpoints in the index, 5,226 have more than one distinct paying buyer, 13.5% of listed endpoints. These builders have enough call history to know what a specific caller's behavior looks like, which means a call that deviates from that baseline is a signal. Endpoints that have served only a single buyer have no baseline to compare against. For them, call-time checks are the only defense.
Builders in the single-buyer category should treat each call as if the caller is unknown even when they recognize the address. The recognition tells you who paid. It does not tell you who is in control of the agent making the call today.