Security6 min read

Hosted Skills vs. a direct GitHub clone

A direct clone spreads Skill source into every local machine that needs to run it. Invokora gives teams a managed path: owners choose server-hosted mode when source should stay server side, public-source mode when inspection and sync are allowed, and audit records show who changed delivery and access.

The risk is source spread, not GitHub itself

GitHub is a strong source system. The unmanaged pattern is the problem: an employee clones a private Skill, copies supporting files, and then the organization loses a practical view of where that operational knowledge moved.

Skills can contain prompts, SOPs, tool instructions, customer handling rules, data access steps, and model behavior constraints. That material is often more sensitive than ordinary application code because it describes how work is done.

  • Local clones can outlive role changes and team moves.
  • Source review is separated from runtime access.
  • Security teams have to reconstruct who could run or copy the Skill after the fact.

Invokora separates run access from source delivery

In server-hosted mode, members invoke the organization Skill while source and bundle files remain server side. In public-source mode, authorized members can sync source packages, but the Skill is still governed by organization membership, role permissions, per-Skill ACL, billing limits, and audit.

That distinction gives owners a specific control to explain during security review: who may run the workflow, who may read source, and who approved delivery changes are different questions.

  • Use server-hosted mode for SOPs, prompt systems, and tool instructions that should not be copied to every client.
  • Use public-source mode when local inspection, debugging, or team-owned source review is required.
  • Use delivery approvals when a Skill moves between these modes after creation.

What becomes reviewable

A managed Skill path gives the security and platform teams evidence that a cloned folder cannot provide on its own. Access decisions, source reads, sync events, blocked outputs, policy changes, and delivery approvals can be reviewed as organization events.

This does not mean every possible prompt injection or model output issue disappears. It means the organization has one place to control source exposure and inspect the events around that exposure.

  • Membership and legal gate before execution.
  • Role and per-Skill access decisions before a member can run.
  • Delivery approval records when protected source boundaries change.
  • Audit summaries that avoid storing source bodies, prompts, model output, or provider credentials.