The moment a model is allowed to call tools, a new question appears that a plain chat window never has to answer: what, specifically, can it reach? The answer is a permission decision someone made, not a fact about how smart the model is.
Key takeaways
A general-purpose model has no inherent ability to touch a calendar, an accounting system, or a customer database. What it can reach is entirely a function of what credentials and tool definitions the surrounding system hands it — a service account with access to one shared inbox, an API key scoped to read-only access on one database table, a specific set of named functions and nothing else. Two deployments of the identical model can have wildly different reach, because reach was never a property of the model in the first place. See what an AI agent actually does for how that permission boundary sits inside the tool-calling loop.
Canada’s Cyber Centre names “privacy of data” directly in its list of generative AI risks: “users may unknowingly provide sensitive corporate data or personally identifiable information (PII) in their AI queries and prompts.” Once an AI system is connected to a live inbox, a shared drive, or a database, that risk stops being about what a person types into a chat box and starts being about what the connection itself exposes the model to automatically, without anyone deliberately typing anything. The same guidance separately names “loss of intellectual property” as its own risk category, for the same underlying reason — reach that wasn’t deliberately scoped can expose more than intended.
The NIST AI Risk Management Framework — cited by Canada’s privacy regulators via the OPC’s own generative-AI principles as the reference for evaluating validity and reliability, and a US framework worth labelling as such — opens its MAP function with exactly this discipline: “Context is established and understood.” Applied to reach specifically, that means deciding deliberately, before the connection is built, what the system needs to touch to do its job and nothing beyond that — rather than granting a broad credential because it was the convenient one already lying around, and working out afterward what the AI system actually needed.
Canada’s federal, provincial and territorial privacy commissioners, in their joint principles for generative AI, give a more direct test than “is it possible” for deciding whether a given piece of reach should be granted at all: “consider whether the use of a generative AI system is necessary and proportionate…the tool should be more than simply potentially useful. This consideration should be evidence-based and establish that the tool is both necessary and likely to be effective in achieving the specified purpose.” Applied to a connection specifically: the question isn’t whether giving an assistant access to a system could help, in some general sense — almost any access could help with something — it’s whether that particular reach is actually necessary for the task the assistant is built to do.
A connection that can only read is bounded in a specific way: its worst failure is producing a wrong summary or a wrong answer, which a person can catch before acting on it. A connection that can also write or send has a structurally worse worst case, because the mistake can already be a completed action by the time anyone sees it. Neither case is really about the model’s intelligence — it’s about how much was left reachable, and what happens if a wrong output lands on all of it. See why AI agents need guardrails for the specific limits that keep reach from quietly widening past what anyone intended.
Two deployments of the same assistant: one is connected only to a shared team calendar, with permission to read availability and propose times. The other is connected to the calendar and, separately, to the company’s accounting system, because someone reused an existing broad service account rather than issuing a narrower one. The first deployment’s worst realistic mistake is a scheduling conflict. The second’s worst realistic mistake now includes whatever the accounting connection allows — not because the assistant became more capable, but because nobody scoped what it should be able to reach before wiring it up. Where the reach is into employee-facing systems specifically — a monitoring or productivity tool wired to see how staff work — a sector-specific layer can apply: Ontario’s Employment Standards Act requires employers with 25 or more employees to maintain a written policy on electronic monitoring of employees. ESA, 2000, s.41.1.1 See Treadstone Law’s guide.
Widen the example slightly and the accounting connection also happens to carry customer personal information — names, invoice histories, payment details. At that point the reach decision stops being only a security question and becomes a privacy-law one as well: whoever approved the broader service account is now accountable, under the same accountability principle that applies to any transfer of personal information for processing, for a connection that was never actually assessed against the task it was meant to serve.
Related: for what determines whether that connection is read-only or read/write in the first place, see what an integration does, in plain terms; for the documented failure modes that show up once reach exists, see where AI agents still fail.
No. Reach is scoped by the specific tools, API keys and permissions actually granted, not by whether a system has network access in the abstract. A model with internet access but no defined tools still can’t act on anything — it can only produce text.
Not directly — but a credential that’s broader than the task requires can quietly widen reach beyond what anyone intended, without a separate, deliberate connection step ever happening. That’s a scoping failure, not the AI finding its own way in.
Whoever configures its credentials and tool list — an organizational and design decision, made (or not made carefully) by the people building the connection, not a property of the AI model itself.
A wide credential is sometimes the fastest way to get a prototype working, but the necessity and proportionality test above doesn’t carry an exception for “still testing.” The safer default is scoping reach to exactly what the test needs and widening it deliberately if the project moves forward, rather than starting broad and meaning to narrow it later.
Less, but not none. A read-only connection can’t change a record, but it can still expose sensitive information the moment it’s connected — the Cyber Centre’s “privacy of data” risk applies to what a system can see, not only to what it can change.
The permission boundary is a design decision made at connection time, not after.
