> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# What to do first when you get 90 days to secure AI agent data
- URL: https://f4n6.co.uk/security-feed/what-to-do-first-when-you-get-90-days-to-secure-ai-agent-data/
- Published: 2026-09-24T08:37:01.000Z
- Updated: 2026-09-24T08:37:01.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

On 2026-09-24 Help Net Security published an interview with Kelly Herrell, CEO of Nol8, on where AI agents create data exposure inside organisations and how to spend a 90-day window on limiting it. The item reports no incident, no vulnerability and no exploitation: it is a practitioner argument that the exposure sits in the data path (what an agent can reach, what enters its context, which tools and models it can call, whether it can talk to other agents, and where results go), and that most organisations can describe their agent inventory but not the path. The affected population is any EMEA financial services firm with agents in production that can query ticketing systems, CRM platforms, shared drives, knowledge bases or chat history, because those stores hold credentials, customer account data and incident narratives that a human once had to assemble by hand. No VERIFIED REFERENCE DATA resolved for this item, so no CVSS score, severity rating or CISA KEV exploitation state is asserted here, and none should be inferred. The risk is architectural and present today; the control the source proposes is runtime policy enforcement at the points where data crosses a boundary, not a patch.

## 2\. Regulatory framing

| Article                                                | Trigger (the fact in this item)                                                                                                                                                              | Practical impact                                                                                                                                                                            |
| ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DORA Art. 28: ICT third-party risk, general principles | The source defines the data path as including "which tools and models it can call", so external model and tool providers sit inside a path that reaches ticketing, CRM and shared-drive data | Those providers belong in the ICT third-party register and fall under the general principles (due diligence, risk assessment, contractual arrangements), not only the agent platform vendor |

No incident-reporting article is engaged: the item describes an exposure model, not an event, and reports no incident to classify or notify. DORA Art. 17, 18 and 19 and NIS2 Art. 23 are therefore not triggered by anything in this source.

## 3\. Technical analysis & attack chain

There is no attack chain to reconstruct. The source contains no exploited component, no CVE, no malware, no command-and-control and no observed intrusion. What it contains is a description of how agent deployments change the reachability of data that already exists inside the enterprise, and that description is worth taking seriously on its own terms.

The argument runs from the data path rather than from the agent inventory. Herrell's stated first question on walking into an organisation with agents already in production is not for the list of agents but for the path: 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. The inventory describes what the organisation believes it deployed; the path describes what it exposed. The gap between the two is the exposure. The follow-up question is whether the organisation can produce every interaction that crossed the path or only a sample, and the source states the answer is almost always a sample.

The source frames the control question in three parts. Most organisations can answer whether a given agent is legitimate and what it is authorised to reach. Almost none can answer what that agent should see, carry forward, or disclose in a specific interaction. That third question is the one runtime policy has to answer, and it is per-interaction rather than per-agent.

The data stores named as the exposure points are not primarily databases. They are the systems enterprises accumulated over years without treating them as large interconnected datasets: ticketing systems first, then CRM platforms, collaboration tools, shared drives, knowledge bases and chat history. 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 previous incident happened. Multiplied across years of tickets, that is a dataset nobody classified as one.

The mechanism the source describes is the removal of friction. Assembling that picture previously required a human who knew where to look, could formulate a query, open another application and connect the pieces by hand. That effort acted as a control: it took time and knowledge, and it limited how often the correlation happened. An agent retrieves and correlates the same pieces almost instantly, so the control goes with the friction. The underlying data did not become sensitive when AI arrived; what changed is the speed, scale and ease with which it can be discovered, combined and moved.

The 90-day plan the source sets out is deliberately front-loaded on visibility. Week one is mapping the paths between agents, enterprise data sources, models, tools and other agents, measuring what sensitive data crosses those boundaries, and establishing where policy can be enforced at runtime. The items explicitly postponed are the large builds: a full identity redesign, rewriting every agent, classifying every piece of enterprise data before starting, building masked replicas per role, and placing guardrail libraries in every agent's code. The stated reason is that all of those scale with the number of agents and roles rather than with the risk. The sequence proposed is observe first, enforce on the highest-risk paths, then widen coverage.

Confidence caveat: this section rests on a single source, a vendor interview with the CEO of a company selling in this space. The architectural claims are plausible and consistent with how agent frameworks retrieve context, but no incident data, telemetry or independent corroboration accompanies them. Treat the exposure model as a hypothesis to test against your own agent estate, not as an observed compromise.

## 4\. Mitigation & containment

The source proposes no technical fix, so these steps translate its plan into actions against your own estate. They are process and architecture controls, not containment of an intrusion.

### P1, within 24 hours

- Produce the data path map for every agent in production, covering the five edges the source names: agent to data source, data source to agent context, agent to tool, agent to model, and agent to agent. An agent inventory is not a substitute and should not be accepted as one.
- Identify which of those edges touch ticketing systems, CRM platforms, collaboration tools, shared drives, knowledge bases or chat history, and mark them as the highest-risk paths for enforcement.
- Establish whether interaction records exist for every crossing of those edges or only a sample. Where coverage is sampled, record that as a known gap rather than assuming completeness.

### P2, within 72 hours

- Search ticketing and chat history for pasted production logs and other content carrying live credentials, and rotate anything found. The source names this as the most common surprise, and it is the one item on the list that is a credential exposure rather than an access-scope question.
- Restrict agent reach on the highest-risk paths to the minimum the use case requires, and enforce that restriction at runtime rather than in agent code, so it holds when agents are added or rewritten.
- Bring external model and tool providers named in the path into the ICT third-party register and confirm the contractual position with each (DORA Art. 28).

### P3, within 7 days

- Extend runtime enforcement from the highest-risk paths to the remainder, in the order the P1 map produced.
- Defer the items the source postpones (identity redesign, agent rewrites, enterprise-wide data classification, per-role masked replicas, guardrail libraries in every agent) until the path is visible and enforceable. Starting with them consumes the window without reducing exposure on the paths that matter.
- Where the business and security teams disagree on agent access, resolve it against the per-interaction question (what should this agent see, carry forward or disclose here) rather than against the agent's authorisation scope, which both sides usually already agree on.

## 5\. Indicators of compromise

No indicators of compromise available in the source material. The item reports no incident and contains no hashes, domains, IP addresses, file paths or command lines.

The source does describe agent behaviours that are observable in principle, so the following are recorded as behavioural indicators. None of these were observed in an incident; they are the paths the source says to instrument, and the telemetry locations are our mapping of those paths, not vendor-supplied detection content.

### Behavioural indicators

| behaviour                                                                                                                          | where to observe                                                 | confidence                                                                          |
| ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| A single agent interaction retrieves and correlates records across ticketing, CRM, shared drives, knowledge bases and chat history | Agent tool-call logs, SaaS platform API audit logs, egress DLP   | medium: behaviour named in source, telemetry location is our mapping                |
| Agent-to-agent communication                                                                                                       | API gateway or service mesh east-west logs, agent framework logs | medium: behaviour named in source, telemetry location is our mapping                |
| Agent calls to external models and tools                                                                                           | Egress proxy logs, model and tool provider API logs              | medium: behaviour named in source, telemetry location is our mapping                |
| Credentials and customer account data present in ticket bodies entering agent context                                              | DLP and secret scanning over ticketing and chat platforms        | high: source names pasted production logs with live credentials as a common finding |
| Interaction records available only as a sample rather than complete coverage                                                       | Per-agent audit log coverage reporting                           | medium: source states this is the usual answer, not a measured rate                 |

## 6\. Detection

Insufficient indicators to author detection rules.

The source names no file names, command-line flags, registry keys, scheduled tasks, mutexes or hard-coded values, and a rule built from the product and vendor names in the interview would match reporting about the exposure rather than the exposure itself.

## 7\. Sources

- Help Net Security, "What to do first when you get 90 days to secure AI agent data" (interview with Kelly Herrell, CEO, Nol8), https://www.helpnetsecurity.com/2026/09/24/kelly-herrell-nol8-ai-agent-data-security/, published 2026-09-24.

## 8\. Adverse Trace position

We assign no severity rating to this item. There is no CVE, no exploitation state and no incident, and the VERIFIED REFERENCE DATA resolved nothing for it, so any CVSS figure or KEV status attached to this advisory would be invented. The client impact is real but architectural: firms running agents against ticketing, CRM, shared drives, knowledge bases or chat history have a data path they probably cannot fully enumerate, and the per-interaction question (what should this agent see, carry forward or disclose here) is the one most estates cannot answer. The whole of §3 and §4 rests on a single vendor interview, so we treat the exposure model as a hypothesis and the 90-day sequence as one practitioner's ordering, not as validated guidance; verify both against your own agent telemetry before committing budget or changing access controls. We will track whether any EMEA financial services firm reports an incident that traces to agent-mediated data correlation, and we will reissue this note with a severity assessment if a concrete exploitation case, CVE or KEV entry emerges.

---

[Read the original source →](https://www.helpnetsecurity.com/2026/09/24/kelly-herrell-nol8-ai-agent-data-security/?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*