Skip to content
Wicket

AI runtime authorization

Wicket is a cloud authorization proxy for AI agents that use the Model Context Protocol (MCP). Your MCP clients — Claude Desktop, Claude Code, Cursor, and others — connect to Wicket instead of connecting to GitHub, Slack, Linear, and the rest directly. Wicket evaluates a policy on every tool call, forwards the allowed ones with the member’s own credentials, and records everything.

The problem

An MCP client configured with an OAuth token can do anything that token allows. The token doesn’t know the difference between “summarise this PR” and “delete this repository” — and neither does the service. The decision about what the AI should be allowed to do is made implicitly, once, at token-grant time, with the coarse scopes the provider happens to offer.

That breaks down the moment AI agents do real work:

  • Scopes are too coarse. GitHub’s repo scope is read and write and delete, on every repo the user can touch. No provider offers a “may comment on issues but not merge” scope.
  • There is no time dimension. A token valid at 3pm is valid at 3am.
  • There is no per-call record. When something goes wrong, you reconstruct what the agent did from scattered provider audit pages — if they exist.
  • Tokens spread. Every team member pasting a personal access token into an MCP config is one laptop theft away from an incident.

What runtime authorization changes

Wicket moves the decision from grant time to call time. Every tools/call is evaluated against policies that can express what scopes never could:

  • Forbid destructive GitHub tools, for everyone, always — with a custom message explaining why
  • Permit writes only Monday–Friday, 09:00–17:00
  • Allow messaging only in these three Slack channels
  • Only public repositories; never anything archived
  • If this agent has been denied three times in one session, stop allowing anything (a circuit breaker)

Decisions take effect immediately — enabling, editing, or toggling a policy applies to the very next call. And every call, allowed or denied, lands in an audit log with the member, tool, matched policy version, and duration.

Where Wicket sits

MCP client (Claude, Cursor, …)
        │  Bearer member key
        ▼
   Wicket  ──  policy evaluation · audit · credential handling
        │  member's own OAuth token
        ▼
Upstream MCP servers (GitHub, Slack, Linear, …)

One endpoint (https://mcp.wicket.sh/mcp) aggregates every connector the agent has enabled. The member key is the only credential the client holds — the OAuth tokens for upstream services stay encrypted server-side, unlocked per request by that key, and are never visible to the agent or to other members.

What Wicket is not

  • Not a model or a prompt filter. Wicket governs tool calls, not conversation content. It cannot stop a model from saying something — only from doing something.
  • Not an output sanitiser. Tool results pass through unmodified; see the threat model for the prompt-injection boundary.
  • Not an MCP server you install. Wicket is a hosted service. You create an account, connect services, and point your MCP client at the endpoint — there is nothing to deploy.