cd /news/ai-agents/leases-not-switches-rethinking-permi… · home › topics › ai-agents › article
[ARTICLE · art-158193] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=↑ positive

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.

read2 min views1 publishedOct 26, 2026

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

── more in #ai-agents 4 stories · sorted by recency
── more on @hmharness 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/leases-not-switches-…] indexed:0 read:2min 2026-10-26 · —