Governance: what the model is not allowed to do

Most of this category answers the question « how do you protect the data? ». That matters, and it is covered below. But an agent that acts raises a harder question: what stops it from doing the wrong thing, or from telling your customer it did something it never did? This page lists what is enforced, and where. Nothing here is a roadmap item.

​

The model is never trusted with what must be exact

Amounts are computed server-side. When a quote tool has a price grid, the model picks the SKU and the quantity — the server does the arithmetic and emits a numbered quote. A hallucinated price is not “unlikely”; it is structurally impossible, because the model is never asked for a number. Identity is verified by the server. A verified action carries the email the server confirmed — through a one-time code or a JWT your backend signed. If the model proposes a different address, it is dropped before the request is built. An agent therefore cannot act on behalf of someone who merely claimed to be them. Parameters are declared, not invented. A verified action accepts only the parameters you declared, and nothing else.

​

It cannot quietly claim to have acted

The weekly digest re-reads the week’s conversations and cross-checks what the agent said against the tool calls it actually made. An agent that told a visitor « I’ve passed your request on » without a submission being created is flagged as an unmet action. The digest also runs on a different model than the chat, and is prompted to be sceptical — a reviewer that shares its subject’s assumptions reviews nothing.

​

It escalates instead of improvising

Outside its scope, the agent hands the conversation to a human: you are notified, and the visitor is told you are taking over. Every captured request, quote and booking lands as a submission with a status — new, contacted, resolved — readable in the dashboard, over the API, or in the digest. An inbox, not a black box.

​

Outbound calls cannot reach your internal network

Every URL you configure — context webhook, verified action, corpus source — is re-validated before every call, DNS resolution included. Loopback, RFC1918 ranges, link-local and cloud metadata endpoints are refused, which also defeats DNS rebinding. Your secrets are encrypted at rest (AES-256-GCM) and decrypted only at call time; no API reads them back. Responses coming back from your systems are filtered before they reach the model: keys matching token|secret|password|credential|api_key|bearer are stripped, strings capped, arrays and depth bounded. Calls time out after 5 seconds — a slow backend degrades one answer, never the conversation.

​

Data

Hosted in France. GDPR applies, and the DPA is available at contact@animam.ai. Logs are redacted at the source. Emails, phone numbers, API keys, tokens, passwords and authorization headers are stripped by the logger itself, not by a convention someone has to remember. Error reporting is PII-scrubbed the same way. Consent is enforced server-side. A contact tool refuses to record a submission without confirmed consent — the check is not a checkbox rendered in a page, it is a condition in the handler.

​

Transparency is not optional

Every agent carries an AI disclosure banner. It stays even under white-label: hiding the “Powered by” footer is a paid capability, hiding the fact that a visitor is talking to an AI is not one. That is the EU AI Act, article 50, and it is treated as a legal obligation rather than a setting.

​

What we do not claim

Being explicit here is part of the point:

• No role-based access control between users of one account. API tokens carry scopes; humans in a dashboard do not have differentiated roles yet.
• No PII masking inside the prompt. We redact logs and error reports. What a visitor types goes to the model — as it must, for the agent to answer.
• No SOC 2 or ISO certification.
• Signed responses (Ed25519) are a pilot, not a shipped feature. See /trust.

If one of these is a requirement for you, say so before buying rather than after.