Add configurable trust modes for Droid-Shield secret blocking

[SantaDiegoKairos]

Summary

Please add a user-controllable trust / secret-protection mode for Droid-Shield, available from settings and/or per-session controls.

The default strict protection is valuable, especially for public GitHub / open-source work. However, advanced users also need a deliberate way to choose a different policy when working in fully trusted private environments, such as a local GitLab instance or an internal monorepo where committing operational config files is intentional.

Concrete scenario

I just hit this in Droid CLI after a recent update (droid --version reports 0.120.0).

I was working in a private repository backed by a local GitLab server that I fully trust. The task was to commit a portable setup bundle containing config templates and launcher scripts for internal use. Droid-Shield detected potential secrets and hard-stopped the commit flow with guidance not to retry or work around it.

That is the right default behavior for many users and many repositories, but in this case it blocked an intentional, trusted workflow. I had to leave Droid and run git commit / git push manually.

Requested behavior

Please add a configurable policy, for example:

1. Strict / Block — current behavior; default for safety.
2. Warn + confirm — show the detected files/patterns, require explicit confirmation, then allow the requested commit/push.
3. Trusted workspace / Allow — for explicitly trusted repositories or sessions, do not hard-stop on secret detections; optionally log a warning.

Useful places for this control:

• /settings menu.
• Per-session toggle.
• Per-workspace/repository trust setting.
• CLI flag, e.g. --secret-policy strict|warn|trusted.
• Optional allowlist for trusted Git remotes/domains, e.g. local GitLab hosts.

Why this matters

A hard safety stop is excellent as a default guardrail, but it removes agency from advanced users in private/internal workflows. Users should be able to decide when they are working in:

• public/open-source mode, where strict blocking is desired;
• private/local/internal mode, where committing sensitive operational config may be intentional;
• temporary high-trust sessions for migration, backup, infrastructure, or private deployment tasks.

Ideally the UI would make the current mode very visible, so users do not accidentally run in a permissive mode when working on public repositories.

Suggested safeguards

To keep the default safe while allowing advanced workflows:

• Keep Strict / Block as the default.
• Require an explicit user action to switch to Warn + confirm or Trusted workspace.
• Show the active policy in the session/status UI.
• Consider resetting permissive modes per session unless the user explicitly marks a repository/remote as trusted.
• Let organizations/admins force strict mode if needed.

Thanks for adding Droid-Shield. The request is not to remove protection, but to make it configurable so power users can choose the right trust model for the current repository and workflow.