> ## Documentation Index
> Fetch the complete documentation index at: https://agent.minimax.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Security model

> What a Mini App can access, and how the host restricts ports, credentials, and the Agent API.

## Mini App runtime

A Mini App's Node code runs locally as the current user, just like local plugins and MCP servers. It can read and write any file the user can access, start programs, and make network requests. Install Mini Apps only from sources you trust, and read the README before installing to see what data it accesses.

The host doesn't use operating-system sandboxes such as seccomp or seatbelt, mainly because of their cost to cross-platform support, debugging, and third-party dependencies. Instead, it strictly limits the capabilities it exposes to a Mini App, to guard against poisoned third-party Mini Apps and harmful code from Agent hallucinations.

## Host security boundaries

| Boundary | Implementation |
| - | - |
| Local only | Each Mini App runs in its own process and listens only on its assigned port on `127.0.0.1` |
| Port access | Each run gets one credential, usable only by the Mini App page and the managed MCP client; other local processes, other browser tabs, and DNS rebinding requests get `401` |
| Plugins never handle credentials | Third-party services are called through Host Connector with the account the user authorized in MiniMax Code; the Mini App stores no credentials |
| Pages never handle credentials | Host credentials, internal ports, run IDs, and Connector tool references are never exposed to the page |
| Explicit grants | `hostConnectorAccess` lists the allowed providers; `agentAccess` declares `session.run` and `session.read` separately; `toolAccess` and `deviceAccess` are declared as needed. Capabilities requiring a declaration are denied when undeclared |
| Permission switches | Users can turn declared capabilities off individually in plugin details; the host checks calls again without restarting the Mini App |
| Immutable runtime copy | The process starts only from a copy the host made and re-verified, so changes to source files after publishing don't take effect |
| Window limits | Always-on-top and click-through can be turned on at runtime only if the manifest declares them; switching window mode requires a user action; the window must overlap a visible display |

## Ports and credentials

A Mini App listens only on a local address, but other processes and browser pages on your machine can still reach its port, including malicious pages that use DNS rebinding. The host therefore checks the caller's identity at the port:

![Credential flow](https://mintcdn.com/agent-en/mM6ovYl9sr4HdU6x/images/miniapp/credentials-en.svg?fit=max\&auto=format\&n=mM6ovYl9sr4HdU6x\&q=85\&s=ea2348c8dd3928d59421b6b657e428eb)

The credential passes only between the host, the request guard, and the Agent's MCP client; the page, plugin code, and outside callers can't obtain it.

* **One credential per run.** Each time the host starts the process, it generates a random 32-byte credential and gives it to the request guard in the child process, the host main process, and the Agent's MCP client. The page never holds it.
* **The guard loads before plugin code.** The child process receives an initialization message over IPC, and a missing or extra field fails startup. It then installs the guard at the request dispatch entry of Node's built-in HTTP server, and only then loads plugin code. Every `node:http` server the plugin creates therefore receives requests only after the guard has checked them.
* **Host and credential checks.** `Host` must equal `127.0.0.1:port` exactly, which blocks DNS rebinding, and the credential is compared in constant time. WebSocket upgrades and CONNECT requests are checked the same way. Once a request passes, the credential is removed from its headers before plugin code sees it.
* **The host adds the credential to page requests.** When the page sends a request, the host main process checks its real origin and then adds the header, overwriting any header with the same name the page set itself. When the Agent reaches the MCP endpoint, its MCP client carries the credential in request headers, never in visible configuration.

The request guard runs in the same process as plugin code, so it can only stop outside callers from posing as the host; it can't isolate a malicious plugin.

## Declarations and permission switches

Each Connector provider, Agent grant (`session.run` and `session.read`), `toolAccess` grant (`call`), and microphone, camera, and system notification permission has its own switch. Declared permissions start on, and users can turn them off in plugin details at any time. The declaration does not change, so the interface object stays present and code must handle refused calls. Every `context.tool` call also follows the user's Agent tool permission rules, with a host prompt when confirmation is needed.

Turning off Connector or tool access refuses new calls. Turning off `session.run` stops this Mini App's active Agent turns; turning off `session.read` ends its session observers. Turning the switch back on allows new calls again.

### Page device permissions

Microphone access requires `microphone` in the manifest's `deviceAccess` and its permission switch to be on. Switching it off refuses the next `getUserMedia` or `speech.transcribe` call. The host does not forcibly stop a recording stream the page already holds; the page must stop its tracks.

Camera and system notifications are officially supported from MiniMax Code v3.1.9, declared with `camera` and `notifications` respectively. Users can turn either permission off independently. Turning off camera access refuses new capture requests; the page must still stop video streams it already holds. Combined audio/video requests require both microphone and camera to be declared and enabled; disabling either refuses the whole request.

Turning off notification access refuses new notification requests. Display also depends on the operating system's notification permissions and settings. A notification click can be handled only by the page that created it while that page is still running; after the page closes or reloads, an old notification cannot reopen the Mini App. See [Page device APIs](https://agent.minimax.io/docs/miniapp/authors/client-api.md#devices) for declarations, version requirements, and usage.

Other unavailable page permissions, such as location, clipboard read, and screen capture, are denied by default. These gates apply to host-managed pages; they do not place Node code in an operating-system sandbox.

## Limits of the Agent API

* `session.run` lets the Mini App create and continue its own Agent sessions, handle tool approvals and questionnaires, and list models and agents. The host records ownership; this grant does not let it control the user's other sessions.
* `session.read` independently grants listing, reading, and observing the user's visible sessions, including session details and final turn replies. It does not grant running turns, approving tools, or answering questionnaires. Neither grant implies the other.
* `message.append` can change only the unsent input draft after confirmation. It cannot change sent messages or send on the user's behalf.
* These limits apply only to the host APIs; the Node process itself has no operating-system-level isolation.

## User confirmation

* `message.append` needs user confirmation every time, and the user sends the message. The host checks the caller against the real page that Electron reports.
* Agent approvals offer only "allow once" and "deny". A Mini App can't change the user's global permission rules, and approvals nobody can answer are denied. See [Who can answer an approval](https://agent.minimax.io/docs/miniapp/authors/agent.md#agent-interaction).
* `context.tool` uses the host's own tool approval prompt, where the user can choose "allow once", "always allow", or "deny". Only the user's "always allow" choice in that prompt writes a global rule; a Mini App cannot answer it. See [Unified tool entry](https://agent.minimax.io/docs/miniapp/authors/data.md#tools).
* Reading and observing user sessions requires `session.read` to be declared and enabled. `message.append` grants no read access and cannot change sent messages.

## Known limitations

* Port authentication only defends against other local processes and browser tabs, not against a malicious plugin itself.
* The host manages only the entry Node process. The plugin must clean up any child processes it starts in `dispose`.
* After a service restart, open tabs get `401` until they are refreshed or reopened.