Agentic AI threat hunting still needs tightly scoped access

At a glance

What this is: This is a Wazuh guide to wiring an agentic AI workflow into SOC threat hunting so an AI agent can query telemetry, correlate alerts, and draft investigations.

Why it matters: It matters because SOC automation introduces a non-human identity-like access layer that must be least-privileged, auditable, and constrained to avoid turning investigation tooling into an additional risk surface.

👉 Read Wazuh's full guide to agentic AI threat hunting in Wazuh

Context

Security operations teams are facing a correlation problem as much as a detection problem. When alert volume rises, manual triage slows down the link between telemetry, investigation, and response, especially when analysts must stitch together processes, network activity, file changes, and historical alerts across multiple systems. In agentic AI terms, the issue is not simply model output, but how a software entity is allowed to query and act on sensitive security data.

In this article, Wazuh frames agentic AI as a way to automate threat hunting while keeping data local and investigations traceable. The identity question sits underneath the workflow: the AI agent is effectively a privileged software actor, so access control, service account scope, and API boundaries matter as much as model selection. For teams already working on NHI governance, this is a familiar control pattern applied to a new class of agent.

The setup described here is a proof of concept, which is typical of where the market is today. Most organisations are still working out how to let AI participate in security operations without creating an ungoverned access path into logs, telemetry, and response workflows.

Key questions

Q: How should security teams govern AI use when users, APIs, and agents all generate different telemetry?

A: Start by separating the governance problem into distinct control domains. Human prompts, service API calls, and agentic workflows need different evidence, different owners, and different enforcement points. A single dashboard rarely gives enough context to govern all three, so teams should build policy around the path where each action begins, not only around the logs it leaves behind.

Q: Why do AI agents increase identity and access risk in SOC workflows?

A: Because they can chain multiple calls, reuse context, and reach across telemetry sources faster than a human review cycle. If permissions are too broad, the agent becomes a privileged automation path that can expose sensitive data or expand the blast radius of a mistake.

Q: What breaks when AI agent access is broader than the task it is trying to complete?

A: When agent access is broader than the task, the identity can touch systems, data, and tools that were never necessary for the work. That expands blast radius, makes audit trails harder to interpret, and turns a useful automation into an ungoverned privilege path that security teams may only see after damage is done.

Q: Who should be accountable for AI agent security incidents?

A: Accountability should sit with the team that owns the agent's business function and permission model, not with a single security tool owner. If the organisation cannot name who approved the agent's scope, who can revoke it, and who reviews runtime exceptions, the governance model is incomplete.

Technical breakdown

Offline model hosting reduces one risk while preserving others

Running the model locally through Ollama keeps log data on-premises and avoids sending telemetry to an external service. That addresses a common data handling concern, especially for environments where logs may contain credentials, incident details, or sensitive host data. But local hosting does not eliminate identity or governance risk. The model still needs credentials, endpoint access, and operational controls, and the security of the workflow now depends on the host, the API boundary, and how secrets are stored and rotated. Privacy improves, but trust shifts inward rather than disappearing.

Practical implication: pair local model hosting with secret hygiene, host hardening, and explicit audit logging for every tool call.

Threat narrative

Attacker objective: The attacker’s objective would be to abuse the agent’s privileged telemetry access path to reach sensitive investigation data or use it as a launch point for broader compromise.

1. Entry occurs when an AI agent is given API and index access to security telemetry so it can autonomously query investigations on behalf of analysts.
2. Escalation happens if that agent is granted broader permissions than the investigation requires, allowing it to traverse more logs, systems, or actions than intended.
3. Impact is the creation of a privileged automation path that can expose sensitive security data or distort response decisions if its access or outputs are not tightly governed.

NHI Mgmt Group analysis

Agentic AI in SOCs creates a new NHI governance problem, not just an automation gain. Once a model can query telemetry, correlate events, and assemble investigations, it functions like a software identity with runtime authority. That authority must be governed through the same discipline used for service accounts, API keys, and workload identities. The practitioner lesson is straightforward: if the agent can inspect security data, it has become part of your identity surface.

Least privilege is necessary but not sufficient when the privilege holder is autonomous. Traditional access design assumes a human user, a bounded session, and reviewable intent. An AI agent can chain API calls, preserve context across steps, and reframe its own query path mid-investigation. That means scope must be constrained not only by permission, but by allowed tool set, query shape, and data domain. The practical conclusion is to govern agent behaviour as well as agent entitlements.

Traceability is the named concept here: investigation outputs must be attributable to source telemetry, not model improvisation. Wazuh’s emphasis on deriving results from API-retrieved data reflects an important control pattern for AI in security operations. If analysts cannot reconstruct which alerts, indices, and queries produced the answer, the workflow becomes hard to defend in audits or incident reviews. Practitioner conclusion: retain provenance for every agent action and every evidence object it produces.

Agentic AI will accelerate SOC operations only where identity and audit controls are already mature. The broader market signal is that AI in security operations is moving from experimentation to practical deployment, but the governance burden shifts rather than disappears. Teams that already manage NHI sprawl, credential lifecycle, and audit evidence will be able to adopt these workflows more safely than teams treating them as simple productivity tools. The right posture is to build control-plane discipline before scaling autonomy.

Security teams should expect agentic workflows to inherit the same failure modes as other privileged automation. Over-scoped accounts, weak secret handling, and poor logging will matter more than the model brand or parameter count. In NHI terms, this is another case where runtime access, not vendor intent, determines risk. Practitioners should evaluate the agent as an identity-bearing system with enforceable boundaries, not as a harmless interface layer.

What this signals

Traceability will become the differentiator between acceptable agentic automation and ungoverned AI in SOC operations. If an investigation result cannot be mapped back to specific telemetry, tool calls, and account scope, the workflow will be hard to defend in audits or incident reviews. Teams should expect reviewability to matter as much as response speed, especially where security findings inform containment decisions.

As AI agents move deeper into operational workflows, their credentials, host hardening, and secret storage become part of the security programme rather than just implementation details. That means identity and secrets teams will need to work directly with SOC and platform engineers so the agent does not become a hidden privileged path. For readers, the signal is clear: agentic AI adoption should trigger identity control reviews, not just model evaluations.

For practitioners

• Define a dedicated identity for every AI agent Create separate service accounts for each agentic workflow, limit them to the exact APIs and indices required, and avoid sharing credentials across use cases. This keeps investigation authority traceable and prevents cross-workflow privilege bleed.
• Constrain tool use to read-only investigation paths Allow only the minimum actions needed for hunting and correlation, then block write operations, response actions, and administrative functions unless a separate control is approved. Keep the read path narrow enough that the agent cannot pivot into broader system access.
• Log every agent action with evidence provenance Record the prompt, tool call, returned data set, and final output for each investigation so analysts can reconstruct how the conclusion was reached. This is essential when the agent is summarising security telemetry from multiple sources.
• Protect local model credentials and runtime secrets Store model and Wazuh credentials outside the application code, rotate them on a defined schedule, and restrict host access to the process running the agent. Local hosting removes external exposure, but it does not remove secrets risk.

Key takeaways

• Agentic AI can reduce SOC triage friction, but it also introduces a software identity that must be governed like any other privileged workload.
• The critical control is not model quality alone, but whether the agent’s permissions, evidence trail, and tool boundaries are narrow enough to remain auditable.
• Teams that already manage NHI lifecycle discipline will be better placed to adopt agentic security workflows without creating a new blind spot.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Read-only access: Read-only access allows a machine or agent to inspect data or systems without changing them. In AI-assisted development, it is a practical least-privilege default because it lets teams validate behaviour and gather context while reducing the chance of unintended modification or privilege escalation.
• Evidence Provenance: The ability to trace a security conclusion back to the exact data, query, and control inputs that produced it. In AI-assisted operations, provenance is what makes an answer defensible, because speed without traceability creates reporting that is convenient but weak in audit, incident review, or privacy enforcement.

What's in the full article

Wazuh's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Wazuh policy, role, and user configuration for the agentic AI workflow
• Exact environment variables and installation commands used to stand up Ollama and Qwen3 locally
• Example investigation prompts for data exfiltration, remote code execution, and alert correlation
• Screenshots and interface steps for reviewing investigation outputs in the Wazuh dashboard

👉 The full Wazuh post shows the exact setup, prompts, and investigation workflow in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to control access for service accounts, APIs, and emerging agentic workflows.