
Your Mastra agent creates Monday.com items on command. One bot token, five minutes of setup. The demo lands.
A week later, your ops lead wants their board included. Then marketing. Then a customer asks if the agent can update items inside their own Monday.com workspace.
Here is what you find: every one of those requests has the same answer, and it is the wrong one. The agent is not acting as users. It is acting as a credential. One credential, one scope, no boundaries between workspaces — nothing that maps to how Monday.com actually enforces access for humans.
The hard part is not the tool schemas. It is the credential architecture.
A shared service account bypasses Monday.com's permission model entirely. It is provisioned with admin-level access for convenience, which means the agent ends up with more access than any individual user would have. When that token is rotated or revoked, every user's agent breaks simultaneously.
The fix is not writing more auth code. It is removing per-user credential management from the agent entirely.
A single Monday.com API token or bot account creates a set of compounding failures. They surface in sequence.
The token belongs to whoever created it — usually the developer who built the agent. Every item creation, board query, and status update runs with that developer's workspace access, not the actual user's. A marketing manager creating campaign items lands them in the wrong workspace. A customer using your embedded project agent touches your internal Monday.com account, not theirs.
Service accounts are typically over-provisioned. Admin credentials get used because they are convenient at setup time. The blast radius of a single token leak is the entire workspace. No per-user revocation path exists. No per-user audit trail. No per-user scope.
Teams that try to solve this themselves quickly own a secondary product: OAuth flows for Monday.com, a token table per user, refresh scheduling, error handling for revoked tokens, and a mapping layer between internal user IDs and Monday.com identities. That is not the product they are building.
There are exactly two moments that matter in a multi-user Monday.com agent.
You control the identifier-to-user mapping. Scalekit controls the Monday.com token, refresh logic, and authorized tool surface. Your agent only ever uses the identifier.

Recommended Reading: Scalekit AgentKit Quickstart — connected accounts, scoped tools, and the execution model in one place.
Create a .env file:
Initialize the Scalekit client in a shared module:
Before the agent can act, the user's Monday.com account must be connected. getOrCreateConnectedAccount returns the current connection state. If the account is not yet active, generate a one-time authorization link.
The first run prompts the user to authorize. Every subsequent run uses the stored, automatically refreshed connection. You do not touch the token.
Do not pass the full Monday.com connector catalog to the model. Pass only the tools this user's connected account is permitted to call. listTools returns exactly that surface — nothing more.
What the user cannot do in Monday.com, the agent cannot do. Scope is derived from their connected account — not from a shared service credential provisioned for convenience.
Typical tools surfaced for an active Monday.com connection:
See the authoritative list for your live connection in the Scalekit dashboard.
Mastra requires tools to be registered with its createTool interface. This step wraps each Scalekit tool into a native Mastra tool that executes through the token vault — the agent calls a tool, gets a result, and never sees a credential.
Every executeTool call resolves back to that user's token inside Scalekit's vault. The agent runtime never sees a credential.
This is not a footnote. It is the architectural line that separates a secure multi-user agent from one with the exposure surface of a shared service account.
The identifier is the key that maps your user to their Monday.com connection. If an attacker can supply an arbitrary identifier — from client input, from an unvalidated cookie, from any untrusted source — they can call Monday.com tools with another user's credentials. No OAuth bypass required. No token theft needed. Just the wrong identifier in the right place.
The identifier must come from your authentication layer: your session, your JWT claims, your database record for the authenticated user. Credentials never touch the agent runtime. Handle the identifier accordingly.
Or with a custom prompt:
Expected output:
The full code is on GitHub. Clone the repo, configure your .env, and have it running in under 30 minutes.
You probably skipped the verification step.
After the user completes the Monday.com consent screen, Scalekit redirects to the userVerifyUrl you provided (or you call the equivalent in a protected endpoint). You must then call verifyConnectedAccountUser({ authRequestId, identifier }) after confirming (via your own auth) that the current logged-in user actually owns this identifier.
If you never call the verify step, or you call it with the wrong values, the account stays in a pending state.
The connected account for that identifier either never received the required Monday.com scopes, or the token was later revoked / the scopes were changed on the Monday.com side.
Re-authorize the same identifier by generating a fresh link with getAuthorizationLink. The user will see the current consent screen based on the scopes you configured on the "monday" connection in the Scalekit dashboard.
Two very common causes:
Rule: The identifier is sensitive. Always look it up from your database or session after you have verified that the current caller is allowed to act as that user. Never trust an identifier supplied by the frontend.
Just call getAuthorizationLink again with the same connectionName + identifier. Scalekit will detect the existing account and let the user re-authorize (or refresh) it. The identifier stays the same.
Yes. Use the exact same identifier value but pass different connectionNames when calling listTools / executeTool (or filter in the Mastra agent).
Fixing the credential model is not a security nicety. It determines whether the agent is usable as a product.
An agent operating on a shared Monday.com token cannot express per-user workspace access. It cannot be individually revoked without breaking every other user. It cannot enforce the permission boundaries Monday.com already enforces for humans. The agent becomes less capable than a logged-in user. It bypasses the permission model entirely.
Per-user connected accounts invert this. The agent inherits each user's permissions exactly — nothing more, nothing less. Users can connect and disconnect their Monday.com on their own. Token refresh runs automatically. You do not write the refresh logic that silently breaks at 3am when six customer workspaces stop updating.
The same identifier, the same pattern, the same architecture — across every connector Scalekit supports.
Browse all AgentKit connectors