外掛標籤
開發者團隊
原文外掛簡介
Your AI assistant needs to work in WordPress: draft posts, review content, update pages. To do that through the REST API, it needs credentials.
The built-in option, Application Passwords, was designed for humans pasting a username and password pair into an app once. AI agents don’t work that way:
Agent credential vaults store one secret, not two. Most agent platforms (including Muse’s custom connectors) have a single API-key field. An Application Password is a username plus a password — it simply does not fit, and the connection gets refused.
Application Passwords rely on Basic Auth. Many shared and managed hosts strip or block the Authorization header, so perfectly valid credentials fail with no useful error.
One leaked password pair is hard to scope. You end up handing an agent credentials tied to a real user account, and revoking means digging through profile pages.
Keypaw takes a different approach: one token, built for agents.
Generate a token in Settings → Keypaw. It is shown once; only its SHA-256 hash is stored.
Map the token to a dedicated WordPress user you choose (for example, an Editor account created just for your agent). The token can do exactly what that user can do — no more.
Your agent sends the token in a simple header (X-Agent-Token) over HTTPS. No Basic Auth, no username, nothing else to configure.
Rotate or revoke the token in one click whenever you want — the old token stops working instantly.
Agent self-discovery: the plugin publishes a small public manifest (/wp-json/keypaw/v1/manifest) describing how to connect — header name, site URL, and the mapped account’s capabilities. Point your agent at your site and it can figure out the rest.
Copy-paste setup: when you generate a token, the plugin gives you a ready-made setup snippet. Paste it to your agent and it is connected.
Security by design: HTTPS only, hashed storage, constant-time comparison, no telemetry, no external calls, and nothing is authenticated when no token is configured. The plugin adds no public write endpoints of its own — it only authenticates standard REST API requests as the user you mapped.
Born in production: Keypaw was written because an AI assistant reviewing drafts on a real site could not use Application Passwords at all. It has run that workflow daily since.
Note: if your tooling can use Application Passwords (local scripts, your own server code), they remain a fine built-in option. Keypaw exists for the growing number of agent platforms that cannot.
