Every Nuntius integration — a native connector, an external MCP server you register yourself, or a
copilot action — goes through the same four-step path before it reaches your AI agent or an identified
caller. This page describes the mechanism; the
**[Integration catalog](/en/integrations/catalogo/)** describes each concrete connector.

## 1. Connection

Nothing exists for your agent until you connect it. A first-party **connector** (HubSpot, say) connects
with a token or credential you generate yourself in the external system — the Platform **verifies that
credential against the real system** before storing anything; if verification fails, no credential is
saved. An **external MCP server (BYO-MCP)** is registered from **Settings → MCP servers**, with the
access credentials for the system you want to connect — the generic path for any system without a native
connector yet.

## 2. Action-by-action allowlist, denied by default

Connecting a system **doesn't turn anything on by itself**. Every concrete action that system can offer —
creating a contact, syncing a stage, adding a note — starts **off**; you turn each one on yourself, one at
a time, from the integration's own card. It's the same principle that governs your agents' resources
(documents, templates, MCP servers): without explicit activation, it doesn't exist.

## 3. Audience: Internal / Both

Every action declares whether it's **Internal** (your team only, or an identified caller) or **Both**
(also an anonymous visitor on a public channel, such as your website's widget). "Internal" is the default
for anything not explicitly declared. A `Both`-audience action that writes to the external system returns
an anonymous visitor only a minimal confirmation — never the full record, never a previous customer's
data — minimized inside the action's own executor, never left to the language model's judgment.

## 4. The caller's permissions

For an **identified** caller (a person with a session, an employee with their own channel, an API key),
your account's fine-grained permission catalog decides what they can do with that integration,
intersected with the ceiling of their access medium — a key's sealed scopes, or their channel's cut-down.
This layer is independent from audience: audience decides WHETHER an unidentified caller reaches the
piece; permissions decide WHAT an identified one can do with it.

All four layers are always enforced **on the server**, never as a prompt instruction the language model
could ignore.

## MCP servers: the generic mechanism

An MCP server is the bridge that connects your own business systems — your CRM, your catalog, your
calendar — to your AI agent, so the AI can query them **live** while talking, instead of relying only on
the documents uploaded to your knowledge base. There are two paths:

- **A native connector** (section 1) automatically registers a managed MCP server the moment you connect
  it — you don't edit or delete it from Settings, it's managed entirely from the integration itself.
- **An external MCP server (BYO-MCP)**, which you register by hand in **Settings → MCP servers**, covers
  any system without a native connector yet, with more configuration steps in exchange for more reach.

Either way, you scope which agents can access the server with **tags** — denied by default, same as any
other resource.

## BYO-MCP: under your own responsibility

Registering an external MCP server is an explicit option, clearly labeled as such: the system on the
other side of that server is yours, contracted and managed by you, not your provider. Nuntius
never offers an external MCP server "wide open" by default — every tool that server exposes still passes
through layers 2-4 above before it reaches an agent or a caller.

## Compliance: where your data ends up

When an integration action sends data to an external system (a CRM, a spreadsheet, your own helpdesk),
that destination system falls outside what Nuntius can guarantee or audit. You're responsible for
minimizing what you send, for your own information duties about that destination system, and for the fact
that erasing an end customer on the Platform doesn't automatically delete a copy already synced to your
own system. See **[Data responsibility](/en/admin/data-responsibility/)**.

## Pending walkthroughs

Some integrations have their full connection procedure documented and verified with real screenshots;
others don't yet. Every catalog page says so honestly in its own status section — a step is never
presented as verified when it isn't.

## See also

- **[Integration catalog](/en/integrations/catalogo/)** — every connector, its actions and its audience.
- **[Settings and integrations](/en/guides/ajustes-integraciones/)** — registering an MCP server of your
  own, step by step.
- **[Agent control: resources and permissions](/en/guides/control-del-agente/)** — the four layers in
  detail.
- **[Security and compliance](/en/security/)** — the same logic applied across the whole product.