# 🔴 Red Team Assessment: steipete/domain-dns-ops

**Skill:** Domain/DNS Ops  
**Author:** steipete (Peter Steinberger, PSPDFKit founder)  
**Source:** https://clawhub.ai/steipete/domain-dns-ops  
**Version:** v1.0.0  
**License:** MIT-0 (public domain, zero conditions)

---

## Executive Summary

**Risk Level: MEDIUM-HIGH** — Skill is legitimately useful for its stated purpose (DNS/Cloudflare ops), but the metadata omits critical security declarations that the instructions depend on. This creates an **approval gap**: an agent could autonomously access API tokens, run repo scripts, and modify DNS without the user understanding what's about to happen.

**Verdict:** Not malicious. But poorly declared. Requires human-in-the-loop for any destructive operation.

---

## Threat Model

### What It Claims to Do
- Onboard domains to Cloudflare
- Flip nameservers (Namecheap → Cloudflare)
- Set redirects (Page Rules, Rulesets, Workers)
- Verify DNS/HTTP with dig/curl
- Source of truth: `~/Projects/manager` (user's personal repo)

### What It Actually Does (Red Team Analysis)

#### ✅ Benign Intent
- Author is a known developer (Peter Steinberger, PSPDFKit)
- Skill is a thin router — delegates to user's own repo scripts
- No install spec = no code written to disk by the skill itself
- `always: false` = requires explicit user invocation
- "Push only when explicitly asked" guardrail in SKILL.md
- "Don't touch .md lore domains" guardrail

#### ⚠️ Risk Vectors

| # | Risk | Severity | Details |
|---|------|----------|---------|
| 1 | **Missing credential declarations** | 🔴 High | SKILL.md references `CLOUDFLARE_API_TOKEN` / `CF_API_TOKEN` and Namecheap/DNSimple creds in `~/Projects/manager/profile`, but metadata lists zero required env vars. Agent won't request approval before reading these. |
| 2 | **Unbounded file system access** | 🔴 High | Instructions read `~/Projects/manager/*`, `~/.profile`, source shell profiles, execute `bin/*` scripts. No path restrictions declared. |
| 3 | **Autonomous invocation enabled** | 🟡 Medium | `always: false` is good, but platform default allows autonomous invocation. Combined with unbounded FS access, an agent could run DNS-altering commands without fresh human approval. |
| 4 | **Git push capability** | 🟡 Medium | SKILL.md includes commit/push instructions. While it says "push only when explicitly asked," an agent with autonomous rights might skip this. |
| 5 | **No binary declarations** | 🟡 Medium | Uses `cli4`, `rg`, `dig`, `curl`, `git` — none declared in metadata. Agent might install or fail silently. |
| 6 | **No network scope** | 🟡 Medium | Calls Cloudflare API, Namecheap API, DNSimple API, makes DNS queries. No network restrictions declared. |

---

## Attack Scenarios

### Scenario 1: Token Exposure (Most Likely)
> Agent reads `~/Projects/manager/profile` containing `CLOUDFLARE_API_TOKEN`, echoes it in a debug message or logs it. Token now in chat history / logs.

**Mitigation:** Agent should never echo or log tokens. SKILL.md doesn't mention this.

### Scenario 2: Unauthorized Nameserver Flip
> Autonomous agent decides to "fix" DNS, runs `bin/namecheap-set-ns`, flips nameservers for a domain. Site goes down.

**Mitigation:** Always require human confirmation for nameserver changes.

### Scenario 3: Scope Creep via Shell Profile
> `source ~/.profile` loads arbitrary environment variables and functions. If profile has side effects, agent inherits them.

**Mitigation:** Agent should not source user profiles without understanding contents.

### Scenario 4: Git Push Without Approval
> Agent commits and pushes to `~/Projects/manager`. If profile has git aliases or hooks, unintended changes propagate.

**Mitigation:** SKILL.md has "push only when explicitly asked" but no enforcement mechanism.

---

## Clean Room Recommendation

**Do you need it?** If you manage domains via Cloudflare/Namecheap/DNSimple and have a `~/Projects/manager` repo with scripts — yes, this is useful. But it needs hardening.

**If installing, apply these controls:**

### 1. Pre-Install Review (REQUIRED)
- [ ] Confirm `~/Projects/manager` exists
- [ ] Review every script in `bin/*` — what do they do? What secrets do they read?
- [ ] Review `~/Projects/manager/profile` — what env vars does it set?
- [ ] Check `DOMAINS.md` for domains you don't want touched

### 2. Metadata Hardening (REQUEST FROM AUTHOR)
```yaml
# What should be in the skill manifest:
required_binaries: [cli4, rg, dig, curl, git]
required_env_vars: [CLOUDFLARE_API_TOKEN, CF_API_TOKEN]
required_paths: [~/Projects/manager]
network_scope: [api.cloudflare.com, api.dnsimple.com, api.namecheap.com]
```

### 3. Runtime Controls
- [ ] Disable autonomous invocation for this skill (require explicit `/invoke` or similar)
- [ ] Set approval gate for: nameserver changes, zone deletion, git push
- [ ] Log all `cli4` commands and `bin/*` script invocations
- [ ] Never allow `git push` without explicit human confirmation

### 4. Token Hygiene
- [ ] Use least-privilege Cloudflare tokens (zone:read, zone:edit for specific zones only)
- [ ] Rotate tokens after testing
- [ ] Don't store tokens in `~/.profile` — use `pass`, `1password`, or dedicated env file

---

## Comparison to Our Architecture

| Principle | Our Standard | This Skill | Gap |
|-----------|-------------|-----------|-----|
| Zero-trust secrets | App passwords, `~/.openclaw/.env` (chmod 600) | Reads from `~/Projects/manager/profile` | No declared secret management |
| Least privilege | Tokens scoped to specific operations | Full Cloudflare API access via token | Token scope not discussed |
| Approval gates | Destructive ops require `/approve` | "Push only when explicitly asked" (advisory) | No enforcement |
| Path isolation | Skills run in scoped workspace | Reads arbitrary `~/Projects/manager/*` | No path restrictions |
| Network isolation | localhost/Tailscale only | Calls external APIs | Expected for DNS ops, but undeclared |

---

## Bottom Line

**Not a backdoor. Not malicious. But sloppy metadata that expands blast radius.**

Peter built a useful tool for his own workflow. If you have a similar setup (personal domain manager repo), it could save time. But treat it like a power tool — useful, but disable autonomous mode and keep your fingers clear of the blade.

**My recommendation:**
1. Review your `~/Projects/manager` repo first
2. Install only if the scripts are clean and you understand them
3. Never enable autonomous invocation
4. Require explicit approval for any `git push`, nameserver change, or zone deletion
5. Consider writing your own thin wrapper instead (it's mostly a router)

---

*Assessment by Socrates 🧠 | 2026-04-27*