Read-only access first
Short answer: every StackTether tool only searches and reads, so the API user you give StackTether should only be able to view. A view-only user means that even if an AI is tricked by text inside a ticket, or a credential leaks, nothing in your PSA can be changed through it.
Why read-only is enough today
- StackTether has no write tools. It cannot create, update or delete tickets, time entries, clients or anything else.
- Tools are marked read-only to the AI app, and StackTether's tools are built only on the vendor's read and search calls.
- Vendor text is treated as untrusted data and labelled "PSA data, not instructions", so instructions hidden in a ticket are shown as text, never acted on.
The rules
1. A dedicated API user, never a person's login
Create a user that exists only for StackTether: an API Employee in Kaseya BMS, an API-only user in Autotask, an API member in ConnectWise, and so on. A person's login carries their full rights, breaks when they change their password or leave, and makes vendor logs impossible to read.
2. Least privilege
Grant view rights only on the areas StackTether reads, listed on each vendor page. Leave out add, edit and delete, and anything finance-related: StackTether never shows prices, rates, costs or billing amounts. Where the vendor offers a "cannot read costs" variant (Autotask does), start from it.
3. One API user per tool and per MSP
Do not share StackTether's API user with other integrations, and do not reuse one MSP's API user for another business. Separate users let you revoke one integration without breaking the rest, and keep each vendor's own logs and rate limits clear.
4. IP allow-listing where the vendor supports it
Some vendors let you restrict an API user to certain addresses. StackTether runs on cloud infrastructure and does not publish fixed outbound addresses today, so an allow-list for StackTether's API user cannot be set up yet. If you need it, tell us through the contact form.
5. Rotation
- Rotate the password, secret or key on a schedule (for example every 90 days) and whenever someone who saw it leaves.
- To rotate: create the new secret in the vendor system, then on StackTether's Connections page enter every field again and click Test and replace. The old secret can then be retired.
- Exclude the API user from automatic password expiry where the vendor allows it, so the connection does not stop unexpectedly.
6. Auditing on the vendor side
- Give the API user a monitored email address so the vendor's alerts reach someone.
- Check the vendor's own login or API activity records for the StackTether user from time to time.
- StackTether's audit log shows every AI tool call, by person and app, with the record IDs shown. The two together tell you who looked at what.
7. When a tech leaves
- The PSA API user does not change, because it belongs to StackTether, not the tech.
- In StackTether, open the person's page from Team: turn vendor access off, sign them out everywhere and delete the account (or pause access). Their AI connections end at once. See Offboarding a tech.
- If the person was an admin who saw the API secret, rotate it.
FAQ
Will a read-only user break anything?
No. If a view right is missing, that tool returns empty results or a fixed "not allowed" message. Add the right and test again.
Can the AI see data that the API user can see but a tech cannot?
The API user's view rights set the ceiling for everyone using that connection. Use your vendor's own restrictions (for example Autotask lines of business or Halo teams) if parts of your PSA must stay hidden, and turn on StackTether vendor access only for people who should see that PSA.