Client choice is not the governance model
A team may use Codex for implementation, Claude Code for local coding sessions, opencode for terminal workflows, and Cursor for editor-based work. That variety is normal.
The governance problem is separate: who can run the Skill, whether source can sync, and where reviewers find evidence.
- Do not bind policy to one client brand.
- Use MCP as the common invocation surface.
- Keep organization policy in Invokora instead of local configuration files.
Keep protected source server side by default
Skills can contain prompts, SOPs, tool instructions, internal references, and operating rules. Copying that material to every local machine makes offboarding and access review harder.
Server-hosted mode lets members invoke the Skill without receiving the protected source bundle. Public-source mode remains explicit for teams that need local source review.
- Use server-hosted mode for sensitive shared workflow logic.
- Allow source sync only for members with the right permission.
- Record source reads and sync events separately from ordinary runs.
Make review questions easy to answer
Security review should not depend on guessing what each local client stored. The system should answer which delivery mode applied, who had access, and whether sensitive output was blocked.
Invokora gives platform owners one place to review organization Skill policy while developers keep using the MCP clients that fit their work.
- Review delivery mode before onboarding a Skill to MCP clients.
- Use per-Skill ACL for sensitive workflows.
- Keep blocked-output and delivery-change evidence available to admins.