Leases, Not Switches: Rethinking Permission Models for AI Agents

The open-source hmharness project, an MIT-licensed agent framework for HarmonyOS/OpenHarmony development, introduced a lease-based permission model in which every capability access passes through a central Capability Broker. Tokens carry eight fields including expiry and provenance, with a default one-hour TTL and a 24-hour hard cap and no permanent grants, and a worker tier rejects network, secret, process and device capabilities regardless of tokens held. The project also wires project creation, builds, signing, install, launch and log reading into a local toolchain so agents verify results against the local machine.

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. 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. 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. 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. 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. 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. 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. 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 https://github.com/swsgbl/hmharness · Evidence: https://swsgbl.github.io/hmharness/evidence/aisecurityarchitectureopensource https://swsgbl.github.io/hmharness/evidence/aisecurityarchitectureopensource