How an agent connects and what it can reach

An agent connects by being added to your AI assistant as a connector; you sign in to Sonta once, through the assistant, and the assistant holds that authorization from then on. It works in one business at a time, remembered on your profile between sessions, and it can do exactly what your role permits. Nothing more.

Requirements

An account in the business, with a role carrying the permissions the work needs. The exact connection details are in Connect to the MCP server.

Before an agent can do anything with your records, two things have to be settled: who it is acting as, and which business it is working in. Both are explicit, and both bound everything that follows.

Signing in

Authorization begins with a person, not a key someone pastes into a config file. When you add Sonta to your assistant, the assistant sends you to Sonta's sign-in, and signing in authorizes that connection. From then on the assistant carries the authorization itself: inside a working session there is no separate sign-in step and no key to pass around.

The consequence is deliberate: a person with a Sonta account has to approve the connection. An agent cannot grant itself entry to a business.

Choosing the business

Authorization says who you are; it does not say where you are working. An agent works in one business at a time. It can list the businesses you belong to and switch between them, and the selected business is saved on your profile, so the next session starts where the last one left off.

That convenience cuts both ways when someone belongs to several businesses. The most common cause of "the collection does not exist" is not a missing collection: it is the right collection in a different business than the one selected, often one chosen in an earlier session. Confirm where you are before concluding something is missing.

An agent is bounded by its role

Because an agent acts as a person, it inherits exactly that person's permissions, the same roles described in How access works. A role that can read two collections and update one gives an agent precisely that reach; a request beyond it is refused, the same as it would be in the interface.

The practical advice follows directly: give an agent that works unattended its own account with a role scoped to the job, rather than connecting it as an administrator because that is convenient. An automated participant that can restructure your business is a much larger risk than one that can update the two collections it was built for. Scope narrowly, and widen deliberately if the work needs it.

Withdrawing access

Access can be ended from either side. In the assistant, remove the Sonta connector. In Sonta, access flows from a person and a role: change what the role permits and the agent's reach changes with it; remove the account and the connection stops working. There is no separate agent registry to clean up, which is the point of routing agent access through the ordinary access model.

Notes and limitations

• Sign-in happens once, through the assistant. A person with a Sonta account has to complete it, so a connection cannot be set up entirely unattended.
• The selected business persists. Switching it from an agent changes it for your account, including your next session.
• Permissions are the person's, not the agent's. There is no elevated agent mode.
• Business isolation applies to agents exactly as to people: one connection works in one business at a time.

Related

What an agent can do once connected is in Working with Sonta programmatically and What the tools cover. For agents working from inside Sonta rather than over MCP, see What an agent is. The boundary between businesses is in Businesses and multi-tenancy.