A support agent reads a customer email and opens a CRM record. A coding agent investigates an issue using logs and repository files. A monitoring agent summarizes an alert and proposes a remediation.
The intended behavior is useful. The dangerous question is: what happens when one of those inputs contains instructions written by someone who is not allowed to control the agent?
A web page, GitHub issue, email, log line or tool result can carry attacker-controlled text. If an agent treats that text as a command rather than data, it may misuse capabilities already granted by the company.
The malicious actor does not need direct access to the CRM, cloud project or Kubernetes cluster. They need a route for untrusted content to reach a more privileged agent that does have access.
Prompt injection is a trust-boundary failure
Traditional application input should not silently become executable commands. AI agents introduce a similar boundary between the instructions that govern the application and the content the application is asked to read.
A user can legitimately ask, "Summarize this issue." The issue itself may contain text such as an instruction to change the agent's next action. That instruction is part of the issue being summarized; it is not an authorized instruction from the user or system owner.
This risk is called prompt injection. OWASP identifies it as a major LLM application security risk, including indirect injection through external content. The source material can be plain text or multimodal content.
A strong system prompt may help, but it cannot reliably substitute for separate authorization and tool-boundary checks.
Why tools change the impact
A chatbot without connected tools can return a bad answer. An agent with tools can have consequences outside the chat.
Imagine an operations assistant with access to:
- Search and read incoming email, Slack conversations and meeting transcripts.
- Read and update the engineering task board.
- Query a production monitoring system.
- Change repository files, open pull requests or trigger builds.
- Retrieve cloud or Kubernetes credentials through a connected tool.
If all those abilities run under one identity with broad privileges, a misleading tool result may send the agent down a path the legitimate user never approved.
A safe architecture therefore limits the effect of any one untrusted input, even if the agent fails to recognize it as malicious.
Recent evidence: AI assistants targeted through their inputs
OWASP's Q2 2026 agentic exploit roundup describes cases in which attacker-controlled error data and other inputs attempted to redirect coding or debugging agents. Some entries were controlled research demonstrations; they should not be represented as confirmed mass exploitation.
The distinction matters. A demonstration shows a feasible failure mode, not the number of organizations compromised.
OWASP's Q3 2026 report discusses additional cases involving agent goal hijacking, tool misuse, identity abuse and persistent memory poisoning. These categories are also included in the OWASP Top 10 for Agentic Applications.
These sources do not imply that every AI assistant is vulnerable in the same way. The exploitability depends on which tool permissions exist, how inputs reach the model and what validation is enforced outside it.
Build three separate boundaries
Boundary one: input provenance
Keep track of where the information came from. An internal policy, a verified system administrator's instruction and a public web page do not deserve the same trust.
External text can inform the agent's answer, but it should not become privileged operational policy. Mark external content as data and make the model's allowed tasks explicit. Do not claim that labeling alone guarantees protection.
Boundary two: capability and identity
The agent should not run everything with a full administrator token.
A summarization workflow should have read-only connectors. A ticket management workflow may update a small set of fields in a specific project. A deployment workflow should use a separate, short-lived identity restricted to approved repositories and environments.
Authorization belongs in the tool service, API gateway or application code. Even if a model asks to perform an unauthorized operation, the tool must reject it. These boundaries belong in a wider DevSecOps review of identities and tool permissions, not only in the prompt.
Boundary three: high-impact action approval
Require deliberate approval before sending external messages, changing permissions, deploying software, exporting sensitive records or deleting data.
The approval should apply to the specific action: the target resource, action type, proposed content, exact account and parameters. If the model changes the action after review, the earlier approval should not silently apply.
Use deterministic state tracking to prevent repeated execution after timeouts. Approval and idempotency are security controls, not just user-experience details.
Do not forget persistent memory
Some agents remember past tool outputs or store summaries for later use. This creates another attack surface: malicious content can be promoted from one untrusted message into a remembered instruction that affects future work.
A durable memory store should track provenance, scope and retention. Facts retrieved from a public page should not be able to overwrite trusted operational policy or another customer's context. Sensitive cross-tenant retrieval requires explicit access checks.
Review memory updates separately from high-trust system configuration changes.
This is especially important when an automation runs hourly and repeatedly reads the same content. An attacker should not be able to plant one item that changes the agent's behavior for weeks.
A defensible testing approach
Before deploying a tool-using assistant, create a controlled set of negative test cases.
Use synthetic emails, tickets and web pages that contain harmless attempts to redirect the agent away from its assigned task. Give the agent access only to isolated canary resources and confirm it rejects unauthorized tool calls.
Test cases should include:
- A public issue attempting to make the agent modify an unrelated ticket.
- A log line that pretends to contain an instruction from the administrator.
- A document whose contents ask the assistant to disclose restricted information.
- A tool response requesting a high-impact action without authenticated user approval.
- A previously stored note trying to override a newer trusted instruction.
- A retry after a simulated network timeout that should not duplicate the action.
Measure whether the request was rejected by model behavior, by the separate tool authorization layer or by the human approval boundary. The latter controls must work even when model behavior is imperfect.
There is no reason to use real secrets or destructive payloads for the acceptance tests.
The operational goal
An agent can be a productive assistant without becoming a privileged universal operator.
The goal is to use language models for the parts they handle well - interpreting messy inputs, comparing evidence and preparing actions - while ordinary software enforces identity, permissions, state and approvals.
For organizations connecting AI agents to CRM, source code, cloud infrastructure and operations workflows, Big Bad Byte AI automation engineering should start with those trust boundaries. Successful automation is measured not only by what the agent can do, but also by what it cannot do when presented with malicious content.