With artificial intelligence, trust isn’t what it used to be. AI is prodding security teams to move from static, binary, identity-based trust toward dynamic, probabilistic, behavior-based trust. They’re also adjusting to a shift in security from the component layer of applications to the data layer.

AI pushes a meaningful portion of security risk up from static components — libraries, services, containers — and into the data and context the system consumes at runtime, said Christopher Jess, senior R&D manager at Black Duck Software.

The root of the problem is architectural, he said.

“In current LLM-based systems, there is not a reliable security boundary between instructions and data inside the prompt, so when developers concatenate trusted instructions with untrusted content, they can accidentally grant attacker-controlled data the ability to steer decisions.”
—Christopher Jess

That means that classic application security (AppSec) controls such as patching dependencies, using static and dynamic testing, and writing web application firewall rules are no longer sufficient on their own, he said. Those legacy controls can’t detect payloads that arrive via text in an email, a document in a knowledge base, or content retrieved for retrieval-augmented generation (RAG). 

Indirect prompt injection — malicious prompts ingested from separate data sources such as web content or plugins during normal operation — can lead to data exfiltration or unauthorized actions without the attacker ever logging in to the application. In Jess’s words, “Data security becomes application security.” 

Joint government guidance on AI data security makes the same point: Machine-learning models derive their decision logic from data, so an attacker who can manipulate the data can manipulate the logic of the system.

Here’s why rethinking your architecture is essential to managing agentic AI risk — and advice on what to do now. 

[ Get Report: AI Is the Supply Chain ]

Risk has a new home in the AI age

Elad Luz, head of research at Oasis Security, said the reason that agentic AI has shifted the attack surface from the component layer to the data layer is that agents don’t execute predefined code paths. They reason over data and use it to decide what to do next. This has opened the door to a jump in prompt injection, poisoned context windows, and manipulated RAG sources, all of which are being discovered constantly, Luz said. Today’s attack surface is enormous and difficult to fully secure.

“Untrusted data is no longer passive input. It can steer an agent’s behavior, turning observation into control.”
—Elad Luz

Defenders of the component layer have spent decades building firewalls, endpoint agents, and network segmentation. But Tim Freestone, chief strategy and marketing officer at Kiteworks, said that now that risk resides on the data layer, AI agents can reach across repositories and workflows at machine speed, without the hesitation a human employee might exercise. Organizations that fail to enforce governance at the data layer — controlling what is accessed, by whom or what, under what policy — will find themselves securing infrastructure that AI simply bypasses. This requires a whole new mindset.

“The security perimeter hasn’t been breached. It’s been made irrelevant.”
—Tim Freestone

Jeff Williams, CTO and co-founder of Contrast Security, spelled out the danger: In AppSec, attacks have always arrived as data, and the code decides whether that data stays data or turns into behavior. What AI changes is that software now reads untrusted content, reasons over it, and may act on it. Passing untrusted data to a large language model (LLM) is risky, and no complete solutions exist yet, he said — only boundaries, least privilege, policy enforcement, and runtime controls that minimize attacks and limit exploitation.

Rein in privileges

One way to address agentic AI risk is to control the agent’s access privileges. Williams recommends restricting agents to least-privilege access, as well as adding strict policy checks around tool use, separating trusted from untrusted data, requiring human approval for high-impact actions, and gaining visibility by applying runtime monitoring and protection to prompts, retrieved context, tool calls, and actions.

“If you cannot see what the agent actually did in runtime, you’re basically guessing.”
—Jeff Williams

David Brauchler, technical director and head of AI and ML security at NCC Group, has more advice. AI systems with exposure to untrusted data should have privileges no higher than those of the author of that data. Organizations also need to manage data provenance, he said, and although they can’t trace every piece of data to its origin, they should know how much to trust each piece relative to the intended execution context. Another danger, he said, is building “one agent to rule them all” architectures; better to split tasks between low-privilege, sandboxed models and convert their responses to safe data types.

The infrastructure underneath the agents needs attention, too. Aner Gelman, vice president of product at Salt Security, said that beyond validating and securing an organization’s Model Context Protocol (MCP) servers, a strong API security program protects the underlying infrastructure that allows agents to operate.

Chris McHenry, chief product officer at Aviatrix, advises controlling internet egress. Full-default “deny” may not be practical for every environment, he said, but it’s powerful where it can be applied — and layering helps everywhere else. He recommends blocking command-and-control traffic, access to file-sharing sites, and post and put requests to external services, as well as implementing for agents the URL category filtering and threat blocking that  human users get. These are containment approaches every security practitioner understands, McHenry said.

“Treat the workloads like users on the network and you’re already ahead.”
—Chris McHenry

How to set up containment

The control that organizations most consistently underutilize is the governance gate between AI reasoning and execution, said Yogesh Thanvi, a member of the ISACA Emerging Trends Working Group and a senior software development engineer at Akamai Technologies. He said the Chevrolet chatbot incident — in which a customer manipulated a dealership AI agent into agreeing to sell a car for $1 — demonstrates what happens when an autonomous actor has no policy checkpoint between reasoning and action. An unsupervised agent that can call APIs, write to databases, or trigger transactions is operating with privileged access and no supervision.

“Every sensitive downstream action should require an explicit authorization decision, not an implicit one inherited from the model’s confidence level.”
—Yogesh Thanvi

Organizations need to treat AI agents as identities with ownership, access limits, and lifecycle controls, said Rosario Mastrogiacomo, chief strategy officer at Sphere Technology Solutions and the author of AI Identities. He recommends data sanitization pipelines to remove sensitive or malicious inputs, continuous adversarial testing to expose manipulation risks, tight scoping of access to APIs and tools, and short-lived, frequently rotated credentials. Audit trails must capture more than access events — inputs, outputs, and decisions  must be known as well.

Kiteworks’ Freestone said the controls that matter most right now are containment capabilities: purpose binding that limits what an agent is authorized to do, kill switches that can rapidly terminate a misbehaving agent, and network isolation that prevents lateral movement into sensitive systems. 

Layered beneath those, he added, are data-layer enforcement mechanisms: attribute-based access control that evaluates every AI request against policy in real time, input validation against prompt injection and data poisoning, and tamper-evident audit logging that creates the evidentiary trail regulators and counsel will demand. The common thread, Freestone said, is shifting from observation to action: Most organizations can watch an AI agent do something unexpected, but far fewer can stop it.

Remember your AppSec foundations

Agentic applications bring together faster development cycles and more complex system behavior, said Eran Kinsbruner, vice president of product marketing at Checkmarx — a combination that lets risk build quickly if it is not managed carefully. Uncertainty about how to secure these systems persists across the industry, he said, and the organizations that regularly test their assumptions and stay flexible will be in the strongest position as the landscape evolves.

Contrast Security’s Williams said that while formulating a practical strategy for securing agentic AI applications is not complicated, it does require discipline — and that does not describe most AI efforts he has seen. The most important thing, he said, is to base security decisions on runtime truth, not architecture diagrams or source code — in other words, watch what the agent actually does in production.

Brett Smith, a distinguished software developer at SAS, said the fundamentals still apply — and may be more critical than ever.

“Sanitize all incoming data, grant minimal necessary permissions, and validate outputs before use. These concepts are not new, but they are critically important when you have autonomous agents operating in your infrastructure.”
—Brett Smith