SecurityHQ AI Agent Research Finds Policies Outpace Incident Accountability

SecurityHQ published research showing that 76% of surveyed cybersecurity leaders have formal AI accountability policies, while only 17% could reconstruct agent activity within minutes. The SecurityHQ AI agent research, developed with Datadog, exposes a practical tension: assigning responsibility does not necessarily make an automated decision explainable.

Released October 15, 2026, the findings arrive as enterprise agents gain permission to perform work across business systems. AI agents are software systems that use models and connected tools to pursue tasks. Their authority creates questions that written policies alone cannot answer.

Microsoft’s expansion of Security Copilot provides a concrete reference for this shift toward delegated security work. The pressure now falls on security leaders, application owners, and vendors to connect automated actions with evidence and accountable human authority.

SecurityHQ AI Agent Research Separates Policy From Readiness

The study surveyed 204 cybersecurity leaders at midsize and large organizations. According to the research announcement, 45% had experienced an incident involving AI agents or automation where accountability was unclear.

That wording deserves attention. The incident category includes automation, so the result does not establish that 45% experienced an autonomous AI agent breach. Unclear accountability also describes an organizational problem, rather than a particular technical failure or level of damage.

The finding concerns whether organizations can explain delegated actions when responsibility becomes contested. A policy can identify an owner without showing which instruction, permission, or system interaction produced an outcome.

SecurityHQ’s public accountability findings also distinguish historical visibility from immediate investigative readiness. Only 49% said they could fully reconstruct an agent’s actions over the previous 30 days.

That distinction changes how buyers should read the results. Retaining records and answering urgent questions are related capabilities, but they serve different operational needs. An organization might preserve relevant evidence while still requiring substantial manual work to connect it.

Conversely, a dashboard might summarize recent activity without retaining enough detail for a later investigation. Neither possibility establishes what happened inside the surveyed organizations. Both explain why a single claim of visibility needs closer examination.

The important change is the research framing. SecurityHQ places policy ownership beside the ability to establish an action sequence, making the distance between those capabilities visible.

For enterprise buyers, that creates a more demanding procurement question. A vendor’s explanation of governance should connect to the evidence a customer receives after an agent acts.

For internal security teams, the same distinction affects reporting. The existence of an approval process does not establish that investigators can recover the approval associated with a disputed action.

An accountability policy remains useful because it defines expectations. Its operational value depends on whether people can apply those expectations to a specific event.

The survey does not establish that organizations with policies experienced fewer incidents. It also does not show that purchasing additional monitoring would resolve uncertainty about responsibility.

Its narrower contribution is still consequential. Enterprises can formally allocate responsibility while lacking the evidence needed to exercise that responsibility under pressure.

That is why the story matters beyond another survey about AI risk. The research challenges whether familiar governance measures describe actual readiness once software receives delegated authority.

Delegated Security Work Puts Buyers and Operators Under Pressure

Security leaders face pressure because agents operate within systems that already divide responsibility among different teams. An application owner can authorize a workflow while another team manages its credentials and another handles incident response.

A credential is the digital proof software presents when requesting access. When several workflows share that proof, identifying the account can leave the actual initiator unresolved.

An apparently straightforward ownership question then separates into several questions. Who approved the task, who granted access, who maintained the integration, and who could stop execution?

These roles do not need to belong to the same person. The difficulty arises when the organization cannot connect them during an investigation.

Delegating work increases the importance of knowing where authority begins, changes, and ends. A named executive cannot resolve an incident simply by appearing in a governance document.

The operational consequences extend beyond security departments. Business owners need to understand whether an agent’s action served an approved objective. Application teams need enough context to distinguish expected behavior from misuse.

Legal and risk teams face a different concern: whether the available record supports the explanation the company gives afterward. A confident narrative carries limited value when its supporting evidence remains fragmented.

Vendors also face pressure because customers depend on product design for parts of that record. Customers cannot independently recover information a service never exposes or retains.

Microsoft illustrates why these questions have become immediate. Its March 2025 security agent announcement introduced agents for tasks including phishing triage, which means sorting and assessing suspected deceptive messages.

The company presented those capabilities as a way to reduce routine work for defenders. That provides a concrete deployment context without establishing that Microsoft products exhibit SecurityHQ’s reported gaps.

The comparison concerns the buying proposition. Microsoft describes work that agents can take on; SecurityHQ asks whether organizations can account for delegated activity afterward.

Those propositions belong in the same purchasing discussion. An efficiency claim becomes more useful when buyers can also assess investigation effort, intervention options, and evidence availability.

For a security operations center, the team responsible for monitoring and responding to threats, reduced routine workload offers clear appeal. Yet unresolved actions create work elsewhere.

An analyst who receives an agent’s conclusion still needs to understand its basis when circumstances change. Another investigator may need to revisit that decision after the original task finishes.

The pressure therefore reaches both deployment approval and ongoing operations. Buyers need evidence about how the system behaves after adoption, including when its actions require explanation.

This does not make autonomy inherently unsuitable for security work. It makes the scope of delegated authority central to judging whether the operational bargain is worthwhile.

Useful Automation Still Needs an Explainable Action Trail

The central tension is between the time agents save during ordinary work and the effort required to explain exceptional outcomes. Faster execution creates value only within boundaries the organization can defend.

Consider phishing triage as an illustrative workflow, rather than a reported SecurityHQ incident. An agent reviews a suspicious message, consults connected information, and produces a disposition.

A useful investigation would connect the message, the information consulted, the agent’s identity, and the resulting action. If approval applied, investigators would also need to connect that approval to the action.

Recording that a task completed answers a narrower question. It establishes an endpoint without necessarily explaining how the system reached it.

An accountable action trail must connect instructions, authority, execution, and outcome. The connection matters because any of those elements can become the disputed part of an incident.

The instruction might have been appropriate while the permission was excessive. The permission might have been appropriate while information encountered during execution redirected the task.

Alternatively, the agent might have followed the requested workflow correctly while the underlying business rule was wrong. Accountability requires room for that possibility too.

A record centered entirely on the model risks overlooking these distinctions. A model is only part of the application that receives instructions, retrieves information, and calls connected tools.

An application programming interface, or API, is a software interface through which one system requests another system’s functions. Agent activity can cross those interfaces and their separate records.

Each service can accurately describe its local interaction while leaving the overall task difficult to reconstruct. The missing element is the relationship among otherwise valid records.

Salt Security’s October 13 agent security findings offer a separate view of that problem. Its research combined more than 380 survey responses with production telemetry.

Only 12.5% of respondents said they could consistently trace complete agent paths across all agents. Salt also reported that 17.5% could automatically stop an unexpectedly behaving agent in production.

These figures measure different capabilities from SecurityHQ’s reconstruction questions. They should not be combined into a shared score or treated as equivalent estimates.

Their relevance is conceptual: tracing an action and interrupting an action are separate parts of control. A complete explanation after an incident does not reverse its consequences.

Similarly, stopping a workflow does not explain why it behaved unexpectedly. Buyers need to assess both capabilities without assuming one guarantees the other.

The commercial comparison is therefore broader than a contest between individual vendors. SecurityHQ emphasizes operational accountability, Microsoft describes delegated security tasks, and Salt highlights tracing and containment.

Those perspectives intersect around a shared customer problem. Enterprises need delegated work to remain understandable across product boundaries, where responsibility often becomes harder to establish.

Human Approval Cannot Carry the Entire Accountability Burden

Human review remains an appealing answer because it places a person near a consequential decision. Its usefulness depends on what that person can inspect and authorize.

An approval attached to a vague objective leaves room for disagreement about the permitted actions. An approval attached to a specific action establishes a clearer boundary.

Even then, investigators need to know whether execution matched the approved request. Approval and execution describe different moments, potentially separated by changing information or system conditions.

Human oversight contributes to accountability when the approval record matches the authority actually exercised. A person’s involvement does not automatically supply the missing technical history.

This distinction matters for business leaders who expect a final reviewer to absorb responsibility for an entire workflow. A reviewer cannot meaningfully assess information the system withholds.

It also matters for product teams deciding where to place approval steps. Interrupting every action introduces friction, while approving an entire task delegates broader discretion.

The practical tradeoff concerns which decisions require intervention and which boundaries software can enforce directly. Different workflows justify different answers because their possible consequences differ.

A system that only recommends a response presents a different authority question from one that changes access. The relevant comparison is the permitted action, rather than the presence of an AI label.

Identity also becomes more important as agents act across organizational boundaries. Authentication establishes who or what is making a request; authorization determines what that requester may do.

Neither function alone explains the business purpose behind a request. An investigation benefits from connecting the technical identity with the task and the person or process that delegated it.

NIST’s agent identity work provides an institutional reference for this challenge. In September, it identified software development as its first implementation use case.

That work focuses on identifying, authenticating, and authorizing agents within the software development lifecycle. It is an implementation effort, rather than evidence that enterprise accountability has been solved.

The direction matters because accountability depends partly on how authority travels through software. Standards and demonstrations can help make those relationships easier to express consistently.

However, a technical identity cannot decide who should own a disputed business outcome. Organizations still need explicit responsibility for deployment, maintenance, review, and emergency intervention.

Clear records and clear roles reinforce each other. Records help establish what happened, while roles determine who must evaluate and respond to that evidence.

The same distinction applies to organizational knowledge. A searchable team knowledge base can support access to policies and responsibilities, while execution evidence establishes what systems actually did.

Keeping those functions distinct helps avoid a familiar mistake. Documenting the expected workflow does not establish that a particular run followed it.

The Survey Raises Questions It Cannot Settle

The SecurityHQ AI agent research provides evidence about respondents’ reported experience and confidence. It does not independently measure the behavior of every agent inside their organizations.

Self-reported readiness can differ from performance during an actual incident. Respondents may interpret reconstruction, accountability, and agent activity differently.

A leader could describe strong central oversight while decentralized deployments remain outside that view. Another could report limited readiness despite having capable teams with unfamiliar internal processes.

These possibilities do not invalidate the findings. They limit the certainty of conclusions drawn from them.

The survey supports scrutiny of enterprise readiness, rather than a universal estimate of agent failure. Its public summaries should not become a substitute for testing individual deployments.

The public announcement and landing page do not provide enough methodological detail to establish broad representativeness. Readers should avoid assuming the sample mirrors every industry or enterprise size.

The combination of AI agents and automation in the incident question creates another limitation. It leaves unclear how much reported uncertainty arose from newer agents versus established automated workflows.

That distinction matters when interpreting novelty. Organizations have long struggled to assign responsibility across software integrations, outsourced services, and shared operational processes.

Agent deployments can complicate that existing problem without making every underlying weakness new. Treating the entire issue as unique to AI risks obscuring familiar control failures.

The relationship between policy and incidents also remains unresolved. The aggregate findings do not establish which respondents had policies when particular incidents occurred.

They therefore cannot demonstrate that policies failed to prevent incidents, or that organizations without policies performed worse. Either claim would require additional evidence.

The SecurityHQ AI agent research also comes from organizations with commercial interests in security and monitoring. That context deserves disclosure without automatically dismissing their observations.

The appropriate skeptical response is to examine definitions, methodology, and reproducible evidence. Commercial sponsorship and useful findings can coexist.

Similar caution applies to comparisons with Salt’s results. Different questions, populations, and measurement methods prevent a clean ranking of enterprise readiness across the studies.

Agreement in broad concern does not establish agreement in measured prevalence. The studies contribute separate observations about visibility, authority, and intervention.

Nor does the research establish that centralizing more records always improves security. Records can contain sensitive information, and access to investigative evidence creates its own responsibilities.

The analytical implication is narrower: organizations need sufficient evidence for the decisions they delegate. What counts as sufficient depends on the action and its consequences.

A convincing response would show how a specific workflow remains attributable during failure. A broader claim that a platform makes all agents accountable requires a much larger evidentiary foundation.

Watch Incident Evidence, Product Controls, and Identity Implementations

Over the coming months, the most useful developments will show whether organizations can turn stated accountability into demonstrable operational capability. Adoption announcements alone will leave that question unresolved.

The first signal is the quality of published incident reconstructions and controlled exercises. Useful accounts would connect the delegated task, relevant authority, action sequence, and intervention.

They should also identify what investigators could not recover. An incomplete but candid reconstruction provides more evidence than an assurance that a team retained control.

Repeated demonstrations across different workflows would strengthen confidence that accountability practices work beyond a prepared example. Persistent gaps would reinforce the concern raised by SecurityHQ.

The second signal is product evidence connecting agent execution with investigation and containment. Buyers should watch what vendors expose to customers, rather than relying on broad governance language.

A meaningful demonstration would show how an investigator follows a task across connected services. It would also show what happens when an authorized operator interrupts the workflow.

The timing and scope of interruption matter. Preventing the next action differs from reversing completed changes, and product demonstrations should make that distinction understandable.

Clearer controls would support broader delegation where customers can verify their behavior. Unexplained gaps between local records would strengthen the argument for narrower authority.

The third signal is implementation progress around agent identity and authorization. NIST’s announced software development use case offers a concrete place to watch for technical outputs.

Practical examples could clarify how delegated authority remains attributable as software moves between services. Their value will depend on whether organizations can apply the approach to actual workflows.

Progress would reduce ambiguity about technical identity, although it would leave business ownership decisions with the enterprise. Delays would leave customers relying more heavily on product-specific approaches.

The next useful benchmark is whether organizations can explain and interrupt delegated activity under realistic conditions. That benchmark connects the research findings with decisions buyers already face.

For readers evaluating a deployment, the SecurityHQ AI agent research offers a reason to examine the evidence behind existing assurances. Start with a consequential workflow that already has an owner. Ask that owner to explain a completed run using the records available today. Follow the instruction, the permission, the action, and the outcome. Then identify who can intervene when those elements stop matching. Missing connections reveal a more specific problem than a general concern about AI safety. They also create a clearer discussion with vendors and internal teams about what must improve. Before granting broader authority, ask for a demonstration that makes the action history and intervention boundary visible. Can your organization defend the explanation when the outcome is disputed?