Permission principles
- Grant read access broadly only where the user should be able to see the underlying documents or data.
- Limit create/write access to users who can change reusable configuration or durable business data.
- Treat workflow triggers, provider imports, API keys, MCP tools, exports, and publication as higher-risk capabilities.
- Use approvals before actions that publish, email, submit externally, or update records at scale.
Product access matrix
Known permission labels
TextMine uses explicit permission labels for some newer surfaces. Current examples include:
Permission labels may be combined with feature flags and organization configuration. If a page or action is not visible, check both the user’s permission set and whether the feature is enabled for the organization.
API keys and MCP access
API and MCP access should be treated like operational access, not just documentation access. Recommended rules:- Create API credentials only for users or systems that need them.
- Store tokens in a secret manager or local environment variable, not in prompts or docs.
- Scope tokens to the minimum organization/team/data access available.
- Rotate credentials if they are pasted into chat, screenshots, issues, or logs.
- Confirm before using MCP/API tools that send emails, import provider files, update records, publish documents, or call external systems.
Admin checklist
Before enabling a user or team, decide:- Which Vaults, teams, and data scopes they should see.
- Whether they can create reusable configuration such as workflows, playbooks, agents, schemas, or templates.
- Whether they can trigger actions with side effects.
- Whether they can approve or publish outputs.
- Whether they can connect providers or manage credentials.
- Whether they can export, email, or submit data externally.
- Whether API/MCP access is needed and how credentials will be stored.