openclaw-trust

name	openclaw-trust
description	Apply OpenClaw’s official threat model and trust guidance (MITRE ATLAS–mapped) when evaluating risky workflows, skills, channel exposure, prompt injection, and tool execution safety.

OpenClaw Trust

Use this skill when the user asks about security posture, threat modeling, attack vectors, trust boundaries, or safe rollout decisions for OpenClaw automations.

Source of truth

• Repo: openclaw/trust
• Core files:
  • threats.yaml — machine-readable threat model
  • CONTRIBUTING.md — how to submit threats/mitigations/chains
• Public render: trust.openclaw.ai/trust/threatmodel
• Vulnerability reporting: [e-mail]

What to apply in practice

1) Default to the highest-risk classes first

Prioritize controls for risks repeatedly marked high/critical in the trust model:

• Prompt injection (direct + indirect)
• Malicious skills / compromised skill updates
• Token theft from local config
• Tool argument injection and command execution abuse
• MCP/tool over-permission

2) Translate trust model into concrete controls

When recommending hardening, prefer specific actions:

• Default-deny sender/channel access (AllowFrom least privilege)
• Approval gates for state-changing actions
• Strict tool argument validation (no free-form shell interpolation)
• Limit/monitor skill install/update sources
• Least-privilege MCP server config
• Audit logs for new sender authorization + sensitive actions
• Token hygiene (rotation, minimize plaintext exposure)

3) Separate threat reporting vs vuln disclosure

• Threat model additions/updates → openclaw/trust issues/PRs
• Live exploitable vulnerabilities → responsible disclosure via Trust page/security email

Contribution pattern (for writing trust updates)

When drafting a new threat proposal, include:

• scenario + attack path
• affected OpenClaw components
• rough risk estimate
• suggested mitigation(s)

Maintainers will map to MITRE ATLAS tactic/technique + assign IDs.

Fast mental checklist for risky automation

• Can untrusted content reach prompt/tool parameters?
• Is there a hard approval gate before side effects?
• Could this run with broader permissions than required?
• Is sender/tool/source authenticated and allowlisted?
• Are outputs validated before execution/posting/sending?

If any answer is “no/unknown”, treat as medium+ risk and recommend guardrails before rollout.