What a “HUMΛN-Compliant Extension” Actually Means

Today’s AI plugins are a mess. Browser extensions, Slack bots, “agents” that ask for OAuth to everything. Supply-chain attacks. Over-scoped permissions—“read all emails forever.” Security teams with no visibility beyond “some bot has access.” We don’t need fewer extensions. We need better ones: extensions that get their power through a trust layer instead of around it.

A HUMΛN-compliant extension is one that uses HUMΛN’s identity, capability, and responsibility layer—Passport, HumanOS, Capability Graph—so that power is scoped, auditable, and revocable. Here’s what that means in practice.

Why Extensions Are Still the Right Primitive

We want extensions. Calendar triage, expense approval, code review, infra maintenance—agents need to do things. But we also need to limit scope, enforce policy, and prove what happened later. So the question isn’t “extensions yes or no.” It’s “extensions that plug into a trust layer.”

Six Rules of a HUMΛN-Compliant Extension

1. All power flows through human.call().
The extension never talks directly to external systems with raw credentials. It calls abstract capabilities like human.call('send.email', ...). HumanOS routes that to the right connector under policy. So the extension doesn’t “have” Gmail—it has a capability that HumanOS resolves to a connector with scoped access.

2. No raw secrets, only Passport-bound tokens.
Extensions never see API keys or passwords. They get scoped, revocable tokens tied to Passport and org policy. A stolen extension can only abuse what it’s explicitly delegated—and delegation can be revoked.

3. Strict sandboxing and isolation.
Code runs in a sandbox (eventually WASM). No uncontrolled filesystem or network. Only allowed to call capabilities explicitly granted. So even if the extension is malicious, its blast radius is bounded by the capability graph.

4. Declared capabilities and risk levels.
Each extension ships a manifest: what it wants to do (read calendar, write drive, view payroll), what data classes it touches (PII, PHI, financial), and its risk category. HumanOS and org policies use this for install-time consent, policy decisions, and extra logging for high-risk actions.

5. Mandatory audit trail.
Every action carries user Passport, extension ID and version, capability used, time and context. Security and compliance can answer “which extensions touched payroll last month?” and “what did this extension do for this user last week?”

6. Revocation and kill switches.
Users can revoke an extension’s access. Orgs can block an extension globally, quarantine it, or restrict it to lower-risk scopes. In an emergency, one action can stop an extension from acting even if it’s still installed.

Trust Tiers: Not All Marketplace Items Are Equal

Private extensions: Single-org. HUMΛN enforces protocol invariants; the org handles code review.
Community extensions: Public, with basic automated checks (static analysis, dependency scanning). No deep security guarantee.
Verified extensions: Deeper review and runtime monitoring. “Verified” badge and stricter SLAs for revocation and incident handling.

That mirrors app-store thinking—but it’s built around a protocol and policy engine, not vibes.

Why This Isn’t “Just an App Store”

Yes, there’s a marketplace UX. No, HUMΛN is not “another AI app store.” The marketplace is discovery and distribution. HUMΛN’s value is the trust layer that all extensions must speak to. Even privately installed, non-marketplace extensions must be HUMΛN-compliant. The product is the identity + capability + responsibility layer.

The Payoff: Say “Yes” to Powerful Agents More Often

For developers: Implement capabilities, declare needs, let the platform handle keys, policy, and audit. One clear model.

For security and compliance: Visibility and control over what agents can do—not just a long list of OAuth grants.

For users: You can adopt powerful extensions (OpenClaw-style skills included) with a smaller blast radius.

Extensions are inevitable. Governance is optional—but only if you don’t care how it ends. We’re not trying to stop powerful agents. We’re defining the standard that lets them into the places that matter.

Next: Agents Before and After a Trust Layer—same “reschedule my life” request, two very different architectures.