Tokens and permissions

A connector token combines an identity, an expiry, one connection, and independent action plus resource scopes.

Token lifecycle

Choose a clear label and an expiry of 30 days, 90 days, one year, or never. Automata shows the raw token once and stores only a SHA-256 hash with last-used, expiry, revocation, and scope data.

Treat the token like a password. Use one token per client or automation so access can be revoked independently.

Action scopes

A token can expose all tools for its connection kind or a chosen subset. Disabled tools are not registered for the MCP request, and direct attempts to call them fail.

PostgreSQL tokens start read-only. Sending messages and running database statements must be explicitly enabled.

Resource allowlists

WhatsApp and Telegram chats: list tools return only allowed chats. Read and send tools refuse an out-of-scope chat. Unrestricted search is narrowed in the query itself.

PostgreSQL tables: catalog tools hide out-of-scope tables. Query and statement tools inspect the query plan before execution and refuse any referenced table outside the allowlist. Names are case-sensitive, and allowing a partitioned table includes its partitions.

Edit, expire, or revoke

Scope is loaded on every request. Editing it takes effect immediately without changing the token value or reconnecting the client. Expiry and revocation also take effect immediately, even when the underlying account or database is unavailable.

A lost token is replaced, not recovered.

Security boundary

Token scopes are strong model guardrails and prevent accidental cross-resource access. They do not replace upstream permissions:

• Use a least-privilege PostgreSQL role.
• Keep Evolution and Telegram administrator keys server-side.
• Use separate connector tokens for unrelated clients.
• Revoke tokens that appear in logs, chat, or source control.