CopilotKit / CopilotKit/OpenBot

Proposal: optional endpoint-bound preflight hook before remote MCP calls

Open
#449 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
5.2k
Forks
655
Avg merge
11h 56m
Merged PRs (30d)
370

Description

OpenBot already makes tool grants, action policy, argument inspection and audit part of PluginStore.callTool. I would like to discuss a small optional extension for operators who also want fresh evidence about a public remote MCP endpoint before calling it, following the README's request to coordinate before substantial work.

At the current source, the selected row and catalogue entry are available before credentials are resolved. callVendor is a test injection that replaces the transport and receives credentials; it is not a suitable public evidence-provider contract. Also, transportFor can select MCP, Drive REST or built-in routines, so a proposed MCP check must identify the actual selected transport.

Would an opt-in asynchronous, deny-only hook at this boundary be welcome?

  • Run after the existing grant/policy/content checks and before credential resolution. Capture the effective URL, transport and physical tool name once, and use that same selection for execution after the await. A concurrent server edit must not let evidence for endpoint A authorize endpoint B.
  • Give the provider a read-only public endpoint descriptor and an abort signal. Do not expose credentials, tool arguments, actor identities or result content. Initial scope would be explicitly configured public MCP endpoints; private or credential-bearing URLs would not be disclosed.
  • The hook can continue or refuse this already-permitted call; it cannot override an existing refusal. Unavailable or unknown evidence follows explicit operator policy. Bound the request lifetime and response size, reject redirects, and keep provider text out of model-facing refusal messages.
  • Preserve the current audit contract: a refused invocation records one refusal and makes no vendor call; a forwarded invocation retains the actual vendor outcome. Keep any new decision state local to the request. Both server replicas perform their own check; no process-local persistent receipt/cache or new listener is proposed.

I maintain Agent Guild under AgentTanuki and would use this seam for an optional adapter to its free /preflight endpoint. That endpoint actively probes the configured public URL and returns unsigned observations; it does not establish endpoint ownership, authenticated access, passport verification or safety. The proposed core hook would be provider-neutral and add no automatic Guild request or paid call. The adapter would require explicit operator setup.

If the extension fits the intended architecture, I can prepare a focused PR with native store/transport tests: denied call reaches neither vault nor vendor, allowed call reaches only its captured endpoint, same-name servers cannot exchange evidence, redirects cannot change the checked destination, existing policy refusals remain effective, cancellation/unknowns are handled, and audit rows remain accurate across two store instances. This is a coordination proposal based on source inspection; those tests have not yet been implemented or run.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with server/src/plugins/store.ts around line 2799, then trace PluginStore.callTool, transportFor, and callVendor to understand selection and credential boundaries. Review the proposed native store/transport tests in the issue; done means the focused tests cover captured endpoints, refusals, redirects, cancellation, unknown evidence, and accurate audit rows across two store instances.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend-api-design, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.