Governance Keys: Two Ways to Govern an Agent
A governance key plugs your agent — or a whole platform — into Clevername's runtime governance. Choose per-agent (one policy for the whole key) or per-platform (each skill governed separately above a shared floor), and scope which MCP servers each skill may reach.
The one idea to hold on to
A governance key (a cnk_token) is not a provider key — it supplies no compute. You paste it into your agent client, and every skill and tool call your agent makes flows through Clevername, which enforces what the agent is allowed to do. There are two waysto attach that governance, and the only question is what's holding the key: a single agent, or a platform that runs many skills. The distinction is not “one key vs. many keys” — it's where the policy attaches.
Model A — one key per agent
The agent is the unit. One key maps to one governed agent, and a single policy governs everything that agent does. Every call it makes is checked against that one policy. This is the simplest model: one identity, one set of rules. Use it when the thing you're governing is a single agent doing a single job.
Model B — one key per platform
The skills are the units. One platform (OpenClaw, an n8n instance, a custom crew) holds a single key, but each skill it runs is governed separately. Everyskill__<name> call is routed by name to its own governed identity with its own learned policy. A shared base floor— the policy of the agent that holds the key — covers anything that isn't a recognized skill. Use it when one runtime runs many distinct capabilities you want governed independently: you can lock one skill down hard while another under the very same key is still being learned.
What actually changes between them
| Model A · per agent | Model B · per platform | |
|---|---|---|
| Unit of governance | The agent | Each individual skill |
| How many policies | One, for the key | One per skill, plus a shared floor |
| Who holds the key | A single agent | A platform running many skills |
| How a call is routed | Straight to the agent's policy | By skill name → that skill's policy |
| Tighten one capability | Affects the whole agent | Affects only that skill; others untouched |
| A new capability appears | Still under the one policy | Auto-onboarded as its own governed skill |
Where each skill's policy comes from
Under a platform key you don't write a policy per skill up front — each skill earns one by being watched. The lifecycle runs independently for every skill:
- Auto-onboard. The first time the platform calls a skill under a key that already has per-skill governance on, Clevername creates a skill agent for it automatically. You never hand-create one (though you can).
- Observing.While learning, that one skill runs under the shared base floor — never wide-open, never a hard wall — and accumulates real examples of how it's used. The dashboard shows an amber Observing N/10 badge with a progress bar.
- Governed.After about ten uses it compiles a policy from what it saw — a tool allowlist, a block list for the obviously dangerous, and prompt-injection and PII scanning — and enforces that instead of the floor. The badge flips to a green Governed.
Scoping MCP servers per skill
Just as a regular agent can be restricted to specific MCP servers, each skill under a platform key can be scoped to only the servers it needs. Assign a skill's allowed servers, and a call to any other server is blocked at the gateway, fail-closed — without affecting the other skills under the same key. A skill with no servers assigned gets first-party tools only. This lets acode-review skill reach your Git server while a research skill under the same key cannot.
What governance keys don't do
- They don't supply compute. Your agent still uses its own provider key (BYOK). Clevername never runs the model.
- They don't run your agent. Clevername sits on the call path, not in the driver's seat.
- They govern what flows through the gateway — the skill call and MCP tool calls that pass through Clevername — not what your agent does with a purely local tool on its own machine that never reaches the gateway.
Create an agent — it becomes the base floor
Create an agent as usual; its governance key (cnk_…) is issued automatically. Under a platform key, this agent's policy is the shared floor that not-yet-graduated skills run under.
Turn on per-skill governance
On the agent's key row, expand Skill agents and choose Enable per-skill governance. This is the switch that turns Model A into Model B — the one key now governs each skill separately.
Install the skills the platform will use
From the agent's Edit Access → Skills or the integration directory, install the skills your platform will call. Only installed skills are offered to the platform. (See Skills for authoring your own.)
Scope MCP servers per skill (optional but recommended)
For each skill under the key, set the MCP servers it's allowed to reach. Leave a skill unscoped to fall back to the base floor's servers, or lock it to a specific set. Assignments are enforced fail-closed at the gateway, per skill.
Point your platform at the key
Add Clevername as an MCP server in your platform's config, using the governance key as a bearer token. For OpenClaw the block goes under mcp.servers and must set the streamable-http transport:
{
"mcp": { "servers": {
"clevername": {
"url": "https://clevername.net/api/hub/mcp/gateway",
"transport": "streamable-http",
"headers": { "Authorization": "Bearer cnk_your_key_here" }
}
} }
}"transport": "streamable-http" and OpenClaw falls back to SSE and silently fails; and the config key is mcp.servers, not mcpServers.Run it, and watch each skill graduate
Run your platform normally. Each skill appears under Skill agents in observation mode and climbs its own N/10 counter, flipping to Governed independently. Nothing to press.