1. Bind the client to a real organization identity
An MCP client should not become a side door around organization policy. The local connector needs a signed-in user, a selected organization, legal acknowledgement, and a plan or balance state that permits the run.
The review question is simple: can a person run a Skill through MCP that they could not run from the workspace?
- Require login before local setup writes client configuration.
- Check organization membership before execution.
- Apply role permissions and per-Skill ACL on every run.
- Record the execution surface in audit metadata.
2. Keep the tool surface small
A broad local tool surface is hard to reason about. Invokora keeps the public connector focused on Skill chat and status checks, then routes sensitive source and delivery behavior through organization policy.
When a team adds tools, the security review should name the exact capability, input boundary, output boundary, and audit event.
- Prefer read-only diagnostics for status checks.
- Avoid broad command execution, secrets, network, and filesystem access unless the workspace and approval boundary are explicit.
- Block write-capable local file actions in plan-only or review modes.
- Make tool failures visible instead of hiding them behind generic client errors.
3. Review source delivery separately from invocation
A user may be allowed to run a workflow without being allowed to receive the source bundle. MCP rollout should keep that separation visible.
Server-hosted mode is the safer default for workflows that contain team SOPs, prompt policy, or tool instructions. Public-source mode is appropriate when local source sync is intentional and authorized.
- Document which Skills are server-hosted mode and which are public-source mode.
- Require approval for delivery mode changes after creation.
- Keep synced local folders marked as Invokora-managed so cleanup does not touch user-created directories.
4. Use sandboxing, then state its limits
Sandboxing limits the blast radius of tool execution, but it is not a proof that every attack path is impossible. Prompt injection, model output misuse, dependency behavior, and user-approved file access still need policy, logging, and review.
A stronger story is layered: identity and ACL before execution, limited tool surface during execution, egress and output controls around sensitive flows, then audit evidence after execution.
- Run untrusted work away from long-lived developer terminal sessions.
- Prefer explicit egress allowlists and output blocking for sensitive data paths.
- Keep audit records for blocked events and policy changes.
- Review logs without storing sensitive prompt, output, source body, or provider credential values in audit summaries.