COMMENTARY: Security teams still treat AI like a request/response problem. That’s already outdated.Prompts are no longer the unit of risk. They're just the entrance. A single request can start a workflow that searches internal knowledge, retrieves customer records, calls tools, updates business systems, triggers approvals, and sends messages to external systems.[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
That means we can no longer answer “what happened?” by looking at the prompt, the model response, or even a single tool call. We need to ask more about the sequence of actions followed, which policies applied at each step, and whether those actions become more risky when seen together.Each of the steps are reasonable in isolation. We can read CRM records, check invoices, apply a credit within a range, and even send the customer an email.But real-world security does not care only about isolated events. Actual attacks involve a sequence. Sensitive data read + financial action + external message represents a different risk than any one of those actions on its own.Many AI systems now have access to information and capabilities that would receive extensive review before being granted to a human employee, with continual audit logging and threat detection analysis. Yet most AI governance efforts still concentrate on the request instead of the work that follows.The sequence becomes the security boundaryMost security controls still evaluate one event at a time. Was this request allowed? Was this tool call allowed? Did this rule match? That’s useful, but it’s not enough for agentic systems.AI agents create sequences - a prompt leads to a tool call which reads data that affects the model context that causes another tool call which triggers a queue to send an email. The security boundary connects multiple steps and systems.That’s why correlation matters. The same trace needs to follow the work across routes, tools, agents, queues, approvals, background jobs, and downstream APIs. Without that, every system gets a fragment and nobody can tell whether the overall workflow should have been allowed.Approving a request represents just the beginning. Once an AI system begins work, it starts retrieving information, using tools, and interacting with other systems. Every one of those steps introduces another opportunity to move data, exercise permissions, or apply business rules.Knowing that a prompt was allowed tells us very little on its own. Security teams need to trace what happened afterward. For example, which information did the AI retrieve? Which systems did it interact with? Which actions did it perform? Did every step stay within policy?Most organizations celebrate AI because it completes work faster, but security teams have a different responsibility – they need to know whether the work was performed correctly, consistently, and within the boundaries the organization intended. It’s not enough to recording the prompt – we need to reconstruct the full workflow.Governance still sees fragmentsMost AI governance gets built for the board deck, not for production.Dashboards, audit logs, reports, and policy documents are useful, but they create the illusion of control. They tell us that something happened. They rarely tell us whether the right task happened, in the right order, for the right reason.In this case, we’re not worried about missing a log line. It’s a broken chain of evidence. If the prompt resides in one system, the model call in another, the tool call somewhere else, and the policy decision in a fourth place, then nobody has a security trace. They have fragments.That creates a very different investigation. Instead of following a single sequence of events, security teams have to assemble pieces of the workflow from multiple systems before they can determine what the AI actually did and why it did it.Application security has long expected controls to explain how software reached a particular state, not simply record that something happened. AI deserves the same standard. As these systems gain access to more applications and carry out more work on their own, reconstructing the entire workflow becomes just as important as recording the individual events that make it up.Audit logs are too late Traditional compliance works well when people perform the work. Someone takes an action, an audit records it, and investigators can reconstruct what happened later.AI compresses those decisions into autonomous workflows. Retrieving data, checking permissions, selecting tools, and taking action may all happen within seconds, potentially thousands or hundreds of thousands of times a day. That shifts where policy belongs.Organizations should decide before work begins which data an AI system may access, which tools it may use, which actions require approval, and which requests should stop immediately. Those decisions should follow the workflow from beginning to end rather than waiting for an audit after the work is complete.An audit can explain why yesterday went wrong, it cannot stop an AI agent from doing the wrong thing today.The need for correlation Next up we have to deal with multi-workflow correlation.A single support case might look safe, but what happens when the same user trigger risky actions across multiple sessions? What happens when the same agent hits policy violations across tenants? What happens when the same MCP server appear in several denied workflows? That's where AI security starts to look less like prompt filtring and more like runtime policy enforcement.The policy should not only ask: Should we allow this action? It needs to ask: given what has happened in this workflow, and in related workflows, do we still allow the action?Our industry has also developed a habit of treating every AI request as a reasoning problem, but most security work isn't.Correlating events, enriching alerts, matching indicators of compromise, filtering data, and enforcing policy all follow well-defined rules. Sending every one of those tasks to a frontier model often adds cost and complexity without producing a better result.We need to decide which parts of a workflow actually require reasoning and which should simply follow codified policy. Tasks governed by well-defined rules don't become better because they're routed thrugh a frontier model. they just become more expensive to operate. They become harder to explain, more expensive to operate, and more difficult to control.Organizations should reserve frontier models for the decisions that genuinely benefit from reasoning and rely on deterministic controls for everything else. That makes it much easier to understand where AI makes decisions where policy gets enforced, and how the two work together throughout a workflow.Here's where it's critical to have correclated control. Security teams have always investigated incidents by reconstructing what happened. AI raises the bar because the work no longer happens in one place. Correlation has become one of the most important security capabilities for AI because agent security incidents do not fail one event at a time.A single request can touch multiple applications, move through several services, retrieve information from different sources, invoke enterprise tools, and trigger actions elsewhere in the environment. Looking at those events individually rarely explains the outcome. The context lives in the connections between them.That's why correlation has become one of the most important security capabilities for AI. Connecting the original request to every decision that follows gives security teams the context they need to determine whether the system behaved correctly, whether policy was enforced, and why a particular action occurred. That's the difference between logging AI activity and controlling it.The companies that get this right will not have the most detailed AI policy documents. But they can answer some simple production questions: What did the AI do? Why was it allowed? And, what stopped it from doing something worse?That's the new security boundary. Not the prompt. Correlated workflows.David Mytton, chief executive officer, Arcjet
That means we can no longer answer “what happened?” by looking at the prompt, the model response, or even a single tool call. We need to ask more about the sequence of actions followed, which policies applied at each step, and whether those actions become more risky when seen together.Each of the steps are reasonable in isolation. We can read CRM records, check invoices, apply a credit within a range, and even send the customer an email.But real-world security does not care only about isolated events. Actual attacks involve a sequence. Sensitive data read + financial action + external message represents a different risk than any one of those actions on its own.Many AI systems now have access to information and capabilities that would receive extensive review before being granted to a human employee, with continual audit logging and threat detection analysis. Yet most AI governance efforts still concentrate on the request instead of the work that follows.The sequence becomes the security boundaryMost security controls still evaluate one event at a time. Was this request allowed? Was this tool call allowed? Did this rule match? That’s useful, but it’s not enough for agentic systems.AI agents create sequences - a prompt leads to a tool call which reads data that affects the model context that causes another tool call which triggers a queue to send an email. The security boundary connects multiple steps and systems.That’s why correlation matters. The same trace needs to follow the work across routes, tools, agents, queues, approvals, background jobs, and downstream APIs. Without that, every system gets a fragment and nobody can tell whether the overall workflow should have been allowed.Approving a request represents just the beginning. Once an AI system begins work, it starts retrieving information, using tools, and interacting with other systems. Every one of those steps introduces another opportunity to move data, exercise permissions, or apply business rules.Knowing that a prompt was allowed tells us very little on its own. Security teams need to trace what happened afterward. For example, which information did the AI retrieve? Which systems did it interact with? Which actions did it perform? Did every step stay within policy?Most organizations celebrate AI because it completes work faster, but security teams have a different responsibility – they need to know whether the work was performed correctly, consistently, and within the boundaries the organization intended. It’s not enough to recording the prompt – we need to reconstruct the full workflow.Governance still sees fragmentsMost AI governance gets built for the board deck, not for production.Dashboards, audit logs, reports, and policy documents are useful, but they create the illusion of control. They tell us that something happened. They rarely tell us whether the right task happened, in the right order, for the right reason.In this case, we’re not worried about missing a log line. It’s a broken chain of evidence. If the prompt resides in one system, the model call in another, the tool call somewhere else, and the policy decision in a fourth place, then nobody has a security trace. They have fragments.That creates a very different investigation. Instead of following a single sequence of events, security teams have to assemble pieces of the workflow from multiple systems before they can determine what the AI actually did and why it did it.Application security has long expected controls to explain how software reached a particular state, not simply record that something happened. AI deserves the same standard. As these systems gain access to more applications and carry out more work on their own, reconstructing the entire workflow becomes just as important as recording the individual events that make it up.Audit logs are too late Traditional compliance works well when people perform the work. Someone takes an action, an audit records it, and investigators can reconstruct what happened later.AI compresses those decisions into autonomous workflows. Retrieving data, checking permissions, selecting tools, and taking action may all happen within seconds, potentially thousands or hundreds of thousands of times a day. That shifts where policy belongs.Organizations should decide before work begins which data an AI system may access, which tools it may use, which actions require approval, and which requests should stop immediately. Those decisions should follow the workflow from beginning to end rather than waiting for an audit after the work is complete.An audit can explain why yesterday went wrong, it cannot stop an AI agent from doing the wrong thing today.The need for correlation Next up we have to deal with multi-workflow correlation.A single support case might look safe, but what happens when the same user trigger risky actions across multiple sessions? What happens when the same agent hits policy violations across tenants? What happens when the same MCP server appear in several denied workflows? That's where AI security starts to look less like prompt filtring and more like runtime policy enforcement.The policy should not only ask: Should we allow this action? It needs to ask: given what has happened in this workflow, and in related workflows, do we still allow the action?Our industry has also developed a habit of treating every AI request as a reasoning problem, but most security work isn't.Correlating events, enriching alerts, matching indicators of compromise, filtering data, and enforcing policy all follow well-defined rules. Sending every one of those tasks to a frontier model often adds cost and complexity without producing a better result.We need to decide which parts of a workflow actually require reasoning and which should simply follow codified policy. Tasks governed by well-defined rules don't become better because they're routed thrugh a frontier model. they just become more expensive to operate. They become harder to explain, more expensive to operate, and more difficult to control.Organizations should reserve frontier models for the decisions that genuinely benefit from reasoning and rely on deterministic controls for everything else. That makes it much easier to understand where AI makes decisions where policy gets enforced, and how the two work together throughout a workflow.Here's where it's critical to have correclated control. Security teams have always investigated incidents by reconstructing what happened. AI raises the bar because the work no longer happens in one place. Correlation has become one of the most important security capabilities for AI because agent security incidents do not fail one event at a time.A single request can touch multiple applications, move through several services, retrieve information from different sources, invoke enterprise tools, and trigger actions elsewhere in the environment. Looking at those events individually rarely explains the outcome. The context lives in the connections between them.That's why correlation has become one of the most important security capabilities for AI. Connecting the original request to every decision that follows gives security teams the context they need to determine whether the system behaved correctly, whether policy was enforced, and why a particular action occurred. That's the difference between logging AI activity and controlling it.The companies that get this right will not have the most detailed AI policy documents. But they can answer some simple production questions: What did the AI do? Why was it allowed? And, what stopped it from doing something worse?That's the new security boundary. Not the prompt. Correlated workflows.David Mytton, chief executive officer, Arcjet
