Security

Three checks gate everything the assistant reads or writes, and all must pass:

None substitutes for another. An agent permitted * reaches everything the user can see and change — and nothing more. Agent permissions and restrictions only ever narrow: they cannot hand a user access to a model their own permissions deny.

Every way the assistant reads or writes a record is held to the acting user’s own permissions — the platform’s permission records, and nothing else:

What the assistant asks for and may not read is refused, naming the field. What comes along unasked — a record’s name field, a relation’s name, a tracked change — is withheld and listed under $hidden on the value that would have held it, so the model knows something is there and does not take the gap for "no data". A relation into a model the user may not read is its id alone. A write naming a field the user may not write is refused, the field named by its path (items[2].discount).

The same holds where no tool is called: a mentioned user’s details, the field a message was sent from, the record open beside the chat, and knowledge drawn from records — each held to the agent’s reach and the AI policy too. What the user configures or is shown rather than what the agent reads stays on the user’s permissions alone: which knowledge bases they may use, the pinned subject’s label in their chat list, where a recap may be posted, and a file they attach to a message, which is theirs to hand over. A record knowledge source declares the fields its template reads, the template renders from those alone, and a record’s text is shown only to a reader who may read the record and every one of them — see Knowledge.

A call with no user is refused, never treated as trusted: an assistant call always runs as someone, a workflow <agent> node as whoever started the run. Nothing in these checks swallows a failure either — a check that throws fails the call.

The assistant is stricter than the web client in three places, all deliberately: the activity it reads withholds tracked changes of fields the user may not read, which the activity stream in the browser shows; administrators are held to field rules, which the browser shows them past; and a query that selects no columns, which would return whole records, is refused.

A permission denial names the operation and the model — "you are not allowed to read User records" — so the assistant can relay a real cause instead of inventing one. It never names the rule, role or condition behind the denial: the user learns that access is missing, not the shape of the policy that withheld it.

Code an administrator wrote runs as that code always has, and is not filtered: script, action, HTTP and MCP tools, a workflow’s prompt templates, a record knowledge template’s own script helpers, and a form’s onChange and onSave when a procedure runs it. What such code hands the model is its author’s decision. An agent’s permissions do not narrow it either, and what it returns is not recorded as data that entered the conversation (see What leaves with a conversation).

This is deliberate: such code reads through the platform’s own API, not through the assistant’s checks, and its result is whatever value it builds — the platform cannot tell which fields it came from. Checking it would mean either trusting a declaration an administrator must keep in step with the code, or treating every result as unknown data, which would bar the conversation from any model not cleared for everything. The administrator who writes the tool knows what it returns; granting it to an agent is the decision.

An agent reaches only the data models its job needs, listed on the agent’s Permissions tab — see Restrict what an agent can touch. Each row names an object and the operations the agent may do there:

An agent’s rows add up: * read and Order read update let it read everything and change orders. An agent consulted by another is held to the permissions of every agent on the way to it, so a narrow agent cannot reach further by consulting a broad one.

Restrictions say what the AI may never read, whatever the user’s own permissions allow: "the assistant may not read `Employee.salary`", "payslips never reach the AI", "contact details stay off models hosted in the US". They hold only when the assistant acts; the same users keep full access in the web client. What the AI may change is not decided here: that is the agent’s permissions — see Agent permissions.

Restrictions live in data policies, under AI  Governance  Data Policies. A policy says both what it hides and where.

Approval & safety covers the safety levels (READ_ONLY/WRITE/DESTRUCTIVE) and the requiresApproval flag that decide whether a tool call pauses for approval. Two things sit on top of that gate:

A paused call shows the tool’s actionLabel on the confirm button and, behind What was asked, the exact arguments the model proposed — so what gets approved is the call itself, not a description of it. Once decided, the card records who allowed or refused it.

Once a shared conversation has fresh text from someone other than the summoner, an internal risk-assessor agent screens it for prompt-injection and manipulation attempts before the target agent reads it. Findings surface as a notice to the summoner and are folded into the prompt as distrust anchors for the model.

This is a mitigation, not a gate: the screen fails open on any error or timeout, so a screening failure never blocks the turn. The approval escalation above is what actually stops a mutating call — the screen only makes the model, and the summoner, better informed going in.

HTTP tools and MCP servers are held to the same address defenses, so an internal service is never reachable by pointing either one at it — see HTTP tools and MCP servers for the rule and how each is configured. MCP alone additionally requires the host to be on an administrator’s allowlist before any connection is attempted at all, and pins the resolved address for the life of the connection.

A SCRIPT tool’s JavaScript runs through the same engine, and under the same Scripting Security Policy, as any other script action in the platform — the same class allowlist/denylist and execution timeout apply. Granting a SCRIPT tool is granting the agent model-directed code execution, and should be treated with the same care as granting a person that capability.

A workflow <agent> node — or any other caller that runs an agent without a chat session behind it — never sees a CLIENT tool (there is no browser to execute one in) or a tool that would need approval, even one whose requiresApproval is off by default: DESTRUCTIVE tools always, and any WRITE tool or non-system mutating tool with approval switched on. There is nobody to grant it. These tools are withheld before the model ever sees them, and a call to one anyway is refused with an error the model can recover from rather than left to stall the turn.

An agent invoked this way also receives a prompt-level instruction not to mutate data on its own — the workflow performs any persistence based on its answer instead. That instruction is a hint to the model, not an enforcement mechanism; the tool withholding above is what actually holds.

Provider API keys and tool/server secrets (AiProvider.apiKey, AiTool.secrets, AiMcpServer.secrets) are stored encrypted and masked as passwords. Conversation content (AiChatMessage) is not separately encrypted — it is a plain column, governed by ordinary Axelor field and row permissions like the rest of the application’s data, not by any AI-specific protection.

Every LLM call is logged to AiUsageLog with its model, provider, token counts and latency, attributed to the calling user and, for a chat call, the conversation — see Usage Policies & Logs. The log records tokens and latency, not a computed cost.