1. Start with Slack permissions
A Slack app should request only the scopes needed for its documented behavior. Review which public channels, private channels, direct messages, files, and member details it can access. Then separate permissions that read data from permissions that post messages, upload files, or take actions as the app.
2. Verify tenant and channel boundaries
Ask the vendor to distinguish application-level tenant IDs from real runtime and storage boundaries. Useful answers explain how workspace identity is carried through every request, how stored state is partitioned, whether credentials are tenant-scoped, and which plans use shared hosts or dedicated compute.
Channel memory deserves its own question. A finance channel and a marketing channel should not become one undifferentiated context pool. Clear channel scoping reduces accidental disclosure and produces more relevant answers.
3. Follow credentials from connection to use
- Confirm credentials are encrypted at rest and in transit.
- Ask which runtime can decrypt them and whether the background systems that do not need them are excluded.
- Check how OAuth grants and API tokens are revoked when an integration is disconnected.
- Require a rotation path for long-lived secrets and a documented response for suspected compromise.
4. Separate model processing from stored memory
The application, selected model provider, and connected tool may each process different parts of a request. Ask which provider receives message content, files, tool results, and credentials for every supported route. Confirm whether customer data is used for training and whose retention and account terms apply.
5. Require explicit action policy
An agent that can use tools needs more than a single on/off switch. Low-risk reads may run automatically, while sending, publishing, deleting, changing permissions, or spending money should be separately controllable. A strong policy model also defines what happens when nobody is present to approve a scheduled task.
Read access, write access, and unattended execution are three different security decisions. Evaluate them separately.
How Yasmine applies these controls
Yasmine uses tenant-scoped runtime identity, encrypted state, and encrypted credentials. Free and Starter run in separate containers on shared AWS hosts; Dev uses dedicated Fargate compute. Tool calls follow configurable Allow, Ask, or Block policy, and unattended Ask denies. The selected model provider processes requests under its terms; Yasmine does not train its own models.
Read the full security overview, review the subprocessor list, and use the contact page for a security review before rollout.