Agent Key Binding
Keys can be scoped to specific agents so that each agent only has access to the keys it needs. Bindings are created automatically during interception or manually through the dashboard.
What is agent key binding?
Agent key binding means that a specific API key is assigned to a specific agent. When that agent makes an AI call, Clevername uses the bound key — not your default key, and not any other agent's key. This is scope isolation: Agent B cannot use Agent A's keys, even if both agents belong to the same user.
Why it matters
- Least privilege — each agent only accesses the keys it needs
- Cost isolation — track spend per agent by using separate provider keys
- Blast radius — if a key is compromised, only the bound agent is affected
- Compliance — auditors can verify exactly which key was used by which agent
How binding resolution works
When an agent needs a provider key, Clevername checks in this order:
- Is there a key explicitly bound to this agent for this provider? Use it.
- Is there a default key for this provider on the user's account? Use it.
- No key found — the request fails with a clear error.
Explicit bindings always take priority over default keys. This means you can set a default OpenAI key for general use, but bind a specific OpenAI key to a high-traffic agent for separate billing.
Automatic binding during interception
When a key is intercepted in an agent's session, the key is automatically bound to that agent. For example, if Agent A's session contains a pasted OpenAI key and you choose to store it, the key is saved and bound to Agent A in a single step.
Manual binding from the dashboard
Open the agent's detail page (Agents → [Agent]) and use the Bound Provider Keys panel. Select a provider and choose which stored key to assign. Stored keys themselves are managed at Dashboard → Settings → API Keys.
Binding via MCP tools or API
For automation, use the gateway tools keys__bind_agent, keys__list_agent_bindings and keys__revoke_binding, or the REST API below. This is useful for provisioning agents at scale — for example, binding a dedicated key to each agent in a department.
Managing Bindings
You can view, modify, and revoke bindings from the dashboard or the API.
| Action | Dashboard | API / MCP |
|---|---|---|
| List bindings | Agent detail page > Bound Provider Keys panel | GET /hub/keys/agent-bindings/{agent_id} |
| Create binding | Bound Provider Keys panel > choose provider and key | POST /hub/keys/agent-bindings (requires a passkey/AAL2 session) |
| Revoke binding | Revoke next to the binding in the panel | DELETE /hub/keys/agent-bindings/{binding_id} |
| Reassign key | Revoke the old binding and create a new one | DELETE the old binding, then POST a new one (there is no PUT) |
Bindings and the Agent Review
When an agent goes through review approval, its key bindings are captured as part of the integration bindings fingerprint. This means:
- •Changing an agent's key bindings after approval triggers drift detection. The agent must be re-reviewed before redeployment.
- •Reviewers can see which keys are bound during the review process, giving them visibility into what resources the agent will access.
- •Revoking a binding on an active, review-approved agent puts it into a resubmit_required state.