AI security infrastructure starts with a simple question
An agent may have permission to read your inbox. That does not mean an email in the inbox should be allowed to give it orders. This distinction is the practical heart of AI security infrastructure: deciding what an AI system can do, whose instructions count, and what happens when those boundaries collide.
AI can help cybersecurity teams sort alerts, analyze suspicious activity, summarize threat intelligence, and support investigation. In this context, “AI in cybersecurity” means using machine-learning or language-model systems to assist security work, from interpreting data to taking actions through connected tools. The useful part is speed and reach. The hard part is ensuring an assistant does not mistake data it is inspecting for authority it must obey.
That risk grows with agentic AI. An agent can use tools, browse, retrieve documents, and carry out multi-step tasks. As the BleepingComputer report describes, malicious emails, websites, skills, plugins, or MCP servers can try to manipulate an agent into unsafe actions. The problem isn’t limited to a dramatic “AI takeover.” It can be a much smaller failure: a tool call made under the wrong instructions.
How prompt injection crosses the boundary
Prompt injection is an attempt to make an AI system follow attacker-supplied instructions instead of, or in conflict with, its intended instructions. In a direct attack, the malicious instruction arrives in the user’s prompt. In an indirect attack, it is tucked into content the system is asked to process: a web page, email, document, or retrieved source.
That distinction matters because the agent may be doing exactly what its user asked—reading a page or summarizing a file—when it encounters hostile text. Microsoft’s prompt-injection guidance describes examples involving hidden instructions in web content and documents, including attempts to expose conversation data or private information. The specific examples are not a reason to assume every agent will behave identically; they show why content from outside the trusted instruction channel must be treated as untrusted.
The attack surface is broader than visible prose. Zscaler’s ThreatLabz reported campaigns that used search-engine manipulation and CSS or HTML techniques to conceal instructions on websites. In its analysis, the hidden text attempted to influence how an agent handled a payment scam and a malicious site. The company also reported internal testing across 26 language models, with some models failing to take appropriate action or classify a site correctly in those campaigns. The point isn’t that every hidden prompt succeeds. It’s that an agent’s interpretation of a page can become part of the attack path.
An unsafe instruction might try to redirect a task, extract sensitive context, induce a payment, or trigger a tool call. Once an agent can act, a bad interpretation can have consequences beyond a poor answer. The OWASP AI Agent Security guidance identifies risks including prompt injection, goal hijacking, sensitive-data exposure, excessive autonomy, tool misuse, and supply-chain attacks involving third-party tools or data sources.
AI security infrastructure needs controls beyond the model
A model’s refusal behavior is not a security boundary by itself. OWASP recommends limiting tools to what an agent needs, scoping permissions by resource and operation, and enforcing authorization in the component that executes the tool call. In plain terms: don’t give a research assistant unrestricted shell access if it only needs to read a defined set of reports.
The same principle applies to inputs. Treat email, retrieved documents, API responses, and web pages as data, not as trusted instructions. Clear separation between instruction and content can help, but it shouldn’t be mistaken for a guarantee that an injection will be recognized. The system still needs controls outside the model’s interpretation of the text.
Memory deserves attention too. OWASP advises validating and isolating stored memory, limiting its duration and size, and checking for sensitive information. An attacker’s text should not quietly become a durable instruction that influences another session or user. This is one reason to review what an agent saves, not only what it reads in the moment.
For actions with real-world impact, use approval gates and an independent authorization check. OWASP recommends human approval for high-impact or irreversible actions, action previews, risk-based autonomy boundaries, and audit trails. A “yes” in a prompt is not enough: the execution layer should verify that approval applies to the current actor and the exact operation being requested. If the target or parameters change, approval should be checked again.
This is also where AI security surveillance—monitoring an agent’s inputs, tool requests, and actions—can help. Monitoring gives security teams evidence to review, but logging alone does not prevent a harmful action. Pair visibility with enforcement: scoped permissions, authorization middleware, and a fail-closed response when a tool or approval is unknown.
Test the protection, not just the model
Agent defenses need testing against the ways agents are actually used. The BleepingComputer report notes that agentic attacks may involve multi-turn prompt injection, tool misuse, malicious plugins or MCP servers, and harm caused by an agent misunderstanding a task even without an attacker. A single test asking whether a model refuses one hostile prompt won’t cover that range.
The report describes a proposed testing approach focused on repeatable evaluation, documented model versions, false-positive testing, and empirical validation. It separates several questions that are easy to blur: Did a protection detect the threat? Did it stop the action? Did the model itself refuse? Did the protection interfere with legitimate work? Those are different outcomes, and teams should be able to tell them apart.
OWASP likewise recommends adversarial validation and testing throughout development. Useful tests should exercise the boundaries: can a malicious page influence a browsing agent; can an untrusted email provoke a prohibited tool call; can sensitive data leak into a response or memory; does an unapproved high-impact action fail closed? Results should be tied to the model and configuration that were tested. Otherwise, yesterday’s reassuring result may say little about today’s deployment.
For enterprise leaders considering Agentic AI, Risks & governance for enterprises is not an abstract policy topic. It comes down to operational ownership: which identity an agent acts under, which data it can reach, which actions require a person, and who reviews the evidence afterward. Keep those choices explicit. A security team can then assess the actual exposure instead of relying on broad claims about a model being safe.
The rule for human–AI coexistence
An agent should act for the person or organization that granted it access—not for whichever email, website, plugin, or document it happens to encounter. That boundary is the core of safe human–AI coexistence.
Make authority explicit in the system that executes actions, and keep permissions limited to the task. Require a fresh, appropriate approval for consequential operations; treat outside content as untrusted; and retain enough monitoring to review what the agent did. The principle is deliberately plain: access is not authority, and an agent should not receive more power than its authorized task requires.