AI agents are shifting rapidly from answering questions to taking actions. They retrieve customer data, trigger workflows, create documents, communicate with business systems, and automate decisions. With that new power comes a new challenge: as agents grow more capable, the consequences of failure grow considerably larger too.
At the recent OutSystems ONE 2026 Conference, security and governance came up again and again in the conversations around agentic systems. The pattern is hard to miss: building an agent gets easier every month, while securing it stays genuinely hard.
At Harmony Group, we increasingly work with organisations that want to go agentic, and one lesson keeps proving itself: security cannot be treated as an afterthought.
The Big Misconception
When people talk about AI risk, they often think immediately of data privacy. Questions such as:
- Will our own data be used to train public models?
- Are we masking personally identifiable information (PII)?
- Can sensitive customer information leak into prompts?
These are important questions, and sound privacy controls remain indispensable.
But privacy and security are not the same thing.
The incidents that surprise organisations most are often not privacy problems at all, but failures in system design, governance, and security. Attackers increasingly target AI systems through techniques such as prompt injection, jailbreak attempts, poisoned content, and compromised integrations. The goal is often not to reach data directly, but to manipulate the agent's behaviour.
If an AI agent is manipulated into ignoring its instructions, exposing sensitive processes, or carrying out unintended actions, the model provider is not the only party affected. The organisation operating the agent carries the responsibility, and the reputational risk along with it.
What This Looks Like in Practice
Abstract warnings about "prompt injection" only become tangible with a concrete example. Take EchoLeak (CVE-2025-32711), a vulnerability in Microsoft 365 Copilot discovered in 2025.
What made it dangerous? It was a zero-click attack. The victim only had to receive a malicious email; opening it was not even necessary. As soon as the user later asked Copilot to, say, summarise some documents, the AI also read that email in the background. The attacker's hidden instructions were carried out directly, quietly leading to a leak of company data.
No firewall was breached and no passwords were stolen. The assistant simply did what it was meant to do: read and process content. The instructions just came from the wrong person.
The structural problem: indirect prompt injection
This phenomenon is called indirect prompt injection: hostile instructions that do not come from the user themselves, but sit hidden in external content the AI takes in. It was described in theory as far back as 2023 (Greshake et al.), but EchoLeak proves it is now a real risk to enterprise software.
Security researcher Simon Willison explains this vulnerability through the "lethal trifecta". Any AI system that combines the following three properties is, by design, susceptible to data theft:
- Access to private data.
- Exposure to untrusted content (such as emails or websites).
- The ability to communicate externally.
Because most useful enterprise agents need precisely these three functions to do their work, securing them is so extremely complex.
An Architecture Problem
One of the biggest mistakes organisations make, therefore, is assuming that AI security can be outsourced to the model provider.
Modern AI systems are far more than a single LLM. They consist of prompts, orchestration layers, APIs, databases, vector stores, external tools, business logic, and user interfaces working together.
Even the most advanced model can become a security liability the moment it is built into an insecure architecture.
The real challenge, then, is not securing the model itself but the entire ecosystem around it. And that calls for a broader view of how agentic systems are designed, deployed, and governed.
A Way to Think About the AI Stack
It helps to see agentic systems as a layered problem, where each layer introduces different risks and calls for different protections. It is less a proprietary framework than a practical way of making sure nothing gets overlooked.
Broadly, it breaks down into three domains.
1. The Capability Layer (Models)
This layer contains the large language models, embedding models, and reasoning engines that power the agent.
These models are incredibly capable, but they are not deterministic security systems. They can be influenced by carefully crafted input and remain susceptible to prompt injection and jailbreak techniques. Prompt injection sits at the top of the OWASP Top 10 for LLM Applications, and understanding those limitations is the first step towards a secure implementation.
2. The Intelligence Layer (Pipelines and Orchestration)
This is where the real business logic lives. The intelligence layer connects models to APIs, databases, enterprise applications, knowledge sources, and other agents. It orchestrates workflows and determines how information flows through the system.
Classic cybersecurity concerns remain highly relevant here. Compromised credentials, exposed API keys, vulnerable integrations, or insufficient access controls can allow attackers to bypass the user interface entirely and communicate directly with backend services.
This is also where the most under-appreciated agentic risk lives: excessive agency. OWASP lists this as a distinct top-ten risk for LLM applications, and it is arguably the defining agentic vulnerability. An agent has excessive agency when it holds more capability, permission, or autonomy than the task requires: too many tools, overly broad API scopes, or the ability to take consequential actions (send, delete, pay, escalate) without a human check.
EchoLeak is dangerous because Copilot could both read private content and act within a context that untrusted input could reach. Break that combination (separate reading from any external action, require confirmation before consequential steps, grant the narrowest permissions the task needs) and the same injection attempt fails without harm. In practice, agentic security is largely about the disciplined management of what an agent is allowed to do, not just what it is allowed to read. As agents gain access to more enterprise systems, governance at this layer becomes critical.
3. The Experience Layer (User Interaction)
The experience layer covers the applications, portals, and interfaces through which users interact with agents.
This is often where malicious input enters the system. Users may, deliberately or unwittingly, supply misleading, contradictory, or manipulative instructions. And as EchoLeak shows, hostile input does not always come from the person at the keyboard; it can ride in on any content the agent takes in. Without proper safeguards, those inputs can influence behaviour further down the chain and produce unexpected outcomes.
Public-facing agents should therefore be designed on the assumption that hostile input is ultimately inevitable.
How We Approach Secure AI at Harmony
There is no universal security framework you can simply drop onto every AI project. Security starts with context.
Define the threat model first. A customer-facing support agent faces completely different risks from an internal HR assistant or an AI-driven clinical decision-support tool. Before you build in controls, you need to understand the specific risks of the use case you are solving.
Trust no input, wherever it comes from. User prompts, retrieved documents, emails, and responses from external APIs all deserve the same treatment as external input entering a classic application. Validation, separation of responsibilities, and controlled access remain essential.
Constrain agency deliberately. Give an agent the fewest tools and the narrowest permissions its task requires, separate read access from write and send access, and put a human in the loop for consequential or irreversible actions.
Put guardrails and governance in place. Modern AI platforms increasingly offer dedicated governance capabilities. Where a low-code platform such as OutSystems, with Agent Guardrails, focuses on monitoring and protecting prompts and responses at the application level, MuleSoft extends that governance into the data and integration layer. Through MuleSoft you can enforce strict API policies on the gateways that connect LLMs and (external) AI services to your enterprise systems. Such controls do not eliminate risk, but they form an important layer within a broader defence-in-depth strategy.
Stay close to the research. The AI security landscape changes at a remarkable pace, and many emerging attack techniques surface in research papers long before they become mainstream in the industry. Staying informed means following academic research, security communities, and frameworks such as OWASP's guidance for the security of LLM and agentic applications.
Building for Enterprise Requirements
At Harmony IT, we do not just help customers adopt AI. We also work out how to keep it running in tightly regulated environments, with private development ecosystems, controlled CI/CD pipelines, and reusable AI assets that fit real compliance requirements.
We also experiment through internal research and community projects, including work on AI benchmarking and evaluation tooling, because you cannot secure or trust what you cannot measure.
The Road Ahead
AI agents are rapidly becoming part of the IT landscape. The question is no longer whether organisations will deploy them, but how they will do so responsibly.
Security can no longer be a compliance checkbox added at the end of a project. It has to sit in the architecture from day one.
Because while building an agent gets easier every month, building one that stays trustworthy under pressure is the real engineering challenge.
Putting agents into production and want a fresh pair of eyes on where they might have too many permissions? That is a conversation we are glad to have.
