This page describes the **controls implemented** in Aymar Agents — 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](/en/api/getting-started/)**)
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. Aymar Agents's **own MCP server** (see [MCP](/en/mcp/getting-started/)) 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 Aymar Agents 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)

Aymar Agents 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](/en/admin/data-responsibility/)**.

## Keep going

- **[MCP](/en/mcp/getting-started/)** — how your own AI assistant connects to your account.
- **[Authentication](/en/api/authentication/)** — the full scope catalog for an API key.
- **[Data responsibility](/en/admin/data-responsibility/)** — the GDPR split applied to your integration.

Questions about security or compliance? Write to **legal@aymaragents.com**.