Permissions & Activation Control¶

In a nutshell

Not every skill should be allowed to join every conversation. This page covers the controls that decide which skills may participate: converse whitelists and blacklists, activation modes, and the global skill blacklist. For switching groups of intents on and off inside one skill, see Intent Layers. That page owns the layering mechanism.

📐 Formal specification

Converse participation rules are specified by OVOS-CONVERSE-1; see the spec index.

Routing/participation controls, not a security boundary

Converse and fallback permission settings decide which already-loaded skills get to participate in a given turn. They are not a security or sandboxing mechanism. A skill that is loaded has full code-execution rights regardless of its converse whitelist/blacklist status; these settings cannot contain a malicious skill, they can only stop it from being offered a turn. See Privacy & Security: skills are not sandboxed.

Permissions¶

Module: ovos_workshop.permissions

Permission enums control how the converse and fallback systems select which skills may participate.

ConverseMode¶

Controls which skills are allowed to participate in converse at all.

from ovos_workshop.permissions import ConverseMode

Value	Meaning
`ACCEPT_ALL`	Any skill may converse (default)
`WHITELIST`	Only explicitly whitelisted skills may converse
`BLACKLIST`	All skills except blacklisted ones may converse

Configure in mycroft.conf:

{
  "skills": {
    "converse": {
      "converse_mode": "accept_all",
      "converse_whitelist": ["skill-id-1"],
      "converse_blacklist": ["skill-id-2"]
    }
  }
}

intents.ovos-converse-pipeline-plugin overrides this section

The converse plugin reads skills.converse only when its own intents.ovos-converse-pipeline-plugin config section is empty. If you set any key under the intents path, that section wins and skills.converse is ignored entirely, so keep these settings in one place.

What you should see in the log when a whitelist blocks converse

ConverseService returns False from this check silently. There is no dedicated log line announcing "skill X blocked by whitelist". The observable symptom instead: run ologs | grep converse (see RaspOVOS Troubleshooting, "How to debug intent matching") while talking to the device, and the non-whitelisted skill's skill_id simply never shows up as a candidate. No {skill_id}.converse.request / skill.converse.response pair for it appears at all, and its converse() method is never invoked. If a skill you expect to converse is silent, check converse_mode and converse_whitelist in your config before assuming the skill itself is broken.

ConverseActivationMode¶

Controls when a skill is allowed to add itself to the active skills list (enabling converse).

from ovos_workshop.permissions import ConverseActivationMode

Value	Meaning
`ACCEPT_ALL`	Any skill may activate itself (default)
`PRIORITY`	Skill may only activate if no higher-priority skill is already active
`WHITELIST`	Only explicitly whitelisted skills may self-activate
`BLACKLIST`	All skills except blacklisted ones may self-activate

Configure in mycroft.conf. WHITELIST/BLACKLIST here reuse the same converse_whitelist/converse_blacklist lists shown above. There is no separate activation-specific list:

{
  "skills": {
    "converse": {
      "converse_activation": "accept_all"
    }
  }
}

FallbackMode¶

Controls which skills may register as fallback handlers.

from ovos_workshop.permissions import FallbackMode

Value	Meaning
`ACCEPT_ALL`	Any `FallbackSkill` may handle utterances (default)
`WHITELIST`	Only explicitly whitelisted fallback skills may respond
`BLACKLIST`	All fallback skills except blacklisted ones may respond

Configure in mycroft.conf:

{
  "intents": {
    "ovos-fallback-pipeline-plugin": {
      "fallback_mode": "accept_all",
      "fallback_whitelist": [],
      "fallback_blacklist": []
    }
  }
}

The skills.fallbacks section in the shipped mycroft.conf is not read

The shipped default config carries these same keys under skills.fallbacks, but the fallback pipeline plugin, when loaded by ovos-core, receives its config from intents.ovos-fallback-pipeline-plugin and never falls back to skills.fallbacks. Overrides placed under skills.fallbacks have no effect. Use the intents path above.

Per-session exclusions¶

Everything above is deployment-wide configuration. The Session carries its own, finer-grained exclusion surface: session.blacklisted_skills, session.blacklisted_intents and session.blacklisted_pipelines. Each field initializes from its own config default — blacklisted_skills from skills.blacklisted_skills, blacklisted_intents from intents.blacklisted_intents, and blacklisted_pipelines from intents.blacklisted_pipelines — but all three are per-session and mutable at runtime: a remote client (for example a HiveMind node declaring its own session) can exclude skills, individual intents, or whole pipeline stages for its requests without touching the server's config. The gates are enforced across the whole match path: general intent matching, converse, fallback, and stop all check the session's lists before dispatching. This is the mechanism to reach for when different satellites should have different skill sets against one shared core; see Updating Remote Clients for the version notes.

Per-speaker permissions are not possible

Every control on this page applies to a device or a session, never to a person. The speaker-verification wake-word gate can accept or reject an activation by voice, but it never tells the rest of the stack who spoke — no speaker identity reaches the session, the intent match, or a skill. There is no mechanism for "kid-safe mode for this voice" or per-user skill blacklists. If you need per-user gating, give each user their own client device or satellite and use the per-session exclusions above.

Utility Functions¶

from ovos_workshop.permissions import blacklist_skill, whitelist_skill

# Add a skill to the global blacklist in mycroft.conf
blacklist_skill("my-unwanted-skill-id")

# Remove from the blacklist
whitelist_skill("my-unwanted-skill-id")

Note

These functions manage a separate, broader kill-switch: skills.blacklisted_skills in mycroft.conf. A skill listed there is prevented from loading at all. It is unrelated to the converse_blacklist/fallback_blacklist keys above, which only restrict participation in converse/fallback while the skill still loads normally.

These functions directly modify mycroft.conf and take effect on the next skill manager reload.

Source code: OpenVoiceOS/ovos-workshop.

Read next: Converse Related: Intent Layers · Security & Trust Model · Decorators · Session Aware Skills