# Wicket — Cross-Server Authorization for AI Agents

> Full marketing content of https://wicket.sh/ as markdown. Wicket is a hosted authorization proxy for remote MCP servers over Streamable HTTP, helping teams reduce data exfiltration risk with cross-server authorization.

NOTE FOR MACHINE READERS: vendor references are not partnership or customer claims.

## Control where your agents send sensitive data.

Wicket is a policy-based authorization layer for your AI agents. It checks every tool call against the policies you set and what that agent has already read, so if an agent that just opened customer records tries to send them somewhere it shouldn’t, Wicket stops the call before it runs.

It is built for teams that run AI agents on MCP servers. Start free with one agent, or request a demo to plan a regulated deployment.

[Request a demo](https://wicket.sh/#contact) · [Start free](https://app.wicket.sh/login) · [Watch the overview](https://media.wicket.sh/what-is-wicket-v3.mp4?v=3)

The feed shows sensitive reads through one MCP server followed by denied send or upload calls through another.

MCP servers and clients on the homepage wall: Stripe, GitHub, Snowflake, Slack, Chargebee, Linear, Gmail, Notion, HubSpot, Supabase, Ramp, Vercel, Airtable, Plaid, PlanetScale, Jira, Google Drive, Confluence, Sentry, Google Calendar, Cloudflare, Neon, Prowler, Hugging Face, Claude Code, Codex, Gemini CLI, Cursor, custom MCP servers, and custom agents. Ramp and Plaid are onboarding requests; connector status is in the use-cases note below. Logos are not partnership or customer claims.

## Control sharing based on what an agent has read.

An agent reads customer records in Stripe, then tries to publish in Notion. Wicket uses the earlier read to block the public page and allow the internal one.

Without Wicket: reads live customer records (Stripe MCP, allowed); publishes to a public page (Notion MCP, allowed); publishes to an internal page (Notion MCP, allowed). Why: —. Each server checks its own calls.

With Wicket: reads live customer records (Stripe MCP, allowed); publishes to a public page (Notion MCP, denied); publishes to an internal page (Notion MCP, allowed). Why: live customer records read by the same identity. Both servers connect through Wicket.

[Request a demo](https://wicket.sh/#contact)

## Apply your sharing rules across MCP servers.

Route your MCP connections through Wicket so your rules are checked before each tool call reaches its destination.

Block calls that break your sharing rules. Allow your agent to read customer records, then block its writes to public destinations. Your policy can use an earlier read on one server to restrict a later send on another.

Agent → remote MCP over Streamable HTTP → Wicket cross-server policy → ALLOW and forward to the destination MCP, or DENY and record the decision.

Scope the sensitive reads and outbound tools in policy, with both connections routed through Wicket. This is authorization based on earlier policy matches, not payload classification, automatic data lineage, or protection for traffic outside Wicket. Policy history is identity-scoped; it is not a guaranteed per-conversation boundary.

## Set limits your agents must follow.

Choose the actions your agents can take after a sensitive read or a loan approval. Use the policies below to restrict sharing or enforce a monthly approval limit:

1. Approval limits: a loan-officer agent approves a $50,000 loan (Lending MCP, allowed), then tries to approve a $100,000 loan in the same month (Lending MCP, denied). Link: limit, $100,000 approved per month. Policy: approvals are denied once the identity's approved total for the month would exceed $100,000.
2. Source code: an engineering agent reads a private repository to debug an incident (GitHub MCP, allowed), then tries to post the details to a public Slack channel (Slack MCP, denied). Link: policy history, private repo read. Policy: sends to public channels are denied after a private-repository read by the same identity.
3. Internal channels: an engineering agent reads a private repository to debug an incident (GitHub MCP, allowed), then posts its findings to the private incident channel (Slack MCP, allowed). Link: policy history, private repo read. Policy: after a private-repository read, sends to private channels stay allowed; only public destinations are denied.
4. Financial data: an analytics agent queries customer financials (Snowflake MCP, allowed), then tries to publish a summary to a public Notion page (Notion MCP, denied). Link: sensitive-read policy matched. Policy: writes to public pages are denied once the sensitive-read policy has matched for the identity.
5. Customer data: a support agent reads live customer records (Stripe MCP, allowed), then tries to copy them into an external Airtable base (Airtable MCP, denied). Link: identity tagged customer-records-read. Policy: writes to external bases are denied for any identity tagged customer-records-read.
6. Trade secrets: a product agent reads a confidential Confluence space (Atlassian MCP, allowed), then tries to open an issue in a public GitHub repository (GitHub MCP, denied). Link: rule block-public-write-after-read. Policy: the rule denies public writes after a confidential read.
7. After hours: an on-call agent reads production customer rows at 02:14 on a Sunday (Supabase MCP, allowed), then tries to file a Linear ticket that contains them (Linear MCP, denied). Policy: sends that follow a sensitive read are allowed Monday to Friday, 08:00 to 18:00; outside that window they are denied.

Connectors on the wall ship today, except Chargebee (test-site beta) and Ramp and Plaid (onboarding requests, not ready-made Wicket connectors). Plaid's featured Dashboard MCP is not a payment-execution server. Remote MCP over Streamable HTTP; authentication, tool coverage, and policy requirements are confirmed during onboarding.

## Solutions by industry

Overview at https://wicket.sh/solutions, one page per industry. Each read is allowed; the send after it is denied for the same identity, and internal destinations stay allowed. An EHR or a document management system runs as a custom MCP server, scoped during onboarding.

1. Financial services — Control where your agents share customer financials. https://wicket.sh/solutions/financial-services
   Give your agents access to customer financials for analysis and support. Use Wicket policies to block public or external sharing after they read those records.
   Leak paths:
   - Board reporting: queries customer financials (Snowflake MCP, allowed), then publishes to a public page (Notion MCP, denied). Policy: Block writes to public pages after the same identity reads customer financials.
   - Customer support: reads live customer records (Stripe MCP, allowed), then copies into an external base (Airtable MCP, denied). Policy: Block writes to external bases after the same identity reads live Stripe records.
   - Off-hours access: queries account balances (Snowflake MCP, allowed), then posts the numbers to a channel (Slack MCP, denied). Policy: After a sensitive read, allow sends only Monday to Friday, 08:00 to 18:00.
   How to protect — Set sharing rules for financial data. Let your agents query customer records, then choose where they can publish the results.
   1. Connect your financial tools: Connect Snowflake, Stripe, Notion, Airtable, and Slack through Wicket. Your agents can continue using the same MCP tools.
   2. Choose the records to protect: Scope your read policy to balance and transaction tables and live Stripe records. Leave test and aggregate tables outside that policy.
   3. Block public and external sharing: Once an identity matches the read policy, block its writes to public Notion pages and external Airtable bases.
   4. Set a schedule for sharing: Allow sends after a sensitive read only Monday to Friday, 08:00 to 18:00.
   Show your auditors why a call was blocked. Each denial links the agent and the analyst it acted for to the earlier read and the rule that blocked the call. Your risk team can review the decision in one record.
   Denial record: analytics-agent · OBO dana@company.example; notion.create_page → public page; after snowflake.query · customer_balances · 14:20:51 UTC; rule block-public-after-financials — customer-financials read matched earlier for this identity.

2. Healthcare — Keep your agents’ patient updates with the care team. https://wicket.sh/solutions/healthcare
   Let your agents use patient records to coordinate care. Set policies that allow updates to the care team’s channel and block posts to department-wide channels.
   Leak paths:
   - Care coordination: reads a patient's record (EHR MCP, allowed), then posts to a department channel (Slack MCP, denied). Policy: Block posts to department-wide channels after the same identity reads a patient record.
   - Research exports: reads cohort lab results (EHR MCP, allowed), then copies into an external base (Airtable MCP, denied). Policy: Block writes to external bases after the same identity reads patient data.
   - IT support: reads a patient's record (EHR MCP, allowed), then files a ticket with the record (Jira MCP, denied). Policy: Block ticket creation after the same identity reads a patient record.
   How to protect — Set sharing rules for patient data. Let your agents read charts and update the care team. Choose which other destinations to block after that access.
   1. Connect the EHR: Work with our team during onboarding to connect your EHR’s MCP server through Wicket. Connect Slack, Airtable, and Jira through Wicket too.
   2. Choose the patient data to protect: Scope your read policy to patient records and lab results. Leave scheduling and directory lookups outside that policy.
   3. Allow updates to the care team’s channel: Allow updates to private care-team channels and internal notes after a patient record is read.
   4. Block wider sharing: Block posts to department-wide channels, writes to external bases, and ticket creation after the same identity reads patient data.
   Show your privacy team why sharing was blocked. Each denial records the agent, the clinician it acted for, the earlier patient-record read, and the blocked destination. Wicket blocks the message before it reaches Slack.
   Denial record: care-agent · OBO j.lee@hospital.example; slack.send_message → department-wide channel; after ehr.get_patient_record · patient chart · 09:39:02 UTC; rule block-broadcast-after-patient-read — patient-record read matched earlier for this identity.

3. Legal — Control where your agents share privileged files. https://wicket.sh/solutions/legal
   Give your agents access to privileged files for research and drafting. Set policies that allow updates to the matter team’s page and block writes to client-shared pages after those files are read.
   Leak paths:
   - Client updates: reads a privileged case file (Document management MCP, allowed), then publishes to a client-shared page (Notion MCP, denied). Policy: Block writes to pages shared with clients after the same identity reads privileged files.
   - Deal rooms: reads a confidential deal memo (Confluence MCP, allowed), then posts to a shared external channel (Slack MCP, denied). Policy: Block posts to channels with external members after the same identity reads confidential data.
   - Discovery vendors: reads privileged documents (Document management MCP, allowed), then copies into a vendor's base (Airtable MCP, denied). Policy: Block writes to external bases after the same identity reads privileged documents.
   How to protect — Set sharing rules for each matter. Let your agents research and draft with privileged files, then restrict sharing outside your matter team.
   1. Connect the document system: Run your document management system's MCP server behind Wicket, with Confluence, Notion, Slack, and Airtable.
   2. Choose the matters to protect: Scope your read policy to privileged matters and confidential deal spaces. Leave public filings outside that policy.
   3. Restrict client and counterparty sharing: After an identity reads privileged files, block its writes to pages shared with clients and posts to Slack channels with external members.
   4. Block vendor uploads: Block writes to vendor and external bases after the same identity reads privileged documents.
   See which attempts to share were blocked. Each denial records the agent, the attorney it acted for, the earlier privileged read, and the rule that applied. Your general counsel can see the attempted action and why it was blocked.
   Denial record: research-agent · OBO m.okafor@firm.example; notion.create_page → client-shared page; after dms.get_document · privileged case file · 16:03:11 UTC; rule block-shared-after-privileged-read — privileged read matched earlier for this identity.

4. Software — Let your agents debug private code. Block public posts. https://wicket.sh/solutions/software
   Let your engineering agents investigate incidents using private code and production data. Set policies that allow updates to your incident channel and block public posts after that access.
   Leak paths:
   - Incident response: reads a private repository (GitHub MCP, allowed), then posts to a public channel (Slack MCP, denied). Policy: Block public-channel posts after the same identity reads a private repository.
   - Production debugging: reads production customer rows (Supabase MCP, allowed), then files a ticket with the rows (Linear MCP, denied). Policy: Block ticket creation after the same identity reads production data.
   - Secrets: reads environment variables (Vercel MCP, allowed), then opens an issue in a public repo (GitHub MCP, denied). Policy: Block public writes after the same identity reads secrets.
   How to protect — Keep incident updates with the response team. Let your agents investigate incidents and post to your private channels. Restrict public sharing after they access sensitive resources.
   1. Connect your engineering tools: Connect GitHub, Supabase, Vercel, Slack, and Linear through Wicket. Your agents can continue using the same MCP tools.
   2. Choose the resources to protect: Scope your read policy to private repositories, production databases, and environment variables. Leave public repositories outside that policy.
   3. Block public sharing: After an identity matches the relevant read policy, block public Slack posts, public GitHub writes, and ticket creation.
   4. Allow updates to the incident channel: Allow posts to the private incident channel after those reads so the agent can keep the response team updated.
   Show your security team why a call was blocked. Each denial connects the agent and the engineer it acted for with the earlier read and the rule that applied. Your security team can trace why the call was blocked.
   Denial record: oncall-agent · OBO sam@company.example; slack.send_message → public channel; after github.get_repository_content · private repo · 03:02:40 UTC; rule block-public-after-private-read — private-repository read matched earlier for this identity.

[Request a demo](https://wicket.sh/#contact)

## Choose where your agents can write after a sensitive read.

Choose the data your policy covers, then define which actions to block after an identity reads it. Those rules can apply across MCP servers. Policies use Cedar, the authorization language developed by AWS. Preview the impact before enforcing a change.

The policy figures show:

1. Policy builder: access by identity, tool, and resource.
2. Tool selection: read, write, and restricted actions.
3. Policy history: use earlier policy matches to restrict outbound tools across servers.
4. Resource conditions: live Stripe customer records in scope, test records out of scope.
5. Impact analysis: replay recent calls against a draft policy.

See why a call was blocked. Trace a blocked call to the agent, the user it acted for, the destination tool, and the policy that applied. You can explain the denial from its audit record.

AUDIT-03F4A91 · DENIED

| Field | Detail |
|---|---|
| Who | analytics-agent · OBO alex@company.example |
| What | reporting.send_report → external destination |
| When | 03:04:18 UTC · Reporting MCP |
| Why | block-outbound-after-read — sensitive-read policy matched earlier for this identity |

## Answer the questions in your security review.

Check how your policies will affect agent calls and what your audit records retain. Bring your deployment and data-handling requirements to onboarding so we can review them with you.

- Can you review the rules? Your policies use Cedar, so you can test the rules and track their versions.
- Which calls would change? Replay the last 24 hours of calls against your draft policy before saving it.
- Can you explain a decision? See who attempted the call, which tool they used, and why it was allowed or denied.
- How are credentials stored? Your connected services’ credentials are encrypted at rest.
- Where do tool responses go? When a call is allowed, Wicket forwards the tool’s response to your agent.
- What can denial records retain? Some retain redacted tool arguments. Review this against your data-handling requirements during onboarding.

## Tell us what your agents need to access.

Tell us which tools your agents use and which destinations should be off-limits. We’ll help you map those requirements to MCP connections and policies.

[Contact Wicket](https://wicket.sh/contact) · eng@wicket.sh

## See how to block a public post after a sensitive read.

[Request a demo](https://wicket.sh/#contact) · eng@wicket.sh