Permissions for connected tools

Admin

Connected tools extend the assistant with your own systems — a database, a folder, a mailbox, an API or an MCP server. You decide at setup time which rights those connections work with. CompanyWizard can only do what the stored account is allowed to do.

This article describes how to grant those rights so that a mistake stays small.

The principle: least privilege

A connected tool gets exactly the rights its job requires — not the rights that happen to be at hand. Three questions before every connection:

Which data does the tool need? A table, not the database. A folder, not the drive.
Which kind of access does it need? Reading is almost always enough. Writing is the exception and needs a reason.
Who may call it? By default every user sees every active tool. On the Access tab you can switch a user to Restrict to selected tools. This applies to tools the user calls directly in chat — an agent runs the tools of its own configuration regardless.

Dedicated service accounts

Use a dedicated service account for each connection — not an administrator’s personal account and not a shared account already in use for something else. Three practical reasons:

Rights can be tailored. A database user with SELECT on three views is quickly created; an administrator account cannot be trimmed after the fact.
Logs become readable. In the target system’s log you immediately see that an access came from CompanyWizard and not from a member of staff.
Switching it off takes one step. You can lock a service account without anyone losing their work.

Name the accounts descriptively, for example svc-cw-sales-data rather than dbuser3.

Which tools can write at all

Many connections are read-only by design. It pays to know which ones are not — that is where, and only where, the risk of an irreversible action arises.

Connection	Write access possible?	What you configure
SQL data source	No. You define the query; only a single `SELECT`/`WITH` is allowed, and the transaction is always rolled back	Restrict the database user to reading and to the tables or views actually needed anyway
Calendar tools	No. No creating, changing, deleting, no invitations	Limit the calendar share to the calendars needed
Git tools (desktop)	No. `GitStatus`, `GitLog`, `GitDiff` are read-only	—
Workspace folder (desktop, built in)	Yes. `WorkspaceWrite` creates and changes files	Do not pick a workspace folder whose loss would hurt; check your backup
Folder tool (desktop)	Optional. `write` can be switched off and is off by default	Enable `write` only when the task demands it; keep the root path narrow
Mailbox tool	Yes. Marking and archiving are part of read access already; sending only with `send` enabled, only to recipients on the allowlist and by default at most 20 per hour (configurable)	Shared function mailbox rather than a personal one; enable sending only when needed
HTTP API tool	Depends on the method you set. `GET`/`HEAD` query, `POST`/`PUT`/`PATCH`/`DELETE` change — what a call actually does is up to the API	Token with the narrowest possible scope; prefer read endpoints
CLI command tool (desktop)	Yes, but state-changing or network-bound commands only run after you approve them in the dialog	Pin only the programs a task actually needs
External MCP servers	Yes, to the full extent of what the server offers	Restrict the server’s credentials; connect only servers whose tool set you know

The MCP row deserves the most attention. An MCP server brings its own toolbox, and CompanyWizard cannot set it tighter limits than the stored credentials do.

Rights per connection — concretely

SQL data source. Create a dedicated database user, give it SELECT only, on the tables needed or — better — on views created for this purpose. Views are the stronger instrument here: you can leave out columns the assistant should not see.

Folder tool. The root path is the boundary: paths outside it are rejected, including via .. and symbolic links. So choose it as narrowly as possible — the project folder, not the department drive. write stays off as long as nobody can name a reason.

Mailbox. A function mailbox, not a personal one. If the assistant is only meant to search and read, do not enable sending.

HTTP API. A separate token per connection, with the narrowest scope the API offers. When the token expires, renew it — a token without an expiry is convenient and stays valid for years.

Calendar. A dedicated account or a targeted share of the calendars in question. Not the managing director’s mailbox with full access.

MCP server. Before connecting, check which tools the server offers — after creation the dialog shows the tool list, and you can expand it in the server list at any time. Individual tools of a server cannot be switched off, only the whole server. Store credentials that are themselves restricted in the target system. For a server you do not operate yourself, this applies twice over.

Content from connected sources is data, not instructions

What comes back from a connected source may contain text phrased as an instruction to the assistant — a comment field in the database, a file in the folder, the reply of a third-party server. This is not a theoretical case; the field calls it prompt injection.

In practice that means:

Connect only sources whose content you consider trustworthy or check separately.
The less a connection is allowed to change, the less manipulated content can do. That is the actual reason for read-only being the default.

Not every write action is confirmed beforehand. The workspace folder asks in chat before overwriting an existing file (in plan mode before every write), and the CLI command tool only starts state-changing commands after your approval. For the folder tool, the mailbox, the HTTP API tool and MCP servers, CompanyWizard currently does not ask before writing; agents suppress write calls only in a dry run. There, the rights you grant are the effective boundary.

Credentials

Connection strings and tokens of configured tools, passwords of mailbox and calendar accounts and OAuth secrets of MCP servers are stored encrypted.

Exception: headers and environment variables of an MCP server are stored unencrypted and are readable for administrators in the form. An API key you enter there is therefore only as protected as the database itself. Prefer OAuth where the server offers it, and give a key in a header only the narrowest scope. → Environment variables & appsettings

Even so: a credential that was stored once should also be rotated once. Include connections in your usual password rotation.

Review regularly

Connections outlive the projects they were set up for. Go through the list of configured tools and MCP servers in your usual review cycle:

Is the connection still needed? If not, deactivate it.
Do the rights still match the task, or have they grown too broad?
Are the restrictions on the Access tab still correct, or has the group of users shifted?
Does the service account still exist in the target system, and is its password current?

What is actually being used shows up in the target system’s log — one more reason for the dedicated service account.

Checklist

A dedicated service account per connection, descriptively named
Read-only access unless writing is explicitly required
Data scope kept narrow: views instead of tables, project folder instead of drive
Tool access restricted per user deliberately rather than left at “all active tools” — keeping in mind that agents are not covered by it
Only sources connected whose content is considered trustworthy
Credentials included in the password rotation
Connections listed in the review cycle