> ## 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.

<div className="code-docs">
  <h2 id="trust">
    Mini App runtime
  </h2>

  A Mini App's Node code runs on your machine as your user, just like local plugins and MCP servers. It can read and write any file you 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.

  <h2 id="boundaries">
    Host security boundaries
  </h2>

  | 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 you 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` is denied unless declared, and its only value is `session.run` |
  | 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 |

  <h2 id="guard">
    Ports and credentials
  </h2>

  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:

  <Frame caption="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.">
    <img src="https://mintcdn.com/agent-en/mM6ovYl9sr4HdU6x/images/miniapp/credentials-en.svg?fit=max&auto=format&n=mM6ovYl9sr4HdU6x&q=85&s=ea2348c8dd3928d59421b6b657e428eb" alt="Credential flow" width="1200" height="540" data-path="images/miniapp/credentials-en.svg" />
  </Frame>

  * **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.

  <h2 id="agent">
    Limits of the Agent API
  </h2>

  * A Mini App can create background sessions, assign tasks, handle tool approvals and questionnaires, and list available models and agents, but no API reads your chat history or inserts messages into your chats.
  * Each Mini App can continue only sessions it created; the host records ownership.
  * These limits apply only to the host APIs; the Node process itself has no operating-system-level isolation.

  <h2 id="human">
    User confirmation
  </h2>

  * `message.append` needs your confirmation every time, and you send the message yourself. 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 your global permission rules, and approvals nobody can answer are denied. See [Who can answer an approval](/docs/miniapp/authors/agent#agent-interaction).
  * A Mini App can't read chat history or change sent messages.

  <h2 id="limits">
    Known limitations
  </h2>

  * 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.
</div>