By AI agents operating across enterprise data stores do not respect organizational boundaries by default. A go-to-market agent can reach employee records, compensation data, or any other context store it can resolve, unless the platform enforces hard isolation. Permissioning at the application layer is not enough when agents fetch, search, and write through API-level connectors that bypass traditional access controls.
In this interview on TFiR, Jean Lafleur, Co-founder and Chief Operating Officer at Airbyte, walks through the workspace isolation model and agent connector permissioning controls Airbyte is releasing now, and what the team is evaluating next for pre-access context store checks.
Guest: Jean Lafleur, Co-founder and Chief Operating Officer at Airbyte
Show: The Agentic Enterprise
LinkedIn: Jean Lafleur
Watch the discussion on YouTube
Here is what every platform engineer and AI infrastructure team needs to know.
Technical Deep Dive
Q: How do you stop AI agents from accessing data stores they were never authorized to reach?
Jean Lafleur, Co-founder and Chief Operating Officer at Airbyte, explains that the first control is workspace isolation. Each workspace contains its own context stores and its own access list defining which employees can reach it, so sensitive data like employee records is structurally separated from context stores used by go-to-market teams. This boundary is enforced at the workspace level, not at the application layer, so agents operating in one workspace cannot resolve data from another.
“You can ensure that your employee data is never mixed with other context stores used by the go-to-market teams.”
Jean Lafleur, Co-founder and Chief Operating Officer, Airbyte
Q: What is the difference between context store-level and connector-level permissioning for AI agents?
Lafleur distinguishes two layers. Workspace isolation operates at the context store level, controlling which users and agents can access a given store. Agent connectors, which handle fetch, search, and write operations by calling external APIs, are permissioned at the connector layer itself. These are independent controls: a user might have workspace access but still be restricted at the connector level when the agent tries to fetch, search, or write through a specific integration.
“We have the Context Store, but we also have what we call agent connectors that can fetch, search, and write data. When they do that, they simply call the API, allowing us to implement permissions at that level.”
Jean Lafleur, Co-founder and Chief Operating Officer, Airbyte
Q: What AI agent access controls is Airbyte planning beyond what it ships today?
The control Airbyte is evaluating next is a pre-access permission check that runs before an agent reaches the context store at all. The current release focuses on workspace isolation as the foundational boundary. The pre-access check would add an earlier gate in the resolution path, validating permissions before the agent query touches the context store, reducing the attack surface further.
“Something we are considering is whether we could check permissions before granting access to the Context Store.”
Jean Lafleur, Co-founder and Chief Operating Officer, Airbyte
Resources & Documentation
- Airbyte, open-source data movement platform with context store and agent connector capabilities for enterprise AI workflows
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: I also want to talk a bit about the security part as well, which is what kind of controls are you providing so agents don’t overstep their bounds when it comes to accessing data? The irony is that agents will hallucinate no matter how many guardrails you put, they will do whatever. We have seen so many stories, but given that, what are you building? What kind of guardrails are you putting in place?
Jean Lafleur: The first guide rail is workspaces where you can have several contact stores within your company and so that you can make sure, for instance, your employee data is never part of the mix of other contact stores used by the go to market teams, for instance, that’s the first thing. So each workspace gives their own access to which employee. So that’s one side of it. The second is at Ambuy we have both the Context Store, but we also have what we call agent connectors that can fetch, search and write. And when they do that, they just go to the API and do the calls. And we can implement permissioning at that level, but it won’t be at the Context Store level. It will be when you fetch, search and write. And we can. Something we considering, for instance is when if we could do that, it’s we could check the permissioning before you have access to Context Store. But right now what we’re releasing today is really the workspace.
