Security, Identity, and Permissions

Who Operator acts as, and what stops it going further

The single most important thing to understand: Operator does not have its own access to your ERP.net data. It acts with the identity of a real ERP.net user, and everything that user cannot do, Operator cannot do either.

Who the agent is

Internal connections (the normal case). You sign in to your ERP.net instance with your own account. Operator stores the resulting session for you, refreshes it in the background, and uses it for every ERP.net call made on your behalf — in chat, in apps, in scheduled runs. Your colleague asking the same question gets answers scoped to their rights, not yours.

Client connections. For customer- and partner-facing scenarios, an instance can expose a service identity instead, so external people can be served without an ERP.net login each. Those connections are deliberately narrow — see Client & Advisor capabilities.

Sessions expire. When yours does, Operator tries to renew it silently; if it cannot, you are asked to reconnect and nothing runs against ERP.net in the meantime.

Four layers of control

  1. ERP.net security. Roles and object permissions in your instance are the hard floor. Operator never bypasses them.
  2. Operator Permission Policies. An instance admin can narrow an Operator user further — for example read-only on Finance.*, no access outside Crm.* — even if their ERP.net login allows more. Policies are checked on every query and every write. See Permission Policies.
  3. Agent capabilities. An agent only has the tools you gave it. An agent without data-write capabilities cannot create or modify anything, regardless of your rights.
  4. Human confirmation. Destructive operations — deleting records, voiding documents — stop and wait for your approval before running.

Where credentials live

Multiple instances

You can connect several ERP.net instances (production, test, another company). A conversation is bound to the instance it started on and stays there — switching the instance at the top of the screen affects new conversations only, never one already in flight. Apps and agents follow the same rule, so data from two instances cannot bleed into one another.

Auditability

Every ERP.net call made through Operator can be reviewed: which user, which instance, which entity, success or failure, and the server's response. Instance admins can inspect this for the users they manage. Failed calls are always recorded, even for users who have request logging turned off.