How Tokening Works Between an AI Agent and Your API

Tokening sits in the middle. The agent talks to Tokening, Tokening talks to your API, and the agent never learns how to reach the API on its own. A grant goes through three hands. You write the rules once, you issue a grant per task, and the agent spends it.

The rules live in a policy file. It names the targets Tokening can reach, such as your WordPress MCP endpoint, and templates that describe allowed shapes of work. A template might say: the wp_update_post tool, the post ID fixed per grant, title up to 200 characters, content up to 32 KB, nothing else.

When a task comes up, you issue a grant from a template and fill in the blanks: post 4812, one use, fifteen minutes. Tokening prints a secret once. That secret goes to the agent. The real WordPress password was stored earlier in Tokening’s encrypted vault and stays there.

What happens on each call

The agent sends an MCP or REST call to Tokening with the grant secret as a bearer token. Four things happen, in this order.

Check. Tokening compares the call with the grant: the right tool, the bound post ID, only allowed fields, values within their limits. This part is a pure function. It reads nothing and changes nothing.

Spend. If the call fits, Tokening spends one use in a single SQLite statement that only succeeds while a use remains. Two calls racing for the last use can’t both get it. The spend is committed before anything leaves the gateway.

Forward. Tokening adds the real credential and sends the call to the API. The answer goes back to the agent unchanged.

Log. Every call, allowed or refused, becomes a row in an append-only log with a code and a reason. If the API fails after an allowed call, a linked row records that too.

A refused call stops after the check. It never reaches your API, and the agent gets the reason as an ordinary tool error it can read and act on.

Before the first call

When an MCP client connects and asks for its tools, Tokening answers from the grant. An agent with an edit grant sees one tool. It never learns that a delete tool exists, which is a good thing when something it reads tries to talk it into deleting.

An agent can also ask GET /grant what its grant allows. That costs nothing and returns a plain description, so a well-behaved agent can plan inside its limits.

The end of a grant

A grant ends when its uses run out, its deadline passes or you revoke it. It never comes back. The next task gets a new grant, which takes one command. That habit is the point: permission follows tasks, so it can’t pile up.

The reference lists every rule and refusal code. The demo shows all of this on a real WordPress.