Enterprise Legal Guardrails Public

Legal/compliance guardrails for outbound OpenClaw actions (anti-spam, defamation, privacy, financial claims).

Security Scan

The skill is internally consistent with its stated purpose: a local, deterministic outbound guardrail checker and an execution wrapper that enforces allowlists and audit controls.

Purpose & Capability

Name/description match the code and SKILL.md: the repository contains a local rule-based checker and a wrapper for executing outbound commands under guardrail controls. There are no unrelated credentials, networks, or cloud SDKs requested.

Instruction Scope

Runtime instructions tell the agent to run the included checker and/or wrapper on draft text before publishing; the scripts only read provided text, optional files/stdin, env config, and run subprocesses. There are no instructions to collect or transmit unrelated system secrets or call external services.

Install Mechanism

Instruction-only skill with no install spec. Code files are included but there is no remote download/installation during install time. Low install risk.

Credentials

No required env vars declared in registry. The SKILL.md and scripts support many optional env flags for tuning and an approval/allowlist model (e.g., ENTERPRISE_LEGAL_GUARDRAILS_ALLOW_ANY_COMMAND and approval token). These are reasonable for an execution wrapper but should be managed carefully — enabling allow-any-command and permissive keep-env settings could expose downstream commands to sensitive env vars.

Persistence & Privilege

always:false (normal). The wrapper can execute arbitrary subprocesses when explicitly configured (allowlist controls and approval-token requirements are present). Autonomous invocation of the skill is allowed by default on the platform, which is expected — but if integrated without strict allowlists or with allow-any-command enabled, the blast radius increases.

Assessment

This skill appears to do what it claims: a local, rule-based preflight checker plus a guarded 'guard_and_run' adapter to execute outbound commands under allowlist and audit controls. Before installing: 1) Confirm you will not enable the '--allow-any-command' escape hatch in production; it bypasses the allowlist and should only be used with explicit approval tokens and auditing. 2) Configure allowed commands and sanitize environment (ENTERPRISE_LEGAL_GUARDRAILS_ALLOWED_COMMANDS, --sanitize-env / --keep-env) so secrets or unrelated env vars are not passed to executed binaries. 3) Place audit logs on a secure path and verify they don't inadvertently store raw sensitive drafts in your environment. 4) Review the allowlist and approval-token practices to ensure tokens are appropriately managed. If you follow those precautions, the skill is coherent and appropriate for outbound guardrail use.

Enterprise Legal Guardrails

Use this skill to preflight bot output before posting, messaging, or publishing anything that could create legal/compliance risk.

What it is

A generic outbound guardrail checker used by workflows before execute actions such as post/comment/message/chat/send in any app.

When to use

• Before create_post, create_comment, send_message, or equivalent publish actions.
• Before market-related commentary, strategy claims, or price/certainty statements.
• Before HR-sensitive or workplace-adjacent messaging.
• Before anti-spam or coordination-heavy communications.
• Before handling or exposing personal identifiers.

Workflow

1. Draft text.
2. Run the checker with the matching action/profile.
3. If result is PASS/WATCH, proceed.
4. If REVIEW, rewrite or route for human/legal review.
5. If BLOCK, do not execute.

Use it as a shared OpenClaw outbound safety layer for any skill that publishes content. Babylon is only one current integration example, not the primary purpose of the skill.

Quick usage

python3 scripts/check_enterprise_guardrails.py \
  --action post \
  --app <app_name> \
  --policies social antispam hr \
  --text "Draft text here"

python3 scripts/check_enterprise_guardrails.py \
  --action comment \
  --scope include \
  --apps whatsapp,telegram \
  --text "Draft text here"

python3 scripts/check_enterprise_guardrails.py \
  --action market-analysis \
  --text "Market commentary..." \
  --json

App scope (global filtering)

Scope applies to any app-context passed with --app and these env vars (legacy names preserved for compatibility):

• ENTERPRISE_LEGAL_GUARDRAILS_OUTBOUND_SCOPE (all|include|exclude)
• ENTERPRISE_LEGAL_GUARDRAILS_OUTBOUND_APPS (comma-separated list)
• BABYLON_GUARDRAILS_SCOPE
• BABYLON_GUARDRAILS_OUTBOUND_SCOPE
• BABYLON_GUARDRAILS_APPS

Examples:

• all: check all outbound content.
• include + whatsapp,email: only check those apps.
• exclude + whatsapp,email,moltbook,babylon: everything except these apps.

If scope is omitted, default is all.

Profiles

• social: public social text, comments, announcements.
• antispam: unsolicited/pumping/coordinating messaging.
• hr: workplace, hiring, performance, or employee conduct language.
• privacy: personally identifying data and private information disclosures.
• market: market/financial claims and outcome assertions.
• legal: legal conclusions/implication language.

If no profile is provided, defaults are derived from --action:

• post|comment|message → social,legal
• trade|market-analysis → market,financial
• generic → legal,social

Output

• PASS: safe to execute
• WATCH: low risk; optional rewrite
• REVIEW: human/legal review recommended
• BLOCK: do not execute

Tuning

You can tune decision sensitivity via environment variables (or CLI flags in direct runs):

• ENTERPRISE_LEGAL_GUARDRAILS_REVIEW_THRESHOLD (default: 5)
• ENTERPRISE_LEGAL_GUARDRAILS_BLOCK_THRESHOLD (default: 9)

CLI overrides:

• --review-threshold
• --block-threshold

Legacy aliases are supported in legacy env names: ELG_* and BABYLON_GUARDRAILS_*.

Universal outbound adapter (no-native integration path)

For skills/tools without native guardrail hooks (for example: Gmail, custom website publishing, custom message bots), run outbound operations through the wrapper:

python3 /path/to/enterprise-legal-guardrails/scripts/guard_and_run.py   --app <app_name>   --action <post|comment|message|trade|market-analysis|generic> --execute --text "$DRAFT"   -- <outbound command...>

Examples:

# Gmail via gog
python3 /path/to/enterprise-legal-guardrails/scripts/guard_and_run.py   --app gmail --action message --execute --text "Hello, ..."   -- gog gmail send --to [e-mail] --subject "Update" --body "Hello, ..."

# Website/publication publish flow
python3 /path/to/enterprise-legal-guardrails/scripts/guard_and_run.py   --app website --action post --execute --text "$POST_COPY"   -- npm run publish-post "$POST_COPY"

Use this wrapper to apply the same policy checks in non-Babylon outbound flows.

Compatibility

Legacy name legal-risk-checker is preserved in OpenClaw workspaces that still reference it.

References

See references/guardrail-policy-map.md for the full policy rule set and suggested rewrites.

Packaging

A distributable bundle is available at:

• dist/enterprise-legal-guardrails.skill

Hardening controls for guard_and_run.py

For non-native outbound integrations, treat guard_and_run as an execution boundary. Recommended flags/env:

Execution safety is allowlist-first by default. Wrapper requires explicit --allowed-command (or env alias) unless --allow-any-command is explicitly enabled.

• --allow-any-command / ENTERPRISE_LEGAL_GUARDRAILS_ALLOW_ANY_COMMAND
  • Explicitly bypass allowlist enforcement (unsafe; audit-first use only).
• --suppress-allow-any-warning / ENTERPRISE_LEGAL_GUARDRAILS_SUPPRESS_ALLOW_ANY_WARNING
  • Suppresses the runtime safety warning when --allow-any-command is intentionally enabled.
• --allow-any-command-reason / ENTERPRISE_LEGAL_GUARDRAILS_ALLOW_ANY_COMMAND_REASON
  • Mandatory rationale for any allow-any bypass invocation. Suggested format: SEC-1234: emergency fix.
• --allow-any-command-approval-token / ENTERPRISE_LEGAL_GUARDRAILS_ALLOW_ANY_COMMAND_APPROVAL_TOKEN
  • Mandatory approval token for any allow-any bypass invocation; stored as a short token fingerprint in audit logs.
• --allowed-command <exe...> / ENTERPRISE_LEGAL_GUARDRAILS_ALLOWED_COMMANDS
  • Allow-list executables (supports comma/space lists and wildcards).
• --execute / ENTERPRISE_LEGAL_GUARDRAILS_EXECUTE
  • Enables execution after guard checks. Without this flag, runs are validation-only.
• --strict / ENTERPRISE_LEGAL_GUARDRAILS_STRICT
  • Escalate REVIEW to hard block.
• --sanitize-env
• --keep-env <VAR...> / --keep-env-prefix <PREFIX...>
• --command-timeout, --checker-timeout, --max-text-bytes
• --audit-log <file> / ENTERPRISE_LEGAL_GUARDRAILS_AUDIT_LOG

These flags provide execution safety, command scoping, and immutable trail for post-incident review without changing checker logic.