Agentic AI in cybersecurity helps triage, but data quality sets limits

At a glance

What this is: This is Panther’s analysis of what agentic AI can and cannot do in cybersecurity operations, with the main finding that it helps most in alert triage and detection engineering but fails when data quality and context are weak.

Why it matters: It matters to IAM practitioners because the article explicitly ties agentic AI to identity telemetry, access context and analyst trust, which are now part of SOC governance and NHI-aware security programmes.

By the numbers:

• Over 40% of agentic AI projects are expected to be canceled by the end of 2027 due to underestimated complexity and cost.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope.

👉 Read Panther’s analysis of what agentic AI does, and doesn’t do, in cybersecurity

Context

Agentic AI in cybersecurity refers to systems that can perceive, plan, act and learn across a workflow, rather than waiting for a human prompt at each step. The governance gap is that many teams are still evaluating these systems as if they were advanced chat interfaces, not systems that can change investigation outcomes, access patterns and escalation paths.

That distinction matters for identity and security programmes because the agent often depends on identity telemetry, threat context and access to operational tools. When those inputs are incomplete or poorly normalized, the system does not become more intelligent, it becomes more confident about bad conclusions. For SOC leaders, IAM teams and NHI owners, the question is whether the surrounding controls can support bounded autonomy without eroding trust.

The article’s starting position is typical of the current market: useful in narrow operational lanes, but overstated when described as a replacement for analyst judgment.

Key questions

Q: What breaks when agentic AI is used without complete identity and telemetry data?

A: The system does not become more autonomous in a useful way. It becomes more confident about incomplete context, which leads to weak triage, poor correlation and unreliable closures. In practice, missing identity telemetry, inconsistent schemas and thin log retention cause the agent to scale error, not insight.

Q: Why do AI SOC platforms create new governance questions for security teams?

A: Because they are not just analytics tools. They query identity, cloud, endpoint, and email systems, then may recommend or execute actions that affect access or containment. That makes them delegated operational agents, so teams need clear ownership, scoped permissions, immutable logging, and a defined approval boundary for any action that changes state.

Q: How do security teams know whether AI access is actually working safely?

A: Look for three signals: complete discovery of the AI estate, clear mapping of source data to each system, and logs that prove what was accessed and why. If any of those are missing, the control environment is incomplete. Safe AI access is evidenced, not assumed.

Q: Who should be accountable when an AI agent causes a security incident?

A: Accountability should sit with the human owner, platform team, or business function that granted and operated the agent. The identity may act independently, but governance cannot detach responsibility from the delegation chain. Programs should define ownership, escalation, and remediation paths before deployment so responsibility is clear when the agent's behaviour changes.

Technical breakdown

Perceive-plan-act-learn loops in the SOC

A genuinely agentic security system is not just summarising alerts. It ingests telemetry, builds context, selects the next investigative step, executes tool calls, and then adjusts based on analyst feedback. In a SOC, that means the agent may pull identity logs, correlate endpoint and cloud events, and decide which enrichment queries to run without being prompted line by line. The control challenge is that each step depends on trustworthy context and governed tool access. If the agent cannot distinguish routine activity from suspicious behaviour because the data layer is thin, it will still act, but its decisions will be weak. Practical implication: treat the agent as an orchestrated decision system, not a chatbot.

Practical implication: define the agent’s allowed actions, data sources and escalation points before it touches production telemetry.

Why identity telemetry is central to agentic AI security

Security agents often rely on identity systems because authentication events, privilege changes and account behaviour provide the clearest signal of compromise. That makes IAM data a core input, not a side source. If the agent can see who authenticated, what role was assumed, which service account was used, and whether access was anomalous, it can make better decisions about triage and escalation. But if identity logs are siloed, incomplete or unnormalized, the model will overfit on partial truth. In practice, agentic AI inherits the quality of the identity and access data it consumes. Practical implication: centralise identity telemetry before expecting reliable autonomous investigation.

Practical implication: normalise authentication, privilege and session data so agentic workflows can reason across identity events consistently.

Explainability in detection engineering and alert triage

Explainability is the control that determines whether agentic AI becomes operationally useful or simply another opaque layer. Analysts do not need a confidence score, they need the chain of evidence, the tools queried, the logic used, and the basis for a closure or escalation. That matters even more when the system is generating detection rules or closing alerts automatically, because reviewers must be able to audit both the output and the path taken to get there. In security operations, explainability is not a nice-to-have feature, it is the trust mechanism that keeps humans in command. Practical implication: require evidence trails for every automated triage or detection decision.

Practical implication: make evidence trails mandatory for any AI-assisted closure, enrichment decision or detection rule generation.

Threat narrative

Attacker objective: The objective is not always direct compromise, but operational deception: to cause the SOC to miss, mis-rank or mis-handle real threats through bad context and overconfident automation.

1. Entry begins when an attacker or noisy operation reaches the SOC through incomplete telemetry, prompting the agent to work from partial context rather than full environmental visibility.
2. Escalation occurs when the system relies on flawed or missing identity and asset data to rank alerts, enrich findings or generate detections, amplifying bad inputs into operational decisions.
3. Impact appears when analysts defer too much to opaque automation, allowing false closures, missed escalation or weak detections to persist in production workflows.

NHI Mgmt Group analysis

Agentic AI is a SOC efficiency layer, not a substitute for security judgement. The article is strongest when it describes automation as bounded assistance for triage and detection engineering. That aligns with what we see across identity-heavy security operations: the more context-sensitive the decision, the less comfortable practitioners should be with full delegation. The practical conclusion is to use agentic systems to remove repetitive work, not to delegate accountability.

Identity data quality is now a prerequisite for AI security operations. Agentic workflows depend on authentication events, privilege context and asset relationships to make defensible decisions. When those signals are fragmented, the system inherits the same blind spots as the SIEM and then scales them faster. The named concept here is identity context debt: the accumulated cost of missing, stale or siloed identity data that weakens every downstream automated decision. Practitioners should treat this as a governance issue, not a tooling issue.

Explainability is the operational control that decides whether AI gains analyst trust. Without a visible evidence chain, analysts will reopen closures, duplicate investigation work and bypass the system. That makes transparency a SOC control, not just a model feature. For teams using agentic AI alongside NHI and identity telemetry, explainability should be reviewed as part of evidence handling and auditability.

Agentic AI changes the boundary between observation and action. Once a system can query, enrich and recommend independently, it starts to resemble a governed participant in the security workflow. That raises questions about access scope, workflow approval and review responsibility. The practical implication is that IAM, SOC and GRC teams need shared ownership for how these systems are authorised and audited.

The market is converging on intelligence over interface, but governance will decide adoption. The article reflects a broader shift away from point AI features toward systems that claim to reason across security data. That will not be sustained by marketing alone. Practitioners will adopt what they can verify, not what they can only observe superficially.

What this signals

Agentic AI will move fastest in teams that already have centralized identity telemetry, normalised schemas and strong analyst workflows. The programme signal is clear: if identity and access data remain fragmented, the AI layer will magnify operational inconsistency rather than reduce toil.

Identity context debt: missing or stale authentication, privilege and session data will become the main reason agentic SOC projects underperform. Teams should assume the agent will inherit every visibility gap they have not already resolved, which makes data governance part of AI readiness.

For IAM, PAM and NHI owners, the practical implication is that AI workflows will increasingly depend on governed access to logs, connectors and response tooling. That pushes privilege management, auditability and approval boundaries into the same conversation as model selection and SOC automation.

For practitioners

• Define bounded autonomy for SOC workflows Map which triage steps, enrichment queries and detection suggestions an agent may execute without review, and require explicit approval before any closure or containment action. Align those boundaries with your incident response and access control model, not with vendor defaults.
• Centralise identity and telemetry inputs Consolidate authentication, privilege, endpoint and cloud events into a normalised schema before enabling agentic investigation. If the agent cannot see complete identity context, it will amplify missing data instead of compensating for it. Use the same source-of-truth approach for service accounts and human accounts.
• Require evidence trails for all automated decisions Make every AI-assisted triage outcome, query path and detection rule generation step reviewable by analysts. The system should expose the data reviewed, the logic used and the tools called so that closures can be audited and reopened when necessary.
• Review access to AI workflows as a governed privilege Treat access to agentic investigation tools, data connectors and response actions as privileged access. Apply least privilege, change control and periodic review to the agent’s permissions, especially where the workflow touches identity systems or sensitive logs.

Key takeaways

• Agentic AI can compress repetitive SOC work, but only when the data foundation and workflow boundaries are already strong.
• Identity telemetry is a core input to autonomous investigation, which makes data quality and access governance part of AI security readiness.
• Explainability is the control that turns AI output into something analysts can trust, review and defend.

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.
• Identity context debt: The accumulated operational cost of failing to expose legitimacy context to detection and investigation systems. As this debt grows, analysts spend more time re-checking routine work, AI models inherit the same blind spots, and the programme becomes harder to trust.
• Local Explainability: Local explainability describes why a model produced one specific result for one specific case. It is most useful when a customer, investigator, or reviewer needs a decision reason that is tied to the exact inputs in play, such as a credit denial or a fraud alert.
• Bounded Autonomy: Bounded autonomy means a system can act independently within defined limits, but cannot exceed those limits without human or policy control. In agentic governance, the boundary must be explicit, testable, and logged, because the real compliance question is where autonomous action stops.

What's in the full article

Panther’s full post covers the operational detail this post intentionally leaves for the source:

• How its AI triage workflow handles alert enrichment, correlation and analyst approval in practice
• Examples of detection rule generation in Python, SQL and YAML with review steps
• The data-layer requirements the vendor says are needed before AI can work reliably in the SOC
• The explainability and evidence-trail features used to support analyst trust

👉 Panther’s full post covers the SOC workflow examples, data-layer requirements and evaluation criteria in more detail

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity governance to the broader security operations stack.