Read the permission in context
A request to read conversations may expose more than the single channel you intended. Ask what data the permission covers, whether access includes private spaces, and whether the app acts on behalf of a person or a service identity.
Separate read and write access
Write access can send messages, modify records, or trigger workflows. Read access can disclose sensitive content. Review both. Use the narrowest supported scope and test with non-sensitive data before expanding the connection.
Review over time
Document who approved the integration, its purpose, and a review date. Reassess permissions after a feature change, an ownership change, or an incident. When it is no longer needed, revoke the authorization and rotate any shared secrets.
Review a request to read and post
An integration that posts project updates may request read access as well as write access. Ask whether it needs to read every conversation or only a designated space, and whether it can act as an individual or a service identity. Test with a non-sensitive project and compare the observed behavior with the documentation. If the provider offers no sufficiently narrow permission, record the residual risk and use the organization’s approval process.
Choose the next step
| Situation | What to check |
|---|---|
| Read access is broader than the job | Request a narrower scope or an alternative design. |
| Write access can affect many spaces | Limit destinations and define an approval process. |
| An integration changes owners | Revalidate permissions, purpose, and credentials. |
A practical checklist
- Identify the data and actions requested.
- Check the identity under which the integration runs.
- Limit scope and test with non-sensitive data.
- Record the owner and review date.