Omh Security Safety Review

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, and external services
• permission_and_secret_risk_matrix/v1 with redacted findings, allowed actions, missing evidence, and escalation gates
• prompt_injection_risk_review/v1 with untrusted input boundaries and tool-use constraints
• safe_action_policy/v1 with allowed, confirmation-gated, blocked, and observed-only actions
• plugin_risk_audit/v1 with bounded aggregate local risk categories and no source disclosure
• credential_rotation_sequence/v1 attached to remediation_handoff/v1, ordering issue-new, deploy-new, verify-new, revoke-old, verify-revoked, with the overlap window and the operator who runs each step