to select ↑↓ to navigate
Docs

Docs

Security, permissions, and the audit trail

The copilot is governed at every step. This is the section to read closely when an IT or risk stakeholder asks "what stops it doing something it should not?"

Five layers of protection

1. Permission guard

Before any action runs, Copilot checks the signed-in user's permission for that record type and, where relevant, that specific document. Management reports also require a management role. If the check fails, the action is refused with a clear message.

2. Input sanitiser

Sensitive fields such as passwords and security tokens are always stripped. Sensitive record types such as Users, Roles, and System Settings are always blocked. Field names are validated and long inputs are trimmed.

3. Manipulation defence

A set of patterns detects attempts to make Copilot ignore its instructions, reveal its configuration, or switch into a privileged mode. Such attempts are flagged and recorded; the permission layer still enforces the real limits.

4. Rate limiter

Per-user limits per minute and per day prevent runaway usage. Users see a clear message and can continue once the window resets.

5. Field whitelisting

On top of the built-in blocks, administrators set precise per-record-type rules for which fields Copilot may read and write, and whether it may create, finalise, or cancel records of that type. See Settings.

The audit trail

Every action Copilot takes is written to an audit log that administrators can review. Each entry records:

Recorded Detail
Who and where User, company, and the conversation it belongs to.
What ran The action taken, the record type, and the specific document.
Inputs and outputs What went in and what came back, with long results trimmed.
Outcome Success, error, permission denied, or blocked.
Performance How long the action took.
Field access Which fields were requested and which were blocked.

Usage and cost visibility

Each conversation tracks how much processing it used, so administrators can see consumption per user and per session. This supports fair-use monitoring and internal reporting.

The governance message in one line

Copilot inherits your existing iVendNext access model. It never widens. It cannot read a field a user cannot read, cannot change a record a user cannot change, and writes every action to an immutable log.

Last updated 8 hours ago
Was this helpful?
Thanks!