1. Bind every MCP run to organization identity
A local AI client should not become a shortcut around workspace policy. Each run needs a signed-in user, an organization context, legal gate, membership, role permissions, per-Skill ACL, and plan state.
The review question is direct: would the same user be allowed to run the same Skill from the Invokora workspace.
- Require login before writing local MCP configuration.
- Resolve the active organization before execution.
- Apply role and per-Skill access checks for every run.
- Record which execution surface initiated the run.
2. Keep source delivery out of the client decision
MCP clients handle interaction. They should not decide whether protected Skill source crosses into local storage.
Owners choose server-hosted mode when source should stay server side, and public-source mode when authorized local inspection is intentional.
- Use server-hosted mode for protected SOPs, prompts, and tool instructions.
- Use public-source mode for explicit local review and collaboration.
- Require approval when delivery mode changes after creation.
3. Review the evidence before broad rollout
A safe rollout needs records that answer who ran a Skill, which source delivery mode applied, whether output was blocked, and which policy changed.
Audit summaries should stay narrow. They should identify actor, object, outcome, and reason without storing sensitive body content.
- Track source reads, syncs, delivery approvals, blocked outputs, and policy edits.
- Exclude source bodies, prompts, model output, provider keys, and local paths from audit summaries.
- Export only allowlisted governance events for review.

