What to do first when you get 90 days to secure AI agent data
Nol8's CEO says teams should map AI agent data paths and enforce runtime limits within 90 days.
In a Help Net Security interview, Nol8 CEO Kelly Herrell argues the first check for production AI agents is the data path: reachable sources, context inputs, tools, inter-agent communication, and where results go. He highlights ticketing systems, CRMs, shared drives, and chat history as overlooked stores that agents can correlate instantly, including tickets that may contain live credentials. His 90-day advice is to map flows and enforce policy on the highest-risk paths first, postponing full classification and per-agent rewrites. He recommends a deterministic in-path control, called an AI Data Plane, that inspects payloads rather than relying on labels.
- Inventory of agents is not the same as exposed data paths.
- Ticketing systems can hold credentials, customer data, and incident detail.
- Week one should map flows and measure sensitive data movement.
- Enforce redaction per agent and role instead of blocking whole systems.
Full article1,106 words · extracted from helpnetsecurity.com · click to collapse
In this interview with Help Net Security, Kelly Herrell, CEO at Nol8, explains where AI agents create exposure inside organizations. The first thing to examine is the data path: what an agent can reach, what enters its context, and where results go.
Ticketing systems, CRM platforms and shared drives hold years of sensitive context that agents can pull together in seconds. The conversation covers a 90-day plan for data access limits, the tension between business and security teams, and the case for enforcing policy in the data path.
When you walk into an organization that already has agents in production, what’s the first thing you ask to see? What does the answer usually tell you about their exposure?
I don’t ask for the list of agents. I ask for the data path.
Show me what the agent can reach, what data can enter its context, which tools and models it can call, whether it can communicate with other agents, and where the resulting data can go.
An inventory of agents tells me what the organization believes it deployed. The data path tells me what it exposed. The gap between the two is the exposure. The follow-up is whether they can show me every interaction that crossed it — or only a sample. The answer is almost always a sample.
Most organizations can answer the first two: is this a legitimate agent, and what is it authorized to reach. Almost none can answer the third: what should this agent see, carry forward, or disclose in this specific interaction.
Which data store has surprised you most as an agent exposure point?
The surprising ones aren’t necessarily databases. They’re the systems enterprises have accumulated for years without thinking of them as large, interconnected data stores.
The one that surprises people most is the ticketing system. A single ticket can hold a pasted production log with a live credential still in it, a customer’s account details, and a step-by-step narrative of how the last incident happened. Multiply that by years of tickets, and nobody ever thought of it as a dataset. CRM platforms, collaboration tools, shared drives, knowledge bases and chat history hold the same kind of sensitive institutional context.
Historically, pulling that together required a human to know where to look, formulate a query, open another application and connect the pieces by hand. That friction was doing the security work — it took time and knowledge to assemble the picture, and the effort quietly acted as a control. An agent retrieves and correlates the same pieces almost instantly. It removes the friction, and the control goes with it.
The underlying data didn’t suddenly become sensitive because AI arrived. AI changed the speed, scale and ease with which that data can be discovered, combined and moved.
A CISO gives you 90 days and a modest budget to put data access limits around agents. What do you do in week one, and what do you deliberately postpone?
Week one is about visibility, not trying to redesign the entire environment.
Map the paths between agents, enterprise data sources, models, tools and other agents. Measure what sensitive data is crossing those boundaries and establish where policy can be enforced at runtime.
I’d postpone the big-build work: a massive identity redesign, rewriting every agent, perfectly classifying every piece of enterprise data first, building masked replicas per role, or putting guardrail libraries in every agent’s code. All of it scales with the number of agents and roles, not with the risk.
The objective is to establish control quickly at the points where data moves. Observe first, enforce on the highest-risk paths, then widen coverage. Everything more sophisticated depends on being able to see and enforce at those points first.
You don’t need to solve every AI governance problem in 90 days. You need to establish control over the data crossing the boundary.
Where do business and security teams tend to disagree about agent access, and how should organizations resolve that tension?
Business teams want agents to have more context because context makes them more useful. Security teams naturally want to restrict access because broader access creates greater exposure.
Both positions make sense. The mistake is treating the choice as binary: either give the agent access to the system or don’t.
An agent may legitimately need access to Salesforce, Jira or a database without needing every piece of data those systems can return. That is the difference between authorization and data governance.
The better model is to enforce policy on the data itself, inside the interaction: sensitive fields are redacted or blocked in flight, per agent and per role, while the rest of the response goes through. The agent keeps the access the business wants; the fields it shouldn’t see never reach it. The usual alternative — maintaining a masked copy of the data for every role — grows with every role and agent you add. This doesn’t.
The business gets its agent in production, the security team gets a control it can verify, and there’s no shadow copy of the data to maintain. That is the third option, besides “allow everything” and “block the agent.”
What’s one control every security team should put in place before deploying its next agent, and what did you learn the hard way that convinced you?
Before deploying another agent, organizations should establish a deterministic policy enforcement point for the data entering and leaving the agentic environment. In practice, that enforcement point has to meet four conditions. It sits in the data path, so traffic cannot route around it. It reads every payload. It decides by what the data contains, not by a label or tag. And it is deterministic, so the same input produces the same decision every time, which is what lets a security team sign off on a mechanism. That is the layer we call the AI Data Plane.
Do not assume that because an agent is authenticated and authorized to access a system, every piece of data returned by that system is appropriate for the agent to consume or disclose.
Authentication answers who the agent is. Authorization determines where it can go. Data governance determines what information should cross the boundary.
That distinction matters because agents retrieve, combine and move information far faster than the human workflows our controls were built for. What convinced me was watching the alternative fail: a control that lives inside each agent’s code depends on every developer remembering to call it, and it fails the first time one team forgets. Put the enforcement in the data path instead, where forgetting isn’t an option.
Download: The Agentic Software Development Guide