Connector safeguards

The pattern, across all four connectors

Gmail, Notion, GitHub, and Linear each follow the same underlying safeguard pattern. That's deliberately kept consistent across all four, rather than allowing each connector's implementation to drift into its own bespoke set of rules over time. That consistency matters for a reason beyond tidiness. It means the mental model you build up from understanding how one connector's safeguards work transfers directly to the other three. You don't need to separately learn a different set of guarantees for each one. A separately-learned set would make it much easier for a genuine gap in one connector's protection to go unnoticed, simply because it wasn't obvious to compare against how the others behave.

Six specific properties make up that shared pattern. Each one is worth understanding individually, not only as an item on a list. Together, they're what makes connecting a real account to tAI a genuinely bounded decision, rather than an open-ended grant of trust. The list below covers opt-in connection, scoped access, the absence of standing copies, the absence of background polling, revocability, and visible connection state. Each of those six properties is enforced independently of the model's own judgment. That's the same layered-defense principle that runs through the Sandboxing page, applied here specifically to connected third-party accounts.

• Opt-in, one at a time. Gmail, Notion, GitHub, and Linear are each a separate, explicit connection. Connecting one never implies access to the others.
• Scoped access. A connector exposes only the specific, documented actions for it, never general account access. Connecting GitHub, for example, means picking one repository per conversation, not standing access to every repository your account can see.
• No standing copies. There's no cached mirror of your inbox, workspace, or repository sitting on our infrastructure between conversations. Each request goes back to the source.
• No background polling. A connected account is never checked on tAI's own initiative. If nothing in a conversation calls for it, nothing happens in the background.
• Revocable at any time. Disconnecting removes access immediately, including any cached credential. No residual token remains usable.
• Visible connection state. The Settings panel shows exactly what's connected and what it can do, the same information we have, not a simplified summary of it.

Scoped access deserves a bit more explanation than the single line above gives it. It's the property most likely to be misunderstood if left at that. Connecting GitHub doesn't hand tAI standing access to every repository your account happens to have permission to see. It means picking one specific repository for a given conversation. That choice is reviewed and confirmed before it becomes active. tAI then works against a sandboxed clone of just that one repository for that conversation, rather than a live connection with broader reach. Gmail, Notion, and Linear each apply their own version of this same narrowing, tailored to what that specific service's data actually looks like. The underlying principle is identical across all four: access scoped to exactly what a given task needs, and nothing broader.

Approval gates on real actions

Sending, publishing, or pushing to a default branch requires explicit human approval at the product level, in every case. That's true independent of how confident the model itself is that the action was correct and ready to go. That requirement isn't something the model can reason its way around by being sufficiently certain. tAI never sends an email under any circumstance. Every draft-creating tool only ever saves a draft for you to review and send yourself, on your own timeline and after your own read of the content. The same review-before-action pattern applies to a GitHub pull request. It applies to a Linear issue update. It applies to any other action with a real, externally visible effect attached to it.

This is enforced identically regardless of which connector is involved. It's also enforced identically regardless of which product surface is making the request. tAI itself, tCode, and a direct API integration are all treated the same way here. That matters, because it would be a meaningfully weaker guarantee if the approval gate only applied to some surfaces and not others. A developer building on the API directly still runs into the same underlying pattern. Drafts require explicit action rather than autonomous sending, even though the API surface itself is more flexible than the tAI product in other respects. That consistency is deliberate, not a coincidence of how each surface happened to be built independently.

Where the full detail lives

This page is deliberately the cross-connector security summary. It covers the pattern that holds true across all four connectors at once. It is not meant to be the complete, tool-by-tool reference for any single one of them. Each connector has its own complete, dedicated documentation. That documentation covers every available tool individually, the exact permission scope that tool operates under, and any known limitations specific to that connector rather than shared across all four. The four are Gmail, Notion, GitHub, and Linear.

If you're evaluating whether to connect a specific service, the individual connector documentation linked above is the right place to go. That's especially true if you want to know exactly what a specific tool does before you grant access. This page intentionally stays at the level of the shared pattern. It doesn't descend into per-tool detail that would need to be duplicated four times over. Detail duplicated that way would inevitably drift out of sync with the connector-specific documentation, as each connector's own tool set evolves independently over time. Keeping the two layers separate, a shared summary here and a detailed reference on each connector's own page, is what lets both stay accurate as the product changes.

When a connected service has an outage

Gmail, Notion, GitHub, and Linear are all services we don't operate ourselves. Each can have its own outage, rate limit, or authentication problem, entirely independent of anything on our side. When that happens, the failure is surfaced to you directly and clearly. You see that the connected service couldn't be reached or that a specific action failed, rather than a silent retry loop or, worse, a cached response presented as though it were current. That second option would directly contradict the "no standing copies" property described above, and we'd rather a request visibly fail than quietly answer from stale data without saying so. A clear failure is something you can act on; a confidently wrong answer is not.

A revoked or expired token behaves the same way: the connection shows as needing re-authorization, rather than continuing to attempt requests that will just keep failing. Reconnecting after that always goes through the same explicit opt-in flow as the original connection. There's no background, automatic renewal that reinstates access without you actively choosing to reconnect. That's consistent with the "opt-in, one at a time" property at the top of this page: access to a connected account is something you actively grant, every time, not something that silently persists or renews itself in the background once it's lapsed. It also means a token that's been revoked on the other service's own end, say you removed the app's access directly from your Google account settings, is respected here immediately rather than treated as still valid until something else notices. Whichever side the revocation happens on, the result is the same: access ends, and it stays ended until you deliberately grant it again.