Skip to main content

Policies and enforcement

Policy enforcement is designed to be deterministic and pre-execution.

Enforcement lifecycle​

For each governed execution command (restore, install, add, remove, dev, test, supported publish, and run -- <native command>):

  1. resolve project root, detected ecosystem, and native command plan
  2. resolve authenticated identity and active workspace context
  3. fetch latest policy snapshot (with safe fallback behavior)
  4. evaluate request at org, team, and user scope
  5. produce verdict (ALLOW, WARN, BLOCK)
  6. emit audit event
  7. execute command only when policy permits

package-ninja plan --json runs only the local planning portion of this lifecycle. It does not fetch policy and does not execute native package-manager commands.

Policy precedence​

Recommended precedence model:

  1. global/system safety rules (highest priority)
  2. organization baseline rules
  3. team-specific rules
  4. user-specific overrides (lowest priority)

When conflicting rules exist, deny-first handling should win unless explicitly approved by policy model.

Verdict meanings​

  • ALLOW: execution proceeds normally
  • WARN: execution proceeds, warning is recorded for visibility
  • BLOCK: execution is terminated before package-manager side effects

Emergency continuity​

Break-glass behavior exists for operational continuity:

  • emergency override must be enabled by admin in dashboard
  • CLI caller must have authorized role to use --admin-skip
  • bypass usage should always be audited
  • denied package names / scopes
  • publish destination and registry constraints
  • file leak preflight controls for publish
  • package metadata and provenance checks
  • size jump and anomaly checks