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.

‍

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.

‍

App design and development has always looked a bit like this: designers hand off mockups. Developers ask questions. Back-and-forth happens. A confused state here, wrong spacing there. More back-and-forth. Delays follow.

‍

At Harmony IT, we’ve spent years perfecting the journey from a spark of an idea to a fully functional application. The bottleneck was rarely the code itself, more often it's the clarity between design intent and development execution.
‍
So we asked: what if designers and developers worked together during design, not after? That simple question changed how we use Figma. It's the tool we work in before anyone opens OutSystems. We have designers and developers in the same Figma files from day one. Developers see exactly what designers intended, in real time, with Dev Mode enabled. The result? We catch misunderstandings early. We reduce back-and-forth. We ship faster and with fewer bugs.

‍

Figma’s Three Competitive Advantages
‍

• Real-Time collaboration
  Unlike Sketch or Adobe XD, Figma is browser-native. This means stakeholders join with zero setup: no downloads, no plugins, no wait times. For organisations with distributed teams, this is transformational. We’ve seen design review cycles drop from 5 days to 2 days purely because participation improves.
  ‍
• Scalable design systems
  Our applications require consistency across hundreds of screens. Figma’s design system capabilities (shared components and variable documentation) mean changes propagate instantly. When you update a button style for brand compliance or accessibility standards, doing it once in Figma updates it everywhere. For OutSystems developers, this eliminates guesswork.
  ‍
• Handoff
  Figma’s Dev Mode serves up CSS classes and styling details directly to developers. These styles transfer nearly one-to-one into OutSystems, cutting build time and reducing bugs born from miscommunication. In our projects, Dev Mode reduces handoff friction by roughly 25–30%.

‍

What about AI? Figma Make vs. Figma Design

‍

No idea when you're reading this, but for now the market is genuinely changing. Tools like Framer are investing heavily in prompt-driven UI generation. You can describe what you want, and the tool builds it. Figma’s response is Figma Make, an AI feature that generates interface concepts from descriptions.

‍

This is the era of "vibe coding": working from a clarity of purpose and letting the tool accelerate the first version.
‍

• Figma Make supports exploration: You describe the intent, the AI generates options, and you pick a direction. It’s about capturing the "vibe" and intent without getting bogged down in pixels too early.
  ‍
• Figma Design supports consolidation: Once the direction is chosen, you refine layouts, apply design system rules, and ensure the precision required for a production-ready OutSystems build.
  ‍

Together, they bridge the gap. Figma Make accelerates the "vibe," while Figma Design ensures the quality.
‍

Figma reality check?

‍

Here is our honest assessment of why we're sticking with Figma.

‍

Our Stance: continuous evaluation
‍

Safe to say we won't be switching tomorrow, butthat doesn't mean we aren't actively evaluating the competition.

The speed of generative UI is undeniable. In 12–24 months, the conversation might be different. For now, Figma offers the balance we need: solid fundamentals plus emerging AI, without sacrificing the rigour that enterprise applications require.