Security by Intent: Progressive Permission Pattern Generalization

Keywords: security, permissions, allowlist, access control, least privilege, privilege escalation prevention, approval fatigue, pattern inference, adaptive security, exec approval, policy mining

The Problem: "Always Allow" Grants Far More Than Users Intend

When a user clicks "Always Allow" on an exec approval, OpenClaw stores only the resolved binary path — arguments are silently discarded. This means approving one safe command blanket-allows every future invocation of that binary.

Example:

User approves:    python3 compute_this.py
System stores:    pattern: "/usr/bin/python3"   ← args discarded

Later, ALL of these are silently auto-allowed with no prompt:
  ✅ python3 compute_this.py              (intended)
  ✅ python3 delete_all.py                (NOT intended!)
  ✅ python3 -c "import os; os.system('rm -rf /')"   (dangerous!)
  ✅ python3 exfiltrate_secrets.py        (dangerous!)

This is a privilege escalation. The user intended to trust one specific script, but the system granted trust to the entire interpreter.

Code references:

• Pattern extraction stores only the binary path, discarding arguments: exec-approvals-allowlist.ts:507-525
• The allowlist data structure has no field for arguments: exec-approvals.ts:106-112
• Matching checks only resolvedPath, never arguments: exec-command-resolution.ts:143-175

Proposed Solution: Three-Phase Progressive Permission Model

Phase 0 — Binary-Only Match (current behavior, the problem)

"Always Allow" stores only the binary path. Any invocation of that binary is auto-allowed regardless of arguments. This is the status quo and the security gap this issue addresses.

Phase 1 — Exact Match (binary + args)

"Always Allow" should store the full command (binary + arguments). Only the exact same invocation is auto-allowed.

• python3 compute_this.py → allowed
• python3 delete_all.py → requires approval

This is safer but creates a new usability problem for dynamic workflows (see Phase 2).

Phase 2 — Pattern Detection via Periodic Security Review

For repetitive workflows with predictable variation (e.g., date-based file names), exact-match creates approval fatigue:

Day 1: approve write to journal/2026-03-01-Monday.md
Day 2: approve write to journal/2026-03-02-Tuesday.md    ← exact match doesn't cover this
Day 3: approve write to journal/2026-03-03-Wednesday.md   ← nor this
...

A heartbeat/periodic review scans the approval log for clusters of similar actions and notifies the user:

"You've approved 7 similar write actions in /journal/ that follow a date-based naming pattern."

Phase 3 — Generalized Rule with User Confirmation

The system proposes a scoped permission rule:

"Would you like to allow writes matching /journal/\d{4}-\d{2}-\d{2}-\w+\.md?"

The user explicitly confirms, and the regex-based rule replaces the individual entries.

Why This Matters

• Eliminates over-permissioning — permissions match demonstrated intent, not binary-level blanket access
• Eliminates approval fatigue — which is itself a security anti-pattern (users start blindly approving)
• Enforces least privilege automatically — the system generates the narrowest pattern that covers observed behavior
• Auditable — every generalization requires explicit user confirmation, never silent escalation

Implementation Sketch

1. argsPattern support in allowlist config:

{
  "allowlist": [
    {
      "pattern": "/usr/bin/python3",
      "argsPattern": ["/Users/me/scripts/safe_script.py"]
    },
    {
      "pattern": "/opt/homebrew/bin/node",
      "argsPattern": ["/workspace/scripts/*.js"]
    }
  ]
}

2. Approval log: Record all approved actions with full arguments/paths
3. Pattern detector: Periodically cluster similar approvals (common prefix/suffix, date patterns, numeric sequences, globs)
4. Rule proposal UI: Present detected patterns to the user with a clear diff of what changes

Related OpenClaw Issues and PRs

Argument-level / pattern-based exec permissions:

• Feature Request: Path-based argument filtering in exec allowlist #48452 — Path-based argument filtering in exec allowlist
• Feature: exec approvals — command-content deny patterns (not just binary path) #41140 — Command-content deny patterns (not just binary path)
• Feature: Add denylist support for exec-approvals #6615 — Denylist support for exec-approvals
• Allowlisted commands still trigger approval prompts for complex arguments (2026.2.25) #27843 — Allowlisted commands still trigger prompts for complex arguments
• [Feature]: Path-scoped RWX permissions for exec and file tools #39979 — Path-scoped RWX permissions for exec and file tools
• feat(fs): path-scoped RWX permissions for file and exec tools #42653 — feat(fs): path-scoped RWX permissions (PR)

"Always Allow" persistence and behavior:

• [Bug]: "Always Allow" fails silently and does not persist allowlist for unresolved short commands (basenames) #43988 — "Always Allow" fails silently for unresolved short commands
• allow-always silently fails for shell builtins (cd, etc.) #40478 — allow-always silently fails for shell builtins
• Infra: tighten exec allowlist glob matching #43798 — Tighten exec allowlist glob matching (merged)
• fix(exec): escape regex metacharacters in allowlist path matcher #32162 — Escape regex metacharacters in allowlist path matcher (merged)

Approval fatigue / alternative trust models:

• [Feature]: Temporary time-bound exec security escalation via /trust and /untrust #47695 — Temporary time-bound exec security escalation via /trust and /untrust
• feat(cli): add trust windows for time-bounded exec approval #46956 — Trust windows for time-bounded exec approval (PR)

Broader security architecture:

• [Security] Agent Runtime: Unrestricted Tool Execution Leading to Privilege Escalation #12565 — Unrestricted Tool Execution Leading to Privilege Escalation
• [Feature]: Pluggable Guardrail Provider Interface for tool authorization #46441 — Pluggable Guardrail Provider Interface for tool authorization
• RFC: Skill Security Framework — Permission Manifests, Signing, and Sandboxing #10890 — RFC: Skill Security Framework — Permission Manifests, Signing, and Sandboxing

Prior Art and References

Existing Implementations: OS-Level Policy Learning

• AppArmor complain mode + aa-logprof — The most mature real-world implementation of "learn permissions from usage." Run in learning mode, log violations, then interactively generate allow rules. Essentially progressive permission generalization with a human in the loop. (Ubuntu docs, ArchWiki)
• SELinux audit2allow — Reads AVC denial logs and generates policy allow rules. Policy mining from usage patterns, intended for one-shot profile generation. (man page, Red Hat guide)
• sandboxec (2026) — Linux Landlock-based sandbox for AI agent command execution with filesystem and network allow-lists. (blog)

Academic Literature: Policy Mining

• "The Next 700 Policy Miners" (Basin et al., CCS 2019) — Universal method for building policy miners across ABAC, RBAC, XACML. True positive rates within 5% of specialized miners, false positive rates below 5%. (PDF)
• "Mining Attribute-Based Access Control Policies" (Xu & Stoller, 2013) — First algorithm for mining ABAC policies from operation logs. (arXiv)
• "Mining Least Privilege ABAC Policies" (ACSAC 2019) — Minimizing both under-privilege and over-privilege in mined policies. (ACM)
• "Towards Harnessing the Power of LLMs for ABAC Policy Mining" (2025) — Applying LLMs to automate policy generation. (arXiv)

AI Agent Permission Frameworks (2024–2026)

• "Towards Automating Data Access Permissions in AI Agents" (Wu et al., IEEE S&P 2026) — Prediction model observing user permission decision history, >94% accuracy on high-confidence predictions. Users exhibit high consistency in permission preferences within specific contexts. (arXiv)
• Progent (April 2025) — Programmable privilege control for LLM agents with a DSL for fine-grained tool-call policies. LLMs can auto-generate effective policies. Reduced attack success rates to 0%. (arXiv:2504.11703)
• AgentGuardian (January 2026) — Learns legitimate agent behaviors during a controlled staging phase, derives adaptive policies from execution traces. Closest to "learning permission rules from observed behavior" in the AI agent space. (arXiv:2601.10440)

Mobile Permission UX Research

• Android adaptive permission system (Liccardi et al., EURASIP 2017) — Learns users' privacy preferences, proposes abstract authorization rules. Users make highly consistent permission choices, making prediction feasible. (paper)
• Self-configuring adaptive privacy-aware permission system — Uses contextual signals to predict user preferences, reducing privacy violations by 75%. (ResearchGate)

Current AI Coding Tools (None Implement Learning)

No current AI coding tool implements progressive permission learning. Claude Code, Cursor, Cline, Codex CLI all use static allowlists or binary approve-all/approve-nothing modes.

Note to maintainers: This issue is relevant to labels security and enhancement. We lack triage permissions to add them.