AI Agents Following Malicious Instructions Is a Real Security Problem

When an agent can read untrusted content and take meaningful action, security is not architecture polish. It is the design problem. So we designed for it instead of hoping better prompts would save us.

Sorena AI TeamSecurity and Platform5 min read

The real failure mode

AI agents are useful for one reason: they follow instructions and take action. That is also exactly why they are dangerous.

When an agent reads emails, chats, documents, tickets, websites, or uploaded files, it is exposed to content it did not write and cannot fully trust. If that content contains malicious instructions, hidden prompts, misleading context, or poisoned data, the agent can be manipulated into doing the wrong thing. Sometimes quietly. Sometimes confidently. Sometimes at machine speed.

The core issue is simple: agents do not naturally separate trusted instructions, untrusted content, malicious prompts, and data that looks harmless but carries embedded intent. To the model, these often arrive through the same channel: tokens. A webpage can become an instruction. A message can become an action trigger. A document can become an attack path. The more access an agent has, the more expensive that mistake becomes.

We tried the obvious things. They are not enough.

The industry response usually starts with AI safety settings, refusal behavior, prompt engineering, guardrails, and output filtering. We use those too. But we are not going to pretend they solve the problem.

Safety settings do not work well enough. They help at the margin and reduce some bad behavior. But when an agent operates in messy, mixed-trust environments, they are not a reliable control boundary.

Guardrails are necessary, but still not enough. This has been proven repeatedly: guardrails alone do not stop prompt injection, context poisoning, or instruction hijacking when the model is still allowed to consume untrusted content and act on it. If the system is grounded in manipulable context, better manners at the output layer will not save it.

Did Sorena solve AI agent security?

No. And anyone claiming they fully solved prompt injection in agentic systems should be challenged very hard.

What we did build is a mitigation strategy that materially reduces the risk. Agent safety does not begin with the final answer. It begins with what the agent is allowed to read, trust, and use in the first place.

Reduce blast radius before you trust the agent

Prompt injection is not solved by one magic guardrail. The safer architecture is layered: restrict sources, preserve workspace permissions, limit tools by role, block high-risk actions without approval, log every retrieval and action, and require citations for claims that affect a decision.

That changes the failure mode. If a malicious instruction sneaks into a document, the agent still cannot read outside its workspace, cannot call tools it was never granted, cannot silently approve its own output, and cannot hide the source that influenced the answer. You are not betting that the model never gets confused. You are making sure confusion has nowhere useful to go.

The Sorena approach: reduce exposure, ambiguity, and blast radius

Instead of asking our agents to scrape random websites and treat the open web as a trustworthy knowledge layer, we built Sorena SSOT, our Single Source of Truth. It is the foundation we use to feed our AI systems trusted, structured, source-linked data instead of letting them roam across uncontrolled inputs by default.

SSOT is a governed knowledge layer that centralizes curated regulatory content, standards and frameworks, security datasets, trusted public sources, customer and project documents, and permissioned internal knowledge. In practice, that includes laws and regulations, NIST frameworks, ISO and ETSI materials, EU regulatory content, CVE, CWE, and CAPEC security datasets, and project documents uploaded into controlled workspaces. The point is not more data. The point is better trust boundaries around data.

Why this matters for AI agents

When agents rely on random websites, ad hoc searches, and mixed-trust sources, the context window becomes a liability. When they rely on governed, curated, source-linked, permissioned knowledge, the operating model improves:

  • Less exposure to hostile instructions
  • Less context pollution
  • Less ambiguity about provenance
  • Better traceability and auditability
  • More predictable outputs

This does not eliminate risk, but it changes the risk profile materially. You cannot remove all malicious inputs from the world. You can stop designing your system to depend on them.

What actually works at scale

The model we trust is not to give the agent more freedom and hope better prompts will save it. The model we trust is:

  • Humans make decisions
  • Systems enforce boundaries
  • Trusted data is prioritized
  • Provenance is visible
  • Permissions stay controlled
  • Risky actions are constrained
  • Outputs stay traceable to sources

That is the difference between an impressive demo and a defensible system.

The bigger point

AI agents following malicious instructions is not a strange failure mode. It is one of the most predictable failure modes in modern AI systems. If an agent can read untrusted content and take meaningful action, then security is not optional architecture polish. It is the design problem.

We do not claim to have magically solved that problem. We mitigate it by grounding our systems in Sorena SSOT, using trusted and governed sources, limiting dependence on random internet content, and treating traceability and control as part of the product, not an afterthought. That is the engineering posture: assume hostile instructions can appear, then reduce what they can affect. If you are building AI agents, ask a harder question than how smart the model is. Ask what it is allowed to trust.

Frequently asked questions

Does Sorena claim to have solved prompt injection?+

No. Prompt injection remains a recognized LLM application risk, especially when agents read untrusted content and can take action. Sorena implements a mitigation strategy that materially reduces risk by controlling what agents are allowed to read, trust, and act on.

What is Sorena SSOT and how does it help security?+

SSOT is a governed Single Source of Truth that centralizes curated regulatory content, standards, security datasets (CVE, CWE, CAPEC), trusted public sources, and permissioned internal documents. Feeding agents trusted, source-linked data instead of the open web reduces exposure to hostile instructions, context pollution, and provenance ambiguity.

What controls reduce prompt injection blast radius?+

Start with source restrictions, workspace permissions, role-based tool access, approval gates for high-risk actions, retrieval and action logs, and source citations for decision-impacting claims. OWASP treats prompt injection as a top LLM application risk; the practical response is not one guardrail, but a layered control stack that limits what a compromised instruction can reach.

Sources

Share

See Sorena do the work

Book a demo and watch one real compliance workflow go from question to audit-ready output.