API keys
Issue, scope, and rotate the keys that let external callers drive an agent.
An agent api key is how something outside the console — your backend, a script, an MCP
client — acts as an agent. Keys are prefixed plak_.
One key, one agent
A key is bound to exactly one agent. That binding is the key's entire identity: /agent/invoke
ignores any agent id in the request body, because the key already decided which agent runs.
The practical consequence is good: to give a system narrower reach, issue a key for a narrower agent. You never scope the key itself.
Creating one
In the app's Agents section, open the agent and create a key. Copy it when it is shown — it is stored hashed and cannot be displayed again.
Rotating
Create the new key, deploy it, then revoke the old one. Both work during the overlap, so rotation needs no downtime.
Revoke immediately if a key is exposed. Revocation takes effect on the next request; there is no cached grace period.
Keys belong on servers
An agent key can act on your data. It must never reach a browser, a mobile binary, or a public repository. If a key must be used by client software, put your own backend in front of it.
What a key cannot do
A key is the least-trusted principal in the system.
- It cannot approve its own agent's halted step. The initiator is never the approver.
- It cannot turn off approval. A client-supplied
autoApproveis ignored. - It cannot reach another app, or another organization's data.
- It can only stop its own runs — stopping reduces what an agent does, so it is safe to allow where approving is not.
Rate limits and retries
Keys are rate limited per key. Use an Idempotency-Key header when retrying an invoke so a
network blip joins the existing run instead of starting a duplicate.