Agents that ask before they act.
Last updated: 2026-04-27 · Read time: 4 minutes
An AI agent is a program that can touch your data, spend your money, and talk to the outside world on your behalf. Most agent products ask you to trust them with all three at once. GnamiAI is built on the opposite assumption: the agent has no capability it wasn't explicitly granted, every destructive move pauses for a signed approval, and the entire runtime lives in a browser tab you can close.
How is a browser AI agent runtime different from a Docker or local sandbox?
Sandboxing isn't binary. Three architectures dominate today's AI agents — each removes a different attack surface, and the right choice depends on what you're letting the agent touch.
| Architecture | Shell access | Filesystem | Escape risk |
|---|---|---|---|
| Browser-first (GnamiAI) | Not registered | Not registered | None — capability doesn't exist |
| Docker / microVM sandbox | Present, container-bounded | Container disk | Kernel CVE → host escape |
| Local install (e.g. CLI) | Full host shell | Full host disk | Already on your host — no boundary |
Browser-first wins on blast radius: a jailbreak prompt can't toggle on a capability that was never registered in the runtime. It loses on raw flexibility — you can't run arbitrary tools — which is exactly the trade we want. Read the full guide →
What are the six pillars of GnamiAI's design?
Each pillar serves one goal: every capability is explicit, every destructive move is approved, and nothing lives outside the browser.
Pillar 1 — Granular permissions: how is access scoped?
Capabilities are scoped per role and per resource. Connecting a provider doesn't grant shell access. Installing a skill doesn't grant the network. Loading memory doesn't grant writes. The default is deny; each capability is an explicit, named grant.
Pillar 2 — Human-in-the-loop: when does the agent pause for approval?
Any action flagged destructive, irreversible, or side-effectful against a third party pauses the turn. The UI shows you exactly what the agent wants to do, in what context, against which account. You approve or reject. The agent does not proceed without an approval record tied to the turn.
Pillar 3 — A real dashboard, not a chat: where do approvals, memory, and budgets live?
Approvals, memory, budgets, skills, subagents, schedules — these aren't buried in a chat thread. They're their own pages. You can audit your agent without scrolling a transcript.
Pillar 4 — Signed skill registry: how are AI skills made safe?
Skills are the way an agent learns new behavior. In GnamiAI they're plain-text SKILL.md files. Skills installed from an external URL are fetched server-side, content-classified to reject HTML and binary payloads, and NUL-byte-scrubbed before they're stored. The registry roadmap adds signature verification and a manual review gate before community skills can be distributed.
Pillar 5 — Zero-config memory: how does the agent remember things?
Conversational memory shouldn't require JSON surgery. GnamiAI connects
to Mem0 with one API key; facts you want the agent to remember long-term
get saved with /remember or via a structured agent action.
Memory is scoped to your account by default, or to an entity id you
provide if you want cross-tool continuity.
Pillar 6 — Multi-agent, capability-scoped: how do subagents hand off tasks safely?
Specialized subagents hand tasks to each other with context slices, not full transcripts. A research subagent doesn't get your memory. A coding subagent doesn't get your skills registry. Capability scoping is the handoff contract, not a suggestion.
Where this goes next
The current hosted build runs entirely in the browser. There is no shell, no file-system mount, no background daemon. That constraint is load-bearing: capabilities that don't exist can't be toggled on by a jailbreak prompt.