How an AI assistant works inside your ERP, within your permissions

The risk with an assistant that has its own keys

A common way to connect AI to business software is to give the assistant a service account with broad access, so that it can "do things". That makes the assistant the most privileged user in the building. It also makes audit harder, because the actions belong to the bot instead of the person who asked for them.

A safer design starts from the opposite rule: the assistant never has authority of its own. It borrows the authority of the person talking to it, for exactly as long as they are talking to it.

Same authority as the user

In Agaro a prompt carries the identity of the person who wrote it. Their role, their modules, their grants and their workspace decide what is allowed. The assistant inherits the same role, the same module access and the same workspace, with no elevated service account behind the chat window.

The permission model itself is the same one that governs everyone else. Every paid plan includes five built in roles (Super Admin, Manager, Employee, Developer and Viewer) and full role and attribute based access control: custom access groups with inheritance, access levels per module, read, write, create and delete rights per type of data, menu visibility, record rules and field level security. The same rules apply in the app, the API, MCP and the assistant.

One controlled path from prompt to record

A request does not go straight to the database. It follows the same path whether it comes from a click or from a sentence:

1. Prompt and identity. The person states the outcome. The signed in user and their workspace are the identity and the data boundary.
2. Access and data. Role, modules, grants and approval mode are checked first. Only then are the real records and real values resolved.
3. Engine, action and audit. Validation and calculations run, the same product action that a button would call executes, and the outcome is recorded under the person who asked.

The interface, the assistant, the API and MCP are four entry points into one shared action layer. A button click and an assistant tool call reach the same guarded business logic, so there is one set of controls and one audit trail.

Approval modes: who presses the button

Authority is only half of the question. The other half is who confirms. The default approval mode for the assistant is Ask first: the assistant prepares the change and pauses for your approval before it is applied. You see the proposed action, approve or reject it, and the result is recorded in the workspace activity history.

An account can explicitly opt into Approve for me. Even then, the confirmations that are required depend on how risky each tool is and on the approval settings the account has configured. Review consequential actions before relying on them, and inspect the resulting record.

The interactive assistant and Scale AI agents are different capabilities. The assistant helps a person do their work. Agents on the Scale plan do work for you, and they ask for approval before they act. The plan details list what each plan includes.

What to check in any assistant

• Does it inherit the asker's permissions, or does it use a separate account?
• Are its actions recorded under the person who asked, in the same log as everything else?
• Can I make it ask first, and can I see exactly what it proposes?
• Do the API and MCP paths apply the same checks as the app?
• Is each company's data isolated from every other company's?

If a vendor cannot answer these plainly, the safest assumption is that the assistant has more access than any one of your people should.

Questions people ask