Skip to content
Wicket

Trust model

Wicket’s access model has three layers: accounts (people who sign in), agents (AI identities people belong to), and member keys (what MCP clients hold). This page explains who controls what, and the trusted/untrusted distinction that changes how policies apply.

Roles

CapabilityOwnerMember
Enable connectors, set OAuth app credentials✅—
Create, edit, toggle policies✅—
Invite, approve, reject, remove members✅—
Disable the agent (kill switch)✅—
View the full audit log incl. policy identities✅own activity, policy identities redacted on trusted agents
Connect own OAuth accounts✅✅
Generate / rotate own member key✅✅
View other members’ keys or tokens——

The last row is the heart of the model: nobody — not even the owner — can see a member’s key or OAuth tokens. Keys are shown once at generation and never stored; tokens are encrypted under a key derived from the member key. What the owner controls is authorization (policies, membership, the agent switch), not credentials.

Membership lifecycle

invited ──► signs in with invited email ──► connects services ──► pending
pending ──► owner approves ──► approved ──► generates key ──► proxying
        └─► owner rejects ──► rejected (connections discarded)

Invites are signed links valid for 7 days, bound to one email address. Removing a member invalidates their key immediately — no rotation ceremony needed. Individual invites can also be revoked before they’re used.

Trusted vs untrusted agents

Every agent has a trust mode, chosen at creation:

TrustedUntrusted
Policy setOne, agent-wide — every member is governed identicallyPer member — each member has their own policy set
FitsA team sharing one assistant configurationExternal contributors, contractors, graduated rollouts
Audit visibility for membersOwn activity, with the owner’s policy identities redactedOwn activity
Failure posture—Fail closed: if no per-member policies resolve for a request, the call is denied

The fail-closed rule on untrusted agents is deliberate: a member with no explicit policy assignment can do nothing, rather than inheriting whatever a default would allow.

What a stolen member key can do

A member key is scoped to one member of one agent. A thief holding it can:

  • Call exactly the tools that agent’s policies permit for that member — nothing more
  • Generate audit entries attributed to that member (which is how you’d spot it)

They cannot reach other agents, see other members, extract the underlying OAuth tokens, or touch the dashboard (which uses a separate session sign-in, optionally with MFA). Response: remove the member or rotate the key — both take effect on the next call. See the threat model for the full credential security analysis.

Boundaries to keep in mind

  • The owner is trusted. Owners author policies and approve members; a compromised owner account can loosen both. Protect owner accounts with MFA.
  • Policies govern calls, not content. What a tool returns flows back to the client unfiltered.
  • Each member’s blast radius is their own OAuth grant. Wicket enforces policy on top of — never beyond — what the member’s own token can do upstream.