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

# Security model

> What the platform assumes about your server, and what it will not do for you.

The platform treats a tool server as a **trusted party with an untrusted
surface**: you were deliberately connected, and everything you send is still
checked.

## What the platform enforces

<AccordionGroup>
  <Accordion title="Host allowlist">
    Only hosts on `MCP_ALLOWED_HOSTS` are contacted, and an empty list denies
    everything rather than allowing everything. A customer cannot point an
    assistant at an arbitrary URL — that would be SSRF plus a channel handing
    a stranger the conversation.
  </Accordion>

  <Accordion title="Description sanitisation">
    Descriptions land in the system prompt, so instruction-shaped text is
    stripped and the whole thing is capped and flattened to one line.
  </Accordion>

  <Accordion title="Name namespacing">
    Remote tools are exposed as `srv<id>__<name>`, so no server can shadow the
    assistant's own tools.
  </Accordion>

  <Accordion title="Tenant pinning">
    Every call runs inside an explicit tenant context. One workspace's
    assistant can only reach servers connected to that workspace.
  </Accordion>

  <Accordion title="Idempotent writes">
    See [Side effects](/mcp/side-effects).
  </Accordion>
</AccordionGroup>

## What you must enforce

<Warning>
  **Authenticate every request.** The token is per workspace. Treat it as the
  only statement of who is calling — never trust a workspace or buyer
  identifier that arrives in tool arguments, because those come from a
  language model.
</Warning>

* **Authorise per buyer.** `buyer_ref` says *who*; what they may see or do is
  your decision, resolved from your own records.
* **Resolve entitlements server-side.** Price tier, discount eligibility,
  wholesale access. If it can be passed as an argument, it can be argued into.
* **Validate arguments.** The schema subset is lossy, and constructs the
  platform drops are not enforced anywhere.
* **Never return another buyer's data.** A tool that takes an id and returns
  the record is a lookup oracle unless it is scoped.

## Prompt injection through content

A customer can put text in a product name. If your tool returns it, the model
reads it. Treat anything customer-authored that you return as data — do not
let it arrive shaped like an instruction.

## Credentials

Tokens are stored per server, write-only through the API: responses carry only
a "has token" flag and the last four characters. Rotate by submitting a new
one; a blank submission leaves the stored token alone.

<Note>
  Tokens are stored in plain text in the platform database, matching how other
  provider credentials are held. Scope them to the one workspace they serve
  and rotate them if a dump is ever exposed.
</Note>
