Gurucul announced the general availability of Gurucul AI Risk and Response on 24 September 2026. The company describes the product as a way for SOC and insider-risk teams to find shadow AI, risky agents, excessive access and sensitive-data exposure by joining AI activity with identity, endpoint, cloud and security telemetry.
This is a material product story because AI activity is moving from isolated prompt logs into the same evidence stack used for security response. Gurucul says runtime prevention is still in preview, so buyers should separate what is generally available now from controls that are not yet part of the core release.
What Gurucul launched
The general-availability release covers detection, investigation and analyst-directed response. The announcement says the product normalizes AI activity from platforms such as Claude, Gemini, ChatGPT, Azure AI Foundry and Microsoft 365 Copilot, then combines that with proxy, EDR, identity, operating-system and cloud telemetry.
The result is intended to answer security questions that are hard to answer from a standalone AI gateway: who or what initiated an AI action, which identity and privileges were involved, what data or systems were reachable, how behavior changed over time and whether the activity differs from peers or history.
Gurucul also says the product can build an inventory of agents, models, tools and hosts, connect activity to owners and permissions, prioritize detections mapped to MITRE ATLAS and the OWASP Top 10 for LLM Applications, and route remediation through existing workflows. Those are vendor claims and should be validated in each environment.
Why the evidence layer matters
Security teams already investigate users, machines and service accounts as persistent entities. AI agents now need the same treatment. A risky prompt is one signal. A risky agent is a chain of identity, task, tool, data, network path and downstream effect.
That matters for compliance as well as security. When an auditor, customer or regulator asks what an agent could access and what actually happened, an export of prompts may be incomplete. Teams need evidence that joins the prompt or agent event to the identity used, the data touched, the policy decision, the response action and the final state.
Maetra's AI audit evidence guide makes the same distinction. A control record should show who or what acted, under which policy, against which resource, with which result. AI activity has to enter that record instead of living in a separate AI experiment log.
What buyers should test
The launch is relevant, but it should not be treated as proof of automatic protection. Buyers should test whether the product can see all approved and unapproved AI tools in their estate, whether it resolves human and non-human identities correctly, whether its risk score is explainable and whether playbooks keep analysts responsible for consequential containment actions.
They should also test the boundary between generally available response and preview prevention. If blocking at the point of interaction is required, the organization needs to confirm which AI destinations, browsers, file uploads, prompts and policy exceptions are actually covered today.
What remains uncertain
The public sources do not independently verify detection accuracy, false-positive rates, deployment time, preview-prevention behavior or outcomes for customer environments. PR Newswire carries the company announcement, and the product page confirms the availability framing, but the operational claims remain Gurucul's. The safe reading is that the market is moving toward AI activity as security evidence, not that one product has solved AI risk.
Maetra analysis
Gurucul's release points to the right control shape. AI risk is not confined to a chat window. It crosses identities, apps, agents, models, tools, files and response systems. Security teams need an inventory of those actors and evidence that connects attempted behavior to the controls that allowed, flagged or contained it.
For agent governance, the next step is not only more alerts. It is action reconstruction. When an agent touches a file, calls a tool, reaches a customer record or triggers a response playbook, the organization should be able to prove the task context, authority, policy, reviewer path and effect. Without that, the team may know that AI activity occurred, but not whether it was governed.