This article explains the security rules of the Teamso MCP connection: what the assistant can reach, what it can never do and how to protect your token. It is for every user and for the administrators who manage the company security settings.
Before you start
Know what a token is and how it is created (Creating an access token).
Know your company's security settings (IP restriction, MFA) (Security and access settings).
Step by step: the rules
The assistant works with your permissions. The token is tied to your account and your current permissions. What you cannot see on screen the assistant cannot see either; unless you are a manager you cannot approve someone else's leave, and you only see your own payslips. If your permissions change, the assistant works with the new permissions at once (Responsibility management).
No AI runs on Teamso's side. Your own assistant (Claude, Cursor, ...) understands the question and decides which tool to call. Teamso only performs the call. What you type to the assistant is subject to your assistant provider's terms.
Some operations are never available with a token. Even if you have the permission, these are rejected with a token (403 ACCESS_DENIED):
password changes, session operations and sign-in channel changes (phone number, email confirmation),
access token management (a token cannot create or list tokens),
integration keys, PDKS API keys and SSI/e-Bildirge credentials,
company security settings (IP restriction, MFA, account lockout, screen lock and the like),
Teamso support access,
company deletion and data reset,
creating, changing and deleting webhooks (webhooks can be read).
Leave actions are confirmed with an SMS code. Creating and cancelling a leave request is verified, as on screen, with a code sent to your phone that is valid for 3 minutes. The code comes to you; the assistant cannot know it unless you tell it.
Approval flows are never skipped. Requests created with the assistant go through the same approval process as on screen; the assistant can only decide requests that are at your approval step (Approval process).
The IP restriction applies. If your company restricts IP addresses, requests with a token follow that rule too. The hosted server forwards your real IP address in signed form; the local package in Claude Desktop connects directly from your computer's IP address.
Every write is audited. Changes made with a token are written to the audit log with MCP as the source, together with the token that was used (Transaction History).
The token itself is not stored. Teamso keeps only a hash of the token, which is why it is shown only once. The hosted server neither stores nor logs the token.
Keeping your token safe
Never share the token; do not put it in emails, chats or shared files.
Create a separate token per assistant or computer; if you lose one you revoke only that one.
Prefer 30 days, 90 days or 1 year over unlimited validity.
Revoke the tokens you do not use on the MCP access screen. Revoking takes effect immediately.
If you suspect a token has leaked, revoke it at once and check its Last used date.
Result
If a user is deactivated or moves to another company, their tokens stop working (Deactivating an employee).
Every request with a revoked or expired token is rejected with 401.
Tokens are managed only in the user's own session; the Teamso support team cannot see or create your tokens in a support session (Support access).
Common problems
Symptom: When I ask the assistant to change my password or a security setting it says "403 ACCESS_DENIED".
Cause: These operations are deliberately blocked for tokens.
Solution: Do it on the Teamso screen, in your own session.
Symptom: The assistant's requests are rejected with "IP_NOT_ALLOWED".
Cause: Your company's IP restriction does not allow the address the request comes from.
Solution: Ask your administrator to add your IP address to the allowlist (Security and access settings).