Connecting an assistant to an external tool extends your trust boundary to an operator you have no agreement with, at a seam authenticated more weakly than anything else you run. What the integration can actually see, and the line where the problem stops being technical.
Two estates, one seam
You have audited your systems. You know where the keys live, who holds them, and what happens when somebody leaves.
The operator on the other side has audited theirs, to a standard you have not read, against threats you have not discussed.
The assistant now joins the two. And your data crosses not at a negotiated boundary with obligations on both sides, but at whichever point somebody enabled an integration, on an afternoon, to solve a problem.
Your supplier list is shorter than the truth
The tool you connected may call other services to do its work.
A storage provider. A logging service. A model of its own, hosted somewhere. Each is processing material that originated with you, under terms agreed between two other parties.
Your contract list names one company. Your effective supplier list is longer, and nobody in the organisation maintains the difference — because maintaining it would require asking a question that the integration flow never prompts.
The trust is transitive. The paperwork is not.
Why this seam is the weak one
It is usually a single long-lived key.
Issued once, during setup, by whoever was doing the setup. Unscoped, because the setup screen offered one key rather than a permission model. Shared across every user of the integration, so the credential identifies your organisation and nothing finer.
And rotated never — not through carelessness, but because rotation means coordinating with a party who gains nothing from the exercise and has no obligation to schedule it.
Every other credential in your estate has an owner and a lifecycle. This one has neither, and it sits at the boundary.
What the integration can see
More than the arguments, which is the part people get wrong.
The surrounding conversation, wherever the integration is handed context to work with. The question, the preceding turns, whatever was retrieved to answer it.
Who is asking. An identifier at minimum, frequently a name and an address, because the call has to be attributable.
The pattern over time. Which is the one nobody considers. A tool called forty times a week learns the rhythm of a department, and rhythm is information even when each individual call is dull.
None of that is a flaw in the integration. It is what supplying context to a tool means.
What holds
Scope tokens per user, not per integration. So a call can be attributed to a person, and revoking one person does not mean revoking the tool.
Short-lived credentials exchanged at call time. A token valid for minutes bounds a leak in advance without anybody noticing anything.
Enumerate operations rather than granting categories. Read calendar events is a permission. Calendar access is a surrender.
Log every call with who triggered it. Not for blame — so the question what did this tool receive from us has an answer that does not depend on the other party's cooperation.
Review the connected list on a schedule. That list only ever grows. Nothing in any product anywhere prompts anybody to remove an integration, and so nobody does.
Where it stops being technical
None of this prevents the operator from misusing material you legitimately sent them.
Once data has properly crossed, under a valid token, for a permitted purpose, what happens next is governed by a contract, a jurisdiction and their internal discipline. A scoped token does not reach any of those.
That is worth saying because the technical controls feel like they address the whole problem, and they address one half of it. The other half is selection — who you connected to, and whether you would be comfortable explaining that choice afterwards.
Close
The integration was one click and no signature.
Everything downstream of it — the sub-processors, the retention, the jurisdiction — was agreed on your behalf by somebody you have never met.