case studies

Inside the Tokening WordPress Demo, Step by Step

The demo on this site is a recording, and it’s worth knowing what was recorded and how, because a demo is only as good as the checks behind it. Everything below runs with one command, make demo, and you can run it yourself.

The setup

Docker starts a fresh WordPress with three seeded posts, a database, Tokening and an agent. The agent is a short Python script, not a language model, so every run sends exactly the same calls. That makes the result something you can compare from run to run.

The containers sit on separate private networks. The agent can reach Tokening’s agent port and nothing else. It can’t open a connection to WordPress, the database or Tokening’s admin port, and the script checks that before it starts. Its environment holds two grant secrets and no passwords.

The operator side issues two grants from the same template: wp_update_post on post 2, title and content only, one use, fifteen minutes. One grant is for the main run, the other for the race at the end. Before the agent starts, the script records the posts as they are.

The calls

The agent connects over MCP and asks for its tools. It gets back one: wp_update_post. Then it works through a fixed list.

  1. Change post 2’s title to “Scoped edit”. Allowed. One use spent, WordPress accepts it.
  2. Send the same call again. Refused: “allowed 1 use and has none left.”
  3. Change post 3’s title. Refused: “Grant is bound to id 2; call sent id 3.”
  4. Call wp_delete_post on post 2. Refused: “Grant allows wp_update_post; call asked for wp_delete_post.”
  5. Two threads wait at a barrier and send the same edit on the second grant at once. One allowed, one refused.

The script stops with an error if any decision differs from what’s expected.

The checks afterwards

Calls that look right aren’t enough, so the operator reads WordPress directly. Post 2 must have the title from the winning parallel call and its original body. Post 3 must still have its seeded title. All three posts must exist. A small counter plugin must show exactly two writes and zero deletes.

Then it reads Tokening’s audit log and checks it agrees: two allowed calls, two linked WordPress results, four refusals. Both grants must show zero uses left. Finally it searches the replay data, the HTML page and the audit export for the grant secrets, and fails if one turns up.

The replay

Only then does it build the replay you see on this site. The replay is one HTML file with the recorded data inside. It shows the grant, the request behind each step, the decision and reason, and the post as it changes. It makes no network requests, and its content security policy blocks them anyway. The same file ships with every release.

The demo is built into Tokening’s CI, so it runs on every change to the code. If a refusal stops happening, the build goes red.