Security and compliance

This page describes the controls implemented in Nuntius — never a certification. Nothing here replaces your own risk assessment or your own compliance audit; it’s an honest, plain-language description of what mechanisms exist today and where they live.

Four access layers, on everything new

Before any action reaches your account’s AI agent — or any identified caller, such as an API key or a Platform session — it passes through four independent checks, in this order:

1. Existence for your account. A connected integration, or a template, only exposes the specific actions you turned on, one at a time — nothing arrives “wide open by default”.
2. Visibility to the agent. Every AI agent has its own resource scope (tags); an agent may not see a resource even if your account has it connected — denied by default, total.
3. Audience of the piece. Every action, template or document declares whether it’s Internal or Both — an anonymous channel visitor (say, your website’s public widget) can only reach what’s marked Both; everything else is Internal by default, no exceptions.
4. Permissions of the caller. 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 may do, intersected with what that key or channel was granted.

All four layers are enforced on the server, not by the language model’s own judgment — a prompt instruction never replaces a code-level check.

Per-account isolation and audit

Every account (tenant) is an isolated compartment: every piece of data is filtered by your account’s id on every query, and an id belonging to another account on any route responds “not found” — never “not authorized”, which would confirm the data exists. Sensitive actions are recorded in a per-account audit log, viewable from the Platform.

A curated public API, not generic access

The public API (/public/v1, see Getting started with the API) exposes exactly 5 resources — leads, contacts, conversations, appointments, tickets — and nothing else: there are no routes for billing, team, settings or administration, whatever your key’s permission is. Every key declares its own read/write scopes per resource when it’s created, and that selection is sealed. Nuntius’s own MCP server (see MCP) is an adapter with no database or state of its own: it forwards your same key to this same API, call by call — all the real control lives in the API, never in the adapter.

The copilot: reviewed and approved, in plain language

The on-screen copilot (where available) lets an assistant navigate, highlight or fill in fields, and — with your explicit confirmation — click a real button. The assistant reads a “manifest” describing your own site’s screens; that manifest is data you send, never an instruction the system trusts blindly. Eight concrete defenses protect it:

1. It’s data, never an instruction. The manifest goes through the same anti-injection filter as any other tool in the system before it ever reaches the language model.
2. Closed vocabulary. Only the field, action and anchor types already documented exist — anything else is rejected with a concrete reason.
3. Hard limits on size, count and length, checked before anything else.
4. Human review of every version, and per-action activation, off by default.
5. A per-session fingerprint. If the manifest changes, the copilot turns off until someone approves it again.
6. The plan is validated on the server against the approved manifest: the assistant can only refer to ids that genuinely exist there, and any action that saves is always forced to require confirmation, whatever the plan itself says.
7. The client itself enforces the confirmation, in case the server ever failed — a second, independent mechanism, never a single point of failure.
8. Origin and session bound. The manifest is only accepted from your channel’s allowed origins, and a result is only accepted for the plan and the session that requested it.

No action that saves, sends or deletes ever runs without explicit confirmation — that’s the product’s minimum floor.

Transparency and training (AI Act, Regulation (EU) 2024/1689)

• Art. 50 — everyone who talks to a Nuntius agent knows it’s an AI, on every channel and in every language you serve your customers in.
• Art. 4 — the product documentation (this site, and the product guides) is written so your own team can understand how the system that manages their account works.

Data protection (GDPR)

Nuntius plays a dual role, depending on which data:

• Data processor for your end customers’ data (the leads, contacts and conversations you manage in your account) — we process and store it on your behalf, under your contract’s guarantees and our data processing agreement (DPA).
• Data controller for your own account’s data (your team, your billing, your configuration).

This includes an end customer’s right to erasure, and the duty to inform at every point their data is captured. More detail, applied specifically to the public API, in Data responsibility.

Keep going

• MCP — how your own AI assistant connects to your account.
• Authentication — the full scope catalog for an API key.
• Data responsibility — the GDPR split applied to your integration.

Questions about security or compliance? Write to legal@nuntius.chat.