1. Establish owners and lifecycle
A Skill should have an owner, an active version, a delivery mode, and an archive path. Without lifecycle rules, old workflow knowledge keeps running after the business process changes.
Invokora treats the organization Skill library as the shared control surface. Skill owners and organization admins can manage source, publish versions, archive stale Skills, and route members to approved runs.
- Assign an owner and reviewer for each organization Skill.
- Keep active and archived states visible.
- Treat the root SKILL.md and supporting files as governed source.
- Review changes when a Skill becomes server-hosted mode or public-source mode.
2. Separate role access from Skill exceptions
Global roles are useful, but sensitive workflows usually need per-Skill exceptions. Deny and allow rules should be explicit enough that owners can answer who can run a Skill and who can receive source.
Access control should be checked in the runtime path, not only in the UI. Connected clients, CLI sync, and workspace runs need to resolve the same organization policy.
- Organization owners keep full control.
- Explicit Skill deny is checked before explicit allow.
- Role permissions apply after Skill-specific exceptions.
- Policy pages should expose pending delivery requests and access changes.
3. Review runtime controls before broad use
Governance is not finished when the Skill is imported. Teams should review how the workflow runs: model usage rules, sandbox boundaries, egress behavior, output blocking, and whether BYOK calls are in scope.
Before broad use, teams need a run path that security and platform owners can inspect across access, model usage, sandbox boundaries, egress behavior, output checks, and BYOK scope.
- Check plan limits and model usage balance before platform-paid calls.
- Keep BYOK subject to the same organization permissions and audit policy.
- Use egress guard and output blocking where sensitive data could leave the run.
- Log blocked events and policy changes for later review.
4. Keep evidence useful and narrow
Audit evidence should answer governance questions without becoming a second sensitive data store. Invokora records metadata around administration, access, delivery, invocation, model usage, billing, blocked events, and security events.
The evidence story is strongest when it is precise: who changed access, which Skill was affected, which delivery mode applied, which surface initiated the run, and what control blocked or allowed it.
- Do not store source bodies, sensitive prompts, model output, or provider credentials in audit summaries.
- Keep audit retention tied to plan or contract terms.
- Route privacy, support, and security material requests to the right workspace pages.