KOMU uses a review-first security model. Plans may come from verified playbooks or provider fallback, but execution always passes through the same plan, review, and approval path before anything runs over SSH.

Before execution, KOMU shows:

• exact commands
• plan source and routing reason
• provider influence where relevant
• plan and step risk
• approval level
• root visibility
• destructive-command visibility
• expected changes
• rollback guidance when available

Elevated or destructive plans require stronger confirmation than standard plans.

The provider layer now has additional guardrails:

• explicit provider trust levels
• provider request context minimization
• prompt redaction for obvious secret-like content
• configuration validation before provider use
• structured provider response validation
• trust-aware suppression of executable command suggestions
• lower-trust treatment for custom endpoints by default

This means a provider can help with reasoning without automatically gaining full executable influence.

KOMU currently uses:

• trusted
• restricted
• untrusted

High-level intent:

• trusted providers can participate normally, but still do not bypass review
• restricted providers stay bounded and may lose executable influence for sensitive tasks
• untrusted providers are limited further and do not get a free path to executable command suggestions

Provider validation now distinguishes:

• missing credentials
• placeholder credentials
• invalid endpoint configuration
• model configuration problems
• authentication rejection
• network failure
• model availability issues
• malformed provider response behavior

Readiness states now include:

• ready
• restricted
• needs-configuration
• unavailable

These states are surfaced through provider status and health commands instead of collapsing everything into "provider failed".

The reusable risk engine supports:

• command pattern matching
• privilege escalation awareness
• destructive filesystem detection
• package removal detection
• firewall and network mutation detection
• permission and ownership mutation detection
• service-state change detection
• direct system-configuration writes
• remote script piping detection

• low
• medium
• high
• critical

• standard
• elevated
• destructive
• blocked

elevated and destructive plans require typed confirmation in the CLI flow.

Preferred secret usage:

1. shell environment variables
2. optional keyring backend
3. local .env only as a convenience file

Not recommended:

• storing raw API keys directly in config.json
• committing .env files with secrets
• copying provider tokens into task text or logs

KOMU now:

• redacts secret-like values in provider-related error paths
• redacts audit/session payloads through the logging layer
• warns when plaintext secret-like fields are detected in local config storage
• supports an optional keyring path when enabled

The policy layer supports built-in and file-based policy packs. Custom JSON policy packs can be placed in the user extension directory under:

• extensions/policies

This is the first step toward enterprise policy customization without rewriting the security service.

• The command risk engine is heuristic, not a full shell parser.
• Provider trust is not OS-level sandboxing or container isolation.
• Keyring support is optional and depends on a working Python keyring backend.
• Approval is still single-operator CLI approval, not multi-party authorization.
• Rollback is guidance-oriented, not automatic recovery.