An AI agent can potentially reach several different kinds of resource: the open internet, internal tools and connectors, and a company's knowledge bases. It can also reach every record of what it did and said. None of that should be inherited from a platform's defaults.
Controlling what an AI agent can access means deciding, on purpose, what each agent is allowed to touch. Different kinds of access need different controls. Blocking a network call is a different problem from scoping a tool grant, and neither is the same as deciding how long a conversation gets kept. This post calls the sum of an agent's access its reach, Commt's term for the same idea. It works through the four boundaries that define it: network, tools, knowledge, and retention.
What does an AI agent have access to?
An AI agent's access breaks down into four boundaries: the network it can call out to and the tools and connectors it can invoke. It also covers the knowledge bases it can retrieve from, and the record kept of what it did afterward. Each is controlled by a different mechanism and fails differently when it isn't.
None of this is one security switch. Turning off web browsing does nothing to scope which Slack channel an agent can post to. Binding an agent to the right knowledge base says nothing about how long its conversations sit in storage. A platform offering a single on/off for "agent access" isn't offering control; each boundary has to be set on its own terms.
1. Network access: should an AI agent have internet access?
An agent should have internet access only when its job requires reaching the open web, and that's a decision made per agent.
Two ways to control browsing: architecture and filters
Whether an agent has internet access is decided by its toolset, not by a policy layered on top of it. If an agent's toolset contains no web-browsing or web-search tool, it cannot fetch an arbitrary URL. That holds regardless of what the user asks it to do, or what a prompt injection talks it into. Prompt injection is text hidden inside a retrieved document or web page that tries to redirect the agent's instructions.
There is no browsing capability to call, which makes this the strongest version of the boundary.
Correct once, at design time, rather than correct every time a request passes through a filter.
Most systems don't build it that way. The common pattern is to give the agent a browsing tool and then constrain what it can reach. That means egress allowlisting at the network layer, a firewall rule restricting outbound traffic to specific domains, or a forward proxy that inspects and blocks requests before they leave.
These work, and they're the right choice when an agent genuinely needs to browse. But they're a filter sitting in front of a capability that still exists, and every filter has to be right on every request. Miss one domain from the allowlist, misconfigure one proxy rule, and the gap is there until someone finds it.
Connectors still reach the network, even with browsing off
Here is the part most writing on this gets wrong. An agent with zero browsing or search capability can still make outbound network calls, through its connectors. A Slack integration posting a message is a network call. A Jira ticket creation is a network call. A webhook firing into a CRM is a network call. Each one goes out over HTTPS to a fixed, known endpoint, authenticated with a token scoped to that one service.
Describing an agent's network access as simply "on" or "off" misses what's actually happening: the agent stays connected to the network even when browsing is off. What's been engineered is scope, a fixed, enumerable set of destinations it can reach, versus the open set the word "internet" implies.
A security review that asks "can this agent reach the internet" and accepts "no" without checking what its connectors can do has not actually established the boundary.
Web browsing and search default on for agents on Commt. A customer can switch it off for a given agent when creating it. That's a setting decided at configuration time, not an architectural default across the platform, and it holds only if the customer sets it and leaves it in place.
2. Tools and connectors: which tools should an agent be allowed to call?
Which tools an agent can call should run on an explicit allowlist rather than a denylist, because a denylist has to anticipate every tool it hasn't seen yet. A denylist says "block these specific connectors and actions," so the default for everything else, including whatever gets added next month, is allow.
An allowlist says "these tools, and only these," which fails safe: a new integration sits unusable until someone deliberately grants it to a specific agent. The cost is real. Allowlisting adds friction to trying a new tool, and every new capability needs a deliberate decision before anyone can use it.
That friction is the point, not a bug to route around.
Tool-call scoping has to check more than whether a tool is switched on. At minimum it needs three things:
- The tool itself. Is Slack even in scope for this agent?
- The resource inside that tool. Which channel, which Jira project, which Drive folder. A grant to "Slack" with no resource scope is a blank check across the whole workspace.
- The action. Read or write. A connector that's read-only for one agent might be read-write for another with a different job.
And it has to check at call time, not only when the agent was configured. A token scoped broadly at setup and never re-checked per call is a static grant wearing the shape of a per-call one.
Most of these tools reach an agent through MCP, the Model Context Protocol. MCP is an open standard that lets an agent discover and call tools, data sources and services, with no custom integration needed for every model-and-tool combination. Official MCP servers and the ones you add yourself are both available among Commt's AI agent integrations.
Custom servers go through custom MCP verification: Commt checks a submitted server before it's usable, and warns the customer if the check identifies security vulnerabilities. Verification reduces risk; it isn't a guarantee a server is secure, so a custom server still needs the same tool, resource and action scoping as anything else you grant.
3. Knowledge and RAG access: how do you stop an agent reading the wrong data?
You stop an agent from reading the wrong data by scoping retrieval to only the knowledge bases explicitly bound to that agent. That's never a shared pool everyone on the account can query by default. The scope has to be enforced at the index and the query, rather than assumed from something upstream in the application.
Retrieval-augmented generation, RAG, is the technique behind this. An agent's query searches a knowledge base for the most relevant passages, and adds them to what the model sees before it answers. RAG is optional. Some agents need a company's own documents and RAG supplies them; other agents run with no knowledge base at all. Access to a knowledge base is granted explicitly either way, never assumed, and RAG itself isn't a security boundary, the boundary is which knowledge bases an agent is bound to.
The sentence "the agent only knows what we gave it" is easy to say and hard to keep true. It holds cleanly with one agent and one knowledge base, where the retrieval query is a filter on a single index and there's nothing else to reach. It gets harder the moment two conditions show up, and almost every real deployment eventually hits both. That's more than one knowledge base, and more than one project or team sharing the same retrieval infrastructure.
With multiple knowledge bases, you need an explicit grant per agent, per base: is this agent bound to base A, base B, or both, and who decided that.
With multiple projects sharing a vector store, the isolation has to be enforced at the index and the query. A vector store is a database that indexes document chunks by meaning rather than exact keywords, built by an embedding pipeline that converts documents into numeric representations.
A bug in a filter clause here is a silent cross-tenant read. It doesn't throw an error. It returns a plausible-looking answer built from someone else's documents.
That's exactly the kind of failure that goes unnoticed until someone happens to check the sources an answer cited.
4. Data retention: what gets kept, and for how long?
What gets kept should be the result of a deliberate retention policy, not a byproduct of logging everything because nobody decided otherwise. This boundary covers conversation content, tool call arguments and results, and retrieved chunks: what's persisted, and for how long. The default of keeping everything, forever, maximizes what you can debug and evaluate later. It also maximizes what a breach exposes. A stolen credential or a compromised export endpoint against a full-retention system hands over months of conversation history, connector payloads and whatever knowledge base content got retrieved into an answer.
The other default stores no message content unless a customer has explicitly set a retention window for it, keeping only what billing and rate limits actually need. That's the shape Commt uses: no message content stored by default, and retention set by the customer. Deletion means the record is actually removed or irreversibly anonymised, rather than flagged as hidden.
The retention tradeoff, stated plainly
Debugging why an agent did the wrong thing, and evaluating whether its output quality is drifting, both depend on having the conversations that show you. A minimal-retention default is a real security improvement and a real operational cost at the same time.
The honest way to hold that tradeoff is to pair a low default with an opt-in debug or evaluation mode a customer can turn on for the traffic they actually want visibility into. That's more honest than pretending the cost isn't there.
And if "delete" is a promise you're making, it needs to mean something specific: removed from primary storage, from search indexes, from the vector store. That's different from a status flag that a support query can quietly ignore.
How the four boundaries work together
They don't substitute for each other, so each has to be checked on its own terms rather than assumed from the others.
- A network boundary that blocks browsing says nothing about what a connector can do once it's granted.
- A tool allowlist says nothing about which knowledge base an agent can search.
- Binding an agent to the right knowledge base says nothing about how long its conversations sit in storage afterward.
Each boundary runs on a different mechanism and adds its own exposure. An agent's actual reach is set by the loosest of the four, not by whichever one happened to get the security review's attention. A gap in any single one is a gap in the whole thing.
For a broader look at what these four boundaries add up to together, see what makes an AI agent private.