WhoDBDocs

Control database access

Decide who should be able to read or change a database before sharing a WhoDB instance. In CE, database credentials and deployment reachability define that access. A connection name or a confirmation dialog is not a per-user permission system.

Start with the database account#

WhoDB executes queries using the connected credentials. For an inspection task, use an account with the read access the task needs. Use a separate account for approved writes rather than giving everyone a write-capable connection for convenience.

Test the account against a known object. Confirm both what it can read and what it should not be able to change. A successful login establishes connectivity, not that the account has the intended privileges.

When a user reports a permissions error, inspect the database account and object privileges. Changing an interface preference cannot grant a privilege enforced by the source.

Understand shared profiles#

A server-configured profile supplies database connection details under an alias. Anyone who can reach that CE instance can select its configured profiles and connect with the profile's credentials. The alias is not a password.

For example, a shared reporting profile should use an account suitable for everyone allowed to reach that instance. Do not put a production write profile beside it and assume people will use only the safer option.

Use separate instances or access paths when audiences need different boundaries. Configure network access before distributing the URL. See profile setup for the environment-variable format.

Distinguish controls from permissions#

An action can be absent because a source does not support it or an object is not writable. That is different from enforcing what a database account is allowed to do through every query path.

Query confirmation asks you to review an execution. It does not replace source permissions. Use the same principle for MCP query modes: choose a restricted mode and restricted credentials for the assistant's task.

Recheck access when the deployment changes#

When adding a profile, changing its credentials, or exposing the instance to a new network, test with the intended audience's connection path. Check visible objects and permitted operations again before treating the old access assumptions as valid.

Was this page helpful?