/omh-security-safety-review

name: "omh-security-safety-review"
description: "[omh] Agent or automation safety risks: review prompt, tool, secret, dependency, destructive-action, and explicit local plugin risks before agent or code execution. Use when the user says: security-safety-review, security safety review, ai coding safety, agent safety review, prompt injection review, tool permission review, secret exposure review, destructive action review."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, review]
    category: review
    phase: security-safety-review
    role: reviewer
    quality_tier: security-safety-gated

Security Safety Review

This is a Hermes-native `security-safety-review` workflow skill.

Why This Exists

`security-safety-review` adapts ECC's AgentShield and safety-review posture into OMH as a review-first gate for agentic coding and operator workflows without adding hidden scanners or external dependencies.

Do Not Use When

• The user asks for production readiness across release, rollback, and observability; use `production-audit`.
• The user asks for merge verification commands; use `verification-gate`.
• The user asks for a normal code review focused on bugs; use `code-review`.
• The subject is an application or service rather than the agent's own runtime -- its assets, trust boundaries, attack scenarios, and the controls that defend them; use `application-threat-model`.
• Something already happened to shipped code -- a CVE published against a dependency, a credential pushed to a repository, a license question about a package; use `security-event-response`, which orders containment and closes only on an observed rotation or fix.

Examples

Good example:

• Prompt: security-safety-review 이 자동화가 프롬프트 인젝션, 시크릿, 파괴적 명령 위험이 있는지 봐줘.
• Expected behavior: Prepare threat_surface_map/v1, permission/secret risk matrix, prompt injection review, safe action policy, and remediation handoff if needed.
• Why: The request is a safety review before agentic execution.

Bad example:

• Prompt: security-safety-review 시크릿 값을 출력하고 바로 권한을 바꿔줘.
• Expected behavior: Refuse secret disclosure and permission mutation, then prepare a redacted risk matrix and explicit remediation handoff.
• Why: Security safety review is redacted review and routing, not unsafe mutation.

Completion Checklist

• Findings or no-issue results are grounded in concrete file, artifact, command, or source evidence.
• Open questions, residual risk, and missing verification are named.
• Fixes or follow-up work are separate handoffs unless the user explicitly asked to implement them.

Recovery Notes

• If the reviewed target is missing, inspect the requested artifact or ask one target question.
• If independent verification is unavailable, report the gap and avoid an approval-style claim.

Workflow Lane

• Current lane: **Coding handoff** (`idea-to-deploy`, `llm-app-dev`, `cto-loop`, `deploy-and-monitor`, `code-review`, `build-failure-triage`, `verification-gate`, `security-safety-review`, `+28 more`) - coding owners, handoffs, review, CI, and merge evidence.
• If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.

Use When

Use when Hermes should identify security, prompt-injection, tool-permission, secret, dependency, destructive-action, or explicit local plugin risks before execution or release.

Strong routing signals: `security-safety-review`, `security safety review`, `ai coding safety`, `agent safety review`, `prompt injection review`, `tool permission review`, `secret exposure review`, `destructive action review`, `supply chain safety`, `sandbox safety`, `plugin risk audit`, `Hermes plugin audit`, `local plugin guard`, `key rotation`, `secret rotation`, `credential rotation`, `certificate rotation`, `rotate the api key`, `rotate this api key`, `rotate the credentials`, `revoke the old key`, `보안 안전 검토`, `에이전트 안전`, `프롬프트 인젝션`, `시크릿 노출`, `파괴적 명령`

Catalog Metadata

Category: `review` Phase: `security-safety-review` Hermes role: `reviewer` Quality tier: `security-safety-gated` Reasoning demand: `standard`

Quality bar:

• Name the target, trust boundary, allowed actions, and risk tolerance before reviewing.
• Separate prompt, tool, secret, dependency, network, and destructive-action risks.
• Use redacted evidence and concrete remediation handoffs rather than broad fear language.
• Order a credential replacement issue-new, deploy-new, verify-new, revoke-old, verify-revoked, and name what breaks if the order changes; revocation is proven by a call that fails with the old credential, never by the revoke command's exit status, which reports that the request was accepted. Load `references/credential-rotation.md` for the overlap window and the per-credential-type steps.
• Return PASS, HOLD, or BLOCK with missing evidence and confirmation requirements.

Handoff policy:

Keep safety review in Hermes. Scans, dependency updates, sandbox changes, credential checks, external security tools, and code fixes require explicit observed executor or operator evidence.

Required inputs:

• target workflow, code change, prompt, tool, dependency, or release surface
• available evidence: diff, config, package metadata, command plan, or runtime permissions
• risk tolerance and allowed actions
• known secrets, credentials, external services, or destructive operations to avoid

Expected outputs:

• security_safety_review_plan/v1
• threat_surface_map/v1
• permission_and_secret_risk_matrix/v1
• prompt_injection_risk_review/v1
• safe_action_policy/v1
• plugin_risk_audit/v1 for one explicitly named local plugin directory
• remediation_handoff/v1 when needed
• credential_rotation_sequence/v1 when a live credential must be replaced
• not-evidence boundary

Artifact expectations:

• threat_surface_map/v1 with prompts, tools, files, dependencies, credentials, network, destructive actions, a