Public AI Access Controls

Public AI Access makes a Hunch-enabled website usable from outside MCP-compatible AI assistants such as ChatGPT, Claude, and others.

The product path is public visitor access: the website owner enables a no-auth public connector URL, controls which public workflows are exposed, and monitors usage. Owner/team OAuth MCP installs are disabled as the default setup path.

How It Works

For each website:

1. Hunch discovers public website knowledge and workflows.
2. The owner reviews public-safe website actions in Website Action Controls.
3. The owner turns on Public Access Mode.
4. Hunch exposes a public connector URL at /public-mcp/{website_id}.
5. ChatGPT, Claude, or another compatible MCP client connects using no authentication by default, with a signed public visitor token if the owner enables that policy, or via OAuth 2.1 using Dynamic Client Registration (DCR) and PKCE. When using OAuth, the website owner approves each connection through a consent screen.
6. Every request is checked against access mode, public tool restrictions, signed-token policy, challenge policy, source rules, blocked visitor hashes, risk limits, rate limits, billing controls, and audit logging.

Public Access Modes

Off

Public AI access is blocked. The public connector URL returns 404 and no external visitor can use the site from ChatGPT or Claude.

Use this while configuring a new website or when you want to pause public AI access.

Unlisted

The public connector works, but only people with the connector URL can use it.

Use this for controlled rollout, private customer testing, sales demos, or limited partner access.

Listed

The public connector works and the site can appear in Hunch's public connector directory.

Use this when the website is ready for broader discovery.

What Public AI Visitors Can Access

The public visitor connector can expose:

• grounded website answers through site.ask
• public website search through site.search
• searchable tool discovery through site.search_tools
• workflow skill discovery through site.list_skills and site.get_skill
• MCP prompts through prompts/list and prompts/get
• public capability inspection through site.get_capabilities
• skill resources through skill://{source}/{id}
• approved contact, support, booking, and quote actions
• multi-turn public action continuation through action.reply, action.confirm, and action.cancel
• handoff export through action.export_handoff

Hunch does not expose raw DOM tools one-to-one.

What Public AI Visitors Cannot Access

The public visitor connector blocks:

• owner/team dashboard tools
• private account data
• raw browser/DOM tools
• live-session bridge tools
• arbitrary generated actions outside the public-safe categories
• actions disabled in Website Action Controls

Dashboard Controls

Each website has a Public AI Access tab that shows:

• public access mode
• public connector URL
• public protected-resource metadata URL
• public usage for the last 24 hours
• website action controls
• visitor security controls
• recent public AI activity

Use Website Action Controls to decide whether each normalized site action is exposed. Public visitor access only allows enabled contact, support, booking, and quote actions.

The same tab now also shows:

• connector install guides for Claude, ChatGPT, Cursor, and generic MCP clients
• remote MCP readiness metadata
• install packages you can copy into a client
• connector smoke-test diagnostics
• a CIMD validator for client metadata documents
• workflow skills/playbooks exposed beside the connector

Dedicated Public Permissions

Public AI Access uses a dedicated public permissions model. It is separate from owner/team MCP OAuth permissions.

For each discovered website action, Hunch stores public-specific settings:

• whether the action is visible to public AI visitors
• whether browser-public execution is allowed
• the public risk level: low, standard, or high
• owner notes for why the workflow is or is not public

This prevents a private owner/team setup from accidentally widening the public visitor connector. The public connector only receives public-safe reads/search plus owner-approved contact, support, booking, and quote workflows.

Visitor Security Controls

Signed Visitor Tokens

By default, a listed or unlisted connector can be used by someone who has the public connector URL. If Require signed visitor token is enabled, callers must first create a public visitor token:

POST https://api.hunchbank.com/public-mcp/{website_id}/visitors
Content-Type: application/json

{}

The response contains a visitorToken. MCP callers then send it on JSON-RPC requests:

X-Hunch-Visitor-Token: {visitorToken}

Bearer tokens are also accepted for compatible clients:

Authorization: Bearer {visitorToken}

Signed visitor tokens are scoped to one website and are used for visitor identity, rate-limit identity, audit logs, and block controls. They do not grant owner/team access.

Turnstile Challenge Mode

Challenge mode controls when Hunch requires a Cloudflare Turnstile proof before issuing a signed public visitor token.

• Off never requires a challenge.
• Auto allows Hunch to challenge risky token issuance patterns.
• Always requires a Turnstile token on every public visitor token request.

Turnstile enforcement only works when the API Worker has TURNSTILE_SECRET_KEY configured as a Cloudflare secret. The dashboard-side token tester also needs VITE_TURNSTILE_SITE_KEY so it can render the client widget. Without the API secret, challenge mode fails closed.

When challenge mode requires proof, send:

{
  "turnstileToken": "token-from-cloudflare-turnstile"
}

The Hunch dashboard includes a Visitor Token Test panel under Public AI Access. It renders Turnstile when the dashboard site key is configured, calls /public-mcp/{website_id}/visitors, and shows the signed visitor token that an MCP client would pass with X-Hunch-Visitor-Token.

Referrer Allow and Block Lists

Use allowed referrers when public connector calls should come only from known sources. Use blocked referrers when one source should be denied while other sources continue to work.

Hunch normalizes hosts before comparison. For example, https://www.example.com/path becomes example.com.

• If the allow list is empty, Hunch does not require a matching source host.
• If the allow list has entries, requests must come from one of those hosts.
• If the block list has a matching host, the request is denied even if public access is enabled.

Some MCP clients may not send a browser-style Origin or Referer header. If you use an allow list, test the exact client before sharing the connector publicly.

Blocked Visitor Hashes

Hunch records a hashed visitor identifier for public connector activity. The dashboard activity log can block a visitor hash with one click.

Blocking a visitor hash prevents that visitor identity from using the public connector again for that website. Hunch stores hashes, not raw IP addresses, in the block list.

Max Risk Score

Every public visitor request receives a request-aware risk score from 0 to 100. The score currently uses deterministic heuristics, including:

• signed versus anonymous visitor identity
• missing user-agent or source host
• previous request volume for the visitor hash
• JSON-RPC batch size
• whether the request attempts public actions
• unknown JSON-RPC methods
• automation-oriented user agents
• high fan-out across many tools in one request
• persistent first-party reputation from previous risk scores for the same visitor hash

This is still not a third-party fraud-intelligence network. Treat it as Hunch's first-party public connector risk engine, then combine it with signed visitor tokens, challenge mode, referrer rules, rate limits, manual blocking, and connector diagnostics for stronger control.

Searchable Tools and Workflow Skills

Hunch does not expect every MCP client to load a huge undifferentiated tool list up front.

Public connectors now expose two discovery layers:

• site.search_tools for searching tool names, descriptions, categories, and execution mode
• site.list_skills / site.get_skill for workflow playbooks such as demo booking, consultation capture, or support deflection

This lets the client narrow the exposed surface before calling a real action.

Examples:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "site.search_tools",
    "arguments": {
      "query": "quote",
      "category": "quote"
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "site.list_skills",
    "arguments": {
      "query": "support"
    }
  }
}

Skills are also visible through MCP prompts and resources:

• prompts/list
• prompts/get
• skill://preset/{id}
• skill://website/{id}

This is the current Hunch direction: remote MCP plus workflow semantics and skills for websites, not raw browser automation.

OAuth 2.1 for AI Assistants

The public-mcp endpoint at /public-mcp/{websiteId} supports OAuth 2.1 with Dynamic Client Registration (RFC 7591) and PKCE (RFC 7636).

MCP-compatible assistants can use their native OAuth connector flows to authenticate against this endpoint. When an AI assistant initiates an OAuth connection, the website owner approves it through a consent screen in the Hunch dashboard.

OAuth connections receive mcp:read and mcp:tools scopes, which grant access to the same public-safe tools governed by Website Action Controls.

OAuth authorization server metadata is discoverable from the public connector itself:

• /public-mcp/{websiteId}/.well-known/oauth-authorization-server
• /public-mcp/{websiteId}/.well-known/oauth-protected-resource

This OAuth 2.1 flow is separate from and replaces the old legacy owner/team OAuth MCP (see below). The no-auth public visitor flow remains available as a simpler alternative for clients that do not need OAuth.

For setup instructions, see Desktop MCP Client Setup.

CIMD

The public OAuth flow also supports Client ID Metadata Documents (CIMD).

If the client sends a URL-style client_id, Hunch fetches and validates that document during authorization:

• the URL must be public HTTPS
• client_id must match the fetched URL
• client_name must exist
• redirect_uris must be present and pass redirect validation

The dashboard includes a CIMD validator so operators can test these documents before asking a customer or AI client to connect.

Readiness and Diagnostics

The dashboard's Remote MCP Readiness section is the operator-facing control plane for:

• metadata endpoint copy/paste
• install packages
• recent installation health
• connector smoke tests across tools, resources, and prompts
• CIMD validation

Use that section before distributing a public connector widely.

Distribution

Every Hunch-enabled website is an MCP server. Share it with users of any MCP-compatible client — ChatGPT, Claude, and others.

Share the public connector URL from the Public AI Access tab in your dashboard. Users add it as a custom MCP server in their client of choice. No authentication required.

For broader distribution:

• ChatGPT App Directory — Submit to platform.openai.com/apps-manage for discoverability
• Claude Connectors Directory — Submit to claude.ai/connectors for listing
• Workspace/org deployment — Deploy as a private app to your organization's MCP client workspace

For setup steps, see Desktop MCP Client Setup.

Legacy Owner/Team OAuth MCP

The old owner/team OAuth MCP at /mcp/{websiteId} remains in the codebase for migration safety and automated tests, but it is disabled on production-facing routes by default. This is the workspace-level owner/team MCP, not the public-mcp endpoint.

Production owner/team OAuth MCP routes return 410 Gone unless LEGACY_OWNER_MCP_ENABLED=true is explicitly configured. The root OAuth discovery metadata endpoints are gated the same way. The recommended path for AI assistant OAuth is the public-mcp endpoint's OAuth 2.1 flow described above.

Rate Limits and Abuse Controls

Public visitor connector traffic is rate-limited per website and visitor source.

The current public connector limit is:

• 60 requests per minute
• 10 JSON-RPC operations per request
• no live-session scope
• no owner/team installation capacity

This keeps public testing usable without opening the same permissions as an authenticated owner/team connection. For sensitive workflows, combine rate limits with signed visitor tokens, challenge mode, strict public permissions, and a lower max risk score.

Billing Behavior

Public connector tool calls run through the same Hunch metering and audit system as other Hunch operations.

Paid plans unlock the production controls around:

• public AI visitor access
• workflow exposure controls
• outcome reporting
• higher-value action routing
• deeper operational analytics

Recommended Rollout

1. Keep public access Off while discovery runs.
2. Review generated website actions.
3. Disable any action that should not be public.
4. Configure visitor security: signed-token policy, challenge mode, referrer rules, and max risk score.
5. Switch to Unlisted and test from an MCP-compatible client.
6. Review the activity log, failed requests, and visitor risk scores.
7. Block suspicious visitor hashes directly from the activity log.
8. Switch to Listed only when the website is ready for broader public discovery.

Related Guides

• Desktop MCP Client Setup
• API Keys