How should security teams investigate activity when AI agents, people, applications, and data all participate in the same workflow?

Security teams should investigate the full chain, not just the isolated event. When a human delegates work to an agent, and that agent authenticates, reads data, transforms it, and passes it onward, the real risk sits in the relationships between those steps. A graph-based investigation preserves that chain so analysts can see who acted, what was touched, and where information moved.

Investigating a Shared AI-Agent Workflow as a Chain of Actions

When AI agents, people, applications, and data all participate in the same workflow, the investigation must follow the sequence of trust and execution, not just the final alert. The core question is not only what happened, but which actor initiated each step, which identity executed it, and how data moved between systems. That distinction matters because the same observable outcome can arise from legitimate delegation, overbroad access, broken automation, or abuse of the agent’s authority.

This is why graph-oriented investigations are so valuable: they preserve the relationship between the human requester, the agent, the calling application, and the records touched. For a useful external baseline on how agentic systems create distinct risk surfaces, see the OWASP Top 10 for Agentic Applications 2026. A flat event log can confirm that access occurred, but it often cannot explain whether the access was expected, delegated, or coerced through an unsafe workflow design. In practice, many security teams discover the critical relationship only after a routine automation has already transferred data farther than intended.

How Investigations Work When Humans and Agents Share the Same Path

A workable investigation starts by reconstructing the workflow as a connected chain: who requested the task, what agent or application accepted it, what credentials or session context were used, which systems were queried, and where the output landed. The analyst is looking for transitions between actors, not merely isolated events. If an agent authenticates successfully, reads a source system, rewrites or enriches the data, and then forwards it to another application, each transition becomes part of the evidence. That is especially important when the agent acts with delegated authority, because the human may be the business owner while the machine identity performs the actual access.

Security teams should treat identity, permission, and data lineage as one investigative unit. The practical aim is to answer whether the workflow stayed within its intended scope. That means checking whether the agent used the correct approval context, whether the application-to-application handoff preserved the expected policy, and whether the data moved into a location where it could be reused or exposed beyond its original purpose. If the workflow spans multiple environments, the team also needs timestamps that line up across orchestration logs, authentication records, data-access telemetry, and downstream application logs. Without that alignment, investigators can see fragments of the path but not the control point where the chain diverged.

• Start with the human request, then follow the agent’s execution path step by step.
• Correlate authentication, authorization, and data-access events across all participating systems.
• Separate intended delegation from unexpected reuse of the same identity or session.
• Track where output was stored, forwarded, or re-ingested by another process.

For broader governance and model-risk context, the NIST AI Risk Management Framework is useful because it frames AI activity in terms of governance, mapping, measurement, and management rather than only incident response. Where the environment includes adversarial manipulation of model behaviour or autonomous tool use, the MITRE ATLAS adversarial AI threat matrix can help analysts think about abuse paths. This guidance breaks down when the organisation cannot correlate the agent’s identity, the business approval, and the downstream data trail in a common evidence model.

Where the Usual Log Review Falls Short

Tighter workflow visibility often increases investigative overhead, requiring organisations to balance completeness against the volume and complexity of cross-system telemetry.

The standard failure mode is to investigate the most visible event first and assume it explains the whole workflow. That approach misses two common realities: an agent may be acting under valid authority while still exceeding the intended scope, or a downstream application may be the point where the risk becomes visible only after the data has already moved. The question is not whether a single control denied or allowed access, but whether the end-to-end chain stayed faithful to the original request.

Another edge case is mixed accountability. A person may initiate the task, an agent may decide how to complete it, and a separate service may perform the actual data transfer. In that situation, assigning root cause to a single event is usually too narrow. Guidance-vs-consensus here is still evolving: many teams agree that graph reconstruction is the right investigative model, but there is not yet universal consensus on the minimum telemetry needed to make it reliable across vendors and platforms.

Teams also need to be careful with legitimate automation that looks suspicious only because it is highly connected. A chained workflow is not automatically a compromise. The key distinction is whether the observed path matches the approved delegation pattern and whether the data movement remained within expected boundaries. Where those boundaries are unclear, investigators should treat the workflow as a governance problem as well as an incident review.

Practitioner Guidance

What to verify: Verify that you can correlate human intent, agent execution, and downstream data movement using the same case record. If those elements live in separate tools with no shared identifier, the investigation will be slow and attribution will be unreliable.

What practitioners underestimate: Analysts often assume the agent is the primary subject, when the real issue may be a workflow design that lets legitimate authority travel too far. The useful question is whether the chain preserved scope, not whether any single event looked malicious.

Decision rule: If you cannot reconstruct the full path from request to data destination, treat the case as a workflow-integrity investigation rather than a simple alert review. That shifts attention to missing telemetry, ambiguous delegation, and uncontrolled data reuse.

Practitioner takeaway: The most useful investigations do not stop at “what happened”; they prove whether the approved chain of trust was still intact at every handoff.

Related resources from NHI Mgmt Group

• How should security teams implement centralized authorization when applications, gateways, and AI agents all need the same policy decisions?
• How should security teams handle risks from AI browser extensions?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern personal data used by AI agents?