DEV Community: 杨洪付

Leases, Not Switches: Rethinking Permission Models for AI Agents

杨洪付 — Mon, 26 Oct 2026 19:37:24 +0000

Most AI agent frameworks model permissions as switches: can-read-files yes/no, granted once, permanent until someone remembers to revoke. hmharness — an open-source (MIT) agent framework for HarmonyOS/OpenHarmony development — replaces this with a lease model built around a Capability Broker.

The eight-field token

Every capability access goes through one broker, and every access presents a token with eight fields: subject (who holds it), class (filesystem / network / process / secret / device), scope, resource, operation, constraints, expiry, and provenance — who granted it and why. That last field is where the audit trail starts.

Rule 1: deny by default

Tokens must be explicitly granted. There is no implicit inheritance. This sounds inefficient, but it buys a complete audit chain: every allow is traceable (who granted, why, when it expires), every deny has a reason.

Rule 2: tokens always expire

The expiry field has no "permanent" option. Default TTL is 1 hour, hard cap 24 hours. Permissions stop being one-time assets and become continuous leases — revocation turns into a matter of time, not management.

Rule 3: the RLM rule, mechanized

The hardest one: the worker tier (low-risk, read-only, no-network sandbox) rejects network/secret/process/device capabilities at the tier itself, regardless of what tokens it holds. "Low-privilege execution must not inherit host capabilities" stopped being a documentation rule and became an if-statement. Rules written in docs get forgotten; rules written in code get executed.

The execution ladder

Low-risk + read-only + no network → worker tier. Medium risk or writes → process isolation. High risk or any network → container (Docker). Critical or long-running → microVM. The broker decides "whether"; the ladder decides "where". Together they form the complete execution policy.

Every decision is audited

Each broker decision — allow or deny — is recorded, and the ledger mirror is wired through an injectable onDeny hook into the cognitive layer. Permission audit and the cognitive ledger share the same append-only discipline.

The general lesson

Agent permissions, once granted, are hard to revoke — you may forget the agent has them, or they may already be in use. A lease model turns revocation into a time problem instead of a management problem.

hmharness wires project creation, checks, builds, signing, install, launch, log reading, and result verification into a local toolchain so AI does not just generate code — it proves results against the local machine. Independent community project, no affiliation with Huawei or OpenAtom.

GitHub: https://github.com/swsgbl/hmharness · Evidence: https://swsgbl.github.io/hmharness/evidence/aisecurityarchitectureopensource

An Append-Only Ledger for AI Thoughts: Every Conclusion Has a Birth Certificate

杨洪付 — Sun, 25 Oct 2026 17:02:24 +0000

Most AI tools keep a chat history for you to read. The cognitive ledger in hmharness — an open-source (MIT) agent framework for HarmonyOS/OpenHarmony development — exists for a different reader: the auditor.

15 categories of cognitive events (predictions, verifications, revisions, decisions, learning signals...) are append-only, never deleted, and each carries a lineage chain: which belief this prediction came from, which verification revised it, what descended from that revision. The whole cognitive process forms a replayable DAG.

Why append-only

History that can be edited after the fact is not history. If an AI can silently rewrite its records, what you see is a cosmetically improved decision chain — errors never admitted, revisions never traced. Immutability buys something expensive: accountability. Any wrong prediction can be traced along its lineage to the belief that produced it; every revision has a paper trail.

Ledger 2.0

Five new event categories, plus beliefVersion (versioned beliefs) and descendants (derivation chains) — the cognitive DAG becomes fully replayable.

Unified provenance prevents silent cheating

Canonical lineageId: conclusions from different experiments on different axes are not comparable unless their lineage matches. "Using data from experiment A to argue for conclusion B" is blocked by rule, not by goodwill.

What this means for developers

Every conclusion the agent gives you carries a birth certificate. When it says "this signing configuration is correct", you can ask the ledger: which verification produced this? What environment was used? Was it ever overturned — when, and on what grounds?

The AI stops being a black box that speaks from memory, and becomes an executor with a complete medical record.

The philosophy in one line

The web workbench guarantees "the numbers you see are traceable"; the ledger guarantees "what the AI knows is replayable". Two sides of the same principle: nothing inside the agent is unverifiable.

GitHub: https://github.com/swsgbl/hmharness · Evidence: https://swsgbl.github.io/hmharness/evidence/aiobservabilityopensourceaudit

Red-Teaming Our Own Agent Sandbox: 9 Attack Payloads, All Blocked

杨洪付 — Sun, 25 Oct 2026 16:35:56 +0000

AI agents execute "commands generated by a model" — and prompt injection can steer that model into doing what an attacker wants. An agent without a sandbox hands your shell, filesystem, and network credentials to an executor that can be talked into misbehaving. A sandbox is not optional; it is the foundation.

This post walks through the red-team test we built for the sandbox of hmharness — an open-source (MIT) agent framework for HarmonyOS/OpenHarmony development — and its results: nine real attack payloads, all blocked, with the suite living in CI as a permanent regression gate.

The foundation: three primitives (Sandbox 2.0)

Egress allowlist — outbound network is deny-by-default with an explicit allow table
Mount policy — filesystem boundaries the sandbox cannot cross
SecretBroker — secrets exist as reference handles; values are only resolvable under an active grant, and transcripts are automatically redacted. The model sees a handle, never the secret itself.

The nine payloads (Sandbox 2.1)

DNS-rebinding lookalike hosts — trick the egress allowlist with visually similar hostnames
Subdomain wildcard boundary — abuse of "*.example.com allowed" rules
URL userinfo/fragment spoofing — hiding things in the username and fragment segments
Path traversal — ../ escapes out of the workspace
Cross-drive escapes — Windows multi-drive-letter boundary differences
Cross-subject secrets — one session secret read by another session sandbox
Forged handle references — fake SecretBroker handles to resolve real values
Revoked token replay — reusing an already-revoked grant token
Grant confusion — grafting a high-privilege grant onto a low-privilege execution

All nine blocked.

The part that matters: it lives in CI

An "all green" result is nice, but the real value is that the suite runs on every change to the sandbox code — a regression-proof red team. Anyone who touches the sandbox meets the nine payloads first.

This completes a security trilogy: LSP pinning (supply chain: sha256-pinned language servers, tamper = refuse to execute) and the browser extension bridge (pairing code to local token, per-action approval for page_act) cover the other two capability surfaces. Every surface an agent has — execution, dependencies, browser — gets a defense, and every defense is itself testable.

The general lesson

Treat "the model will make mistakes" as a premise, not an exception. How much fault tolerance your system has for model errors determines whether it can run long tasks at all.

hmharness is an open-source (MIT) agent framework for HarmonyOS/OpenHarmony development: it wires project creation, checks, builds, signing, install, launch, log reading, and result verification into a local toolchain so AI does not just generate code — it proves results against the local machine. Independent community project, no affiliation with Huawei or OpenAtom.

GitHub: https://github.com/swsgbl/hmharness · Evidence: https://swsgbl.github.io/hmharness/evidence/aisecurityopensourceharmonyos