DM pairing and credentials security: 8 checks before rollout

What this page solves

Most DM incidents are boundary problems, not model problems.
You should treat ~/.openclaw/credentials/* as access gates.

References:

• Pairing
• Session Management

Pre-rollout checklist

1. use dedicated DM accounts, not shared public-channel accounts
2. keep credentials files isolated per channel
3. lock file permissions to runtime user only
4. start with allowlist pairing rules
5. assign explicit dmScope per account
6. keep identityLinks one to one
7. define key rotation and revoke flow
8. keep an owner map for account, channel, and credentials file

30-minute hardening actions

Step 1: lock file permissions

chmod 700 ~/.openclaw
chmod 700 ~/.openclaw/credentials
chmod 600 ~/.openclaw/credentials/*

If you run in containers or managed infra, apply equivalent permission controls.

Step 2: lock pairing boundaries

1. deny by default, then allow known accounts
2. bind one expected identity per account
3. avoid one identity mapped to multiple accounts

Step 3: tie to session audit

1. logs must include channel/accountId/threadId
2. every pairing change must have operator and timestamp
3. incident replay must show who used which credentials and when

Pass criteria

1. unregistered accounts cannot pair
2. credentials permission checks pass
3. revoking one account takes effect within 10 minutes
4. any DM session identity chain is traceable

High-frequency failure mapping

1. Symptom: old account still works after replacement
   Action: check credentials cache, revoke old key, restart affected workers

2. Symptom: two accounts share context
   Action: inspect identityLinks for many-to-one mistakes

3. Symptom: file permissions look correct but access still works
   Action: inspect runtime user and volume mount policy

Next step: Multi-account routing runbook.