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:

‍

1. Access to private data.
2. Exposure to untrusted content (such as emails or websites).
3. 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.

‍

When I started working in digital transformation, everything centred on technology.
‍

Working more efficiently. Improving processes. Helping organisations grow. New tools, new ways of collaborating; that was what mattered.
‍

But the longer I've worked in this sector, the clearer it becomes: real progress isn't just about systems. It's about people. About energy. About wellbeing. And about the impact you have as an organisation on the world around you.
‍

Over the past year, a question kept surfacing for us:

If we're helping organisations transform, how do we ensure we're making a positive impact ourselves?
‍

Not just for our clients. But for our colleagues too. Our community. Society.
‍

CSR can start with a question

Corporate social responsibility often sounds like something requiring a formal strategic plan straightaway. Sustainability reports. Targets through to 2030. The whole package.
‍

For us, it started much simpler. One colleague took the initiative, sent an email asking who wanted to get involved, and that's how the CSR working group came about.
‍

We put a collection box for used batteries in the office. No grand announcement. No communications campaign. It was simply needed.
‍

That captures how we approach this: small, concrete actions that people genuinely care about. No big speeches. Just doing it. And there are plenty more examples of activities we run—here's a straightforward, honest list of them.
‍

Transformation demands energy. From you. From your team.

Our sector moves fast. Projects come one after another. Change is constant, and before you know it, you're just pressing on. That's why last year we deliberately focused on rest, resilience and sleep.
‍

Not as some abstract concept. But practically: How do you create space for people to do good work? How do you prevent yourself and your team burning out? We organised practical sessions with the team.
‍

After one of those sessions, a colleague said: "I thought I was just a poor sleeper. But actually, I never take proper breaks."
‍

That's the point. Technology transforms organisations, but people make that transformation happen. Looking after those people is crucial.
‍

Looking after each other can also be something practical

Another initiative that generated a lot of positive response was first aid training.
‍

Not because we expect something to go wrong every day. But because there's something reassuring about knowing you can help if it's needed.
‍

The training itself was typical Harmony: serious in content, but with room for humour and genuine conversation.
‍

Impact beyond our own doors

What perhaps made the strongest impression were the actions we took beyond our organisation.
‍

We donate regularly to different causes. But the Christmas collection drives for food banks in the Netherlands and Bosnia, and St Vincent de Paul in Belgium, always generate real engagement. We fill several boxes in the office each year.
‍

Colleagues don't just bring items. They choose carefully. They do a bit of extra shopping for "the box." Some colleagues explain why they want to contribute. They share difficult periods. Stories about how close vulnerability sometimes sits to home.
‍

In those moments, it doesn't feel like a "corporate initiative." It feels like something we're doing together.
‍

Not everything is straightforward

Not every action drew large numbers immediately. Sometimes we had to remind people. Sometimes we questioned whether we were approaching it the right way.
‍

Even when things don't go as hoped, we can still extract something from it. To stay true to ourselves, for example. Because corporate social responsibility only works if it's genuine. Not because it looks good on LinkedIn, but because it aligns with who you are as an organisation.
‍

So we keep it simple. Start small. Listen. Adjust.

Actually, it's much like how we approach digital transformations.
‍

What this reveals about how we work

What I find most valuable is that these initiatives don't feel imposed from above.
‍

They emerge from conversations. From colleagues' ideas. From small suggestions that grow because people genuinely care about them.
‍

That no-nonsense mentality suits our sector too. We believe in trying, learning and improving. Not waiting for the perfect plan, but starting and getting better as we go.
‍

And perhaps that's the most important lesson from the past year: you don't change culture through grand statements.

You build culture through small, consistent actions.
‍

Where we're heading

We're still at the beginning with our CSR working group. That's fine.
‍

CSR isn't a project with an end date. It's a way of working. A way of thinking about what responsibility means.

We want to keep investing in wellbeing, sustainability and social impact. Not because it ticks a box, but because we genuinely believe it matters.
‍

Digital progress is powerful. Digital progress with genuine attention to people; that's what we're after.

‍

At the recent OutSystems ONE Conference, Matthijs van Hagen (Product Lead at Cordaan) and I shared the stage to tackle a fundamental problem in the healthcare sector. For those who don't know the organisation: Cordaan is one of the largest care providers in and around Amsterdam. With roughly 6,000 employees, they support more than 20,000 clients across elderly care, disability care, and mental health care.

‍

The operational complexity of an organisation like that is enormous. Matthijs set out a challenge every CTO will recognise: an abundance of fragmented point solutions. Cordaan's care workers were losing themselves in a maze of apps for medication, care plans, and protocols.

‍

With Cordaan Werkt, we used OutSystems to build a central "super-app" to counter that fragmentation. The latest addition to it is an advanced implementation of RAG (Retrieval Augmented Generation).

‍

What is RAG, and why is it crucial in healthcare?

‍

For anyone who doesn't yet use the term daily: RAG is an architectural pattern that couples a large language model (such as GPT-5) to a specific, external information source.

‍

Using generative AI in a clinical or care-related context is risky if you rely solely on public LLMs. The chance of hallucinations is simply too great. At the same time, the digital library of a large care institution is often a graveyard of unused PDF protocols.

‍

RAG bridges these two worlds. Instead of hoping a model "knows" the right information, we force the AI to formulate answers based exclusively on Cordaan's own, validated source documents. This process runs through a tightly defined pipeline: retrieval of relevant chunks, augmentation of the prompt, and finally generation of the answer.

‍

When a care worker asks a question, the system first finds the most relevant fragments in the internal protocols (Retrieval). This factual information is then passed as context to the AI model (Augmented), which formulates an accurate answer on that basis (Generation). This minimises the chance of hallucinations and ensures the output is always directly verifiable against the source.

‍

The architecture: from test phase to evolution

‍

During our presentation at the ONE Conference, we showed the blueprint we used during the initial test phase. It's worth noting that this architecture formed the basis for our proof-of-concept. Since then the architecture has partly shifted as we scale towards broad production, which is telling of the speed of this technology.

The foundations of that phase were:

‍

Azure AI Search as orchestrator. During the test phase we used Azure's indexing capabilities. At that point we relied mainly on BM25 search for lexical precision and complemented it with semantic search to raise contextual relevance, without the overhead of a full vector database.

‍

Intelligent chunking. We developed our own character-based chunking mechanism with a strategic overlap. This ensures the semantic value is not lost when documents are split up, which is essential for accuracy.

‍

OutSystems AI Workbench. This acted as the secure gateway to the LLM, where we kept full control over the data flows and the integrity of the prompts.

‍

Lessons learned: strategic insights for AI in healthcare

‍

Our journey with Matthijs at Cordaan surfaced a number of crucial lessons that are essential for any care institution getting started with AI:

‍

Start with a "human-in-the-loop" mindset. AI should assist, not dictate. The feedback loop where care workers can rate answers as "useful" or "not useful" is not only technical validation, but also an essential part of the adoption process on the ground.

‍

Pragmatism beats complexity. In the test phase, the temptation is strong to go straight for the most expensive vector databases. Our lesson? Start simple with lexical search and expand to semantic search when the use case calls for it. That saves considerable cost in the early stages.

‍

Data hygiene is the bottleneck. The model is only as good as its source. We found that cleaning up old PDF protocols has more impact on the quality of the answer than fine-tuning the AI model itself.

‍

Architectural flexibility is a requirement. As our own shift after the test phase proves: the AI market changes weekly. Build your solution modularly so you can switch provider or model relatively easily, without rewriting your entire application logic.

‍

Guardrails and keeping it human

‍

As Matthijs stressed, at Cordaan AI is an assistant, not a replacement. That translates into hard technical boundaries: the bot is explicitly configured as a non-medical tool, every answer contains direct citations to the source, and privacy filters safeguard anonymity before data leaves the domain.

‍

Looking ahead: from RAG to Self-RAG

‍

Although the architecture around the provider and implementation has since shifted compared with our first presentation, the vision remains unchanged. We are now looking at patterns such as Self-RAG, where the model itself assesses the quality of the retrieved information before the user sees it.

‍

The lesson for the sector is simple: the technology is a means, not an end. By starting pragmatically, learning critically from your test phase, and being willing to adapt your architecture to real-world practice, you can already give care workers back time today for what really matters: the client.

‍

Curious about what our current architecture looks like after the latest shifts, or want to talk through the specific lessons learned, or AI within your own organisation? Do get in touch.

‍