Tokening Compared With API Keys, OAuth Scopes and MCP Gateways

There are already several ways to limit what software can do with an API. Most were built for people or for long-running services. Agents need something slightly different: permission that matches one task and then disappears. Here’s how Tokening fits next to the usual options.

API keys

The default. One key, the account’s full power, valid until someone rotates it. Easy to set up and easy to leak. Fine for a script you wrote and trust. Risky for an agent that reads other people’s text and retries on its own.

OAuth scopes

Scopes narrow a token by category: read posts, write posts, manage settings. Better than a raw key, but “write posts” still means every post, as often as you like, until the token expires. Scopes describe kinds of action. They don’t describe this action on this record.

OAuth has an extension for richer requests, where a client can ask for something like “pay 45 euros to this merchant.” It’s good work, but the API’s own login server has to support it, and most APIs you’ll point an agent at don’t. Your WordPress site certainly doesn’t.

Presigned URLs and signed tokens

Cloud storage lets you sign a URL that uploads one file, under a size limit, for ten minutes. That’s very close to the grant idea, and if all your agent does is move files in and out of a bucket, use it. It just stops at storage. Token formats like Macaroons and Biscuit can carry narrowing rules too, but something still has to hold the real key and enforce them in front of your API.

Enterprise MCP gateways

Large platforms now put a policy engine in front of MCP servers. They check which agent calls which tool, sometimes down to argument values, and log everything. If your company already runs one of these, it may cover you.

They’re built on standing policies: rules that stay in force for an agent or a role. They also come as part of a managed platform or a cloud account.

Where Tokening sits

Tokening takes the per-task idea from presigned URLs and applies it to any MCP tool or REST call. The unit is a grant issued for one job, used up and gone. It holds the real credential, so the agent never needs it. And it’s one binary you run yourself, with a SQLite file and no account to create.

The trade-off is that someone has to issue grants. For a handful of agents that’s one command per task, and the quick start shows it. Grant requests that wait for a person’s approval are planned for the next version, for the cases where the agent should ask first.