aikido-device-protection

A block is a security decision, not a broken build. You can't tell from the shell whether it's a false positive or the attack it just stopped. Being asked to install a package is not authorization to obtain it another way.

Check before you debug

Blocks surface as opaque registry failures — usually HTTP 403, sometimes a connection reset or a version quietly resolving older than latest. Aikido is rarely named, so a block looks like an auth problem, and the standard 403 playbook makes it worse: re-authenticating hides it, and switching registry swaps an inspected source for an uninspected one.

aikidoctl events --json

Parse the JSON; don't scrape the package manager's error. If no event matches, it's an ordinary registry or auth problem — debug it normally. If the command is unavailable, ask the user to check the desktop app (tray icon → Open Dashboard; minimum-age blocks under Logs) rather than guessing. Malware writeups: https://intel.aikido.dev/?tab=malware

Resolve

First matching rule decides: 1) malware → blocked, no exceptions; 2) a group exception blocks it; 3) a group exception or prior admin approval allows it; 4) Block All Installs is on for the ecosystem; 5) Force Requests is on and it hasn't been requested → held in the admin Inbox; 6) otherwise allowed.