Secure Agentic AI in Production

Repetitive but Not Standard

Every large enterprise runs mailboxes whose only purpose is to answer questions. At this client, thousands of suppliers send inquiries regarding their invoices via email to a central accounting mailbox: Has the invoice arrived? When will it be paid? Why was the reminder not answered? Or they announce new bank details.

A correct answer always needs internal information and process knowledge. A typical case: a supplier writes that an invoice is due but has not been paid. Accounting first finds the invoice references in the mail body, the subject line or the attachments, often screenshots, PDF or Excel files. They then look up the invoice status and the reason for the outstanding payment in the system of record and pass both on to the supplier.

The work is highly repetitive, yet it cannot be reduced to fixed rules. References arrive malformed or padded with leading zeros, a single mail can contain hundreds of references and questions arrive in several languages.

The obvious alternative would be to move suppliers to a portal where they check the status of their invoices themselves. With thousands of suppliers, many of them without their own system integration, that switch would be costly and for most of them email communication is the preferred way to resolve questions.

Why Capable Prototypes Rarely Ship

Besides the open question how the solution could be implemented technically, the decision for an agentic system changed the risk profile. Three security questions had to be resolved.

First, the agent processes content written by people outside the company. Supplier mail and its attachments are an attack surface for prompt injection: Instructions hidden within an email or its attachments are read by the large language model in exactly the same way as an invoice number appearing alongside them.

Second, the agent needs read access to supplier data to be useful. It must therefore be impossible for information about supplier A to reach supplier B, whether by accident or through a deliberately manipulated request.

Third, identity verification and authorisation are difficult when the channel is email. For the agent to not only answer but also create and change data in live systems, a robust mechanism was needed to authenticate the sender and check their authorisation.

Business departments also needed an interface to review the agent's actions, intervene where necessary and see figures on quality and performance.

Without a suitable solution to address these questions, the prototype could not be put into production.

In addition, a reliable system was needed to observe and grade the agent's decisions, so that unsatisfactory results are escalated for human review.

A system prompt is not a control mechanism. The system prompt and the manipulated supplier email sit in the same context. If you are trying to program an agent in plain English, you are doing something wrong.

Cornelius HöfigExpert IT Architect

Guarantees First, Autonomy Second

The more autonomy an agentic system has, the greater the damage it can cause. mmkdigital therefore defined the following system guarantees first:

• Security checks are not executed nor initiated by the agent. They are enforced by the harness and deterministic.
• The agent can only access data linked to the supplier that sent the mail. Responses are sent exclusively by the Harness to email addresses associated with the supplier.
• The agent works in an isolated sandbox per case. Between receiving a mail and sending the reply, there is no path by which data can leave the company.

Safety-relevant behaviour is enforced by deterministic code outside the model, so the guarantees are a property of the system rather than of the model's behaviour. Statements regarding the expected behaviour of the agent are substantiated by an extensive automated test suite with corresponding evaluations and these tests must be passed before any rollout to the production system. The infrastructure reuses the client's approved cloud building blocks, so the security review starts from an accepted baseline. The system was designed modularly and built to extend to further use cases.

During the hypercare phase after go-live, a person reviews replies before sending and the agents actions as required. In the target operating model, a human in the loop is only required for exceptional cases.

Human approval is the right choice during hypercare, until the system has proven its quality in live operation. We measure how often the agent's own quality review agrees with the human decision. Once that rate reaches the agreed threshold, the system can work fully autonomously.

Efstratios BaxivanelisProfessional IT Architect

Architecture, Cloud Engineering, Delivery

mmkdigital delivered with two people covering lead solution architecture, cloud architecture and engineering, working alongside a software engineer, an enterprise architect and multiple staff members of the business unit on the client side. Decisions on the business logic remained with the client. Together with the business unit, we analysed the process, separated the business workflow from its technical implementation and optimised it for an agent. The architecture that lets the agent run it securely was also developed together.

Technically, the solution is built on Amazon Bedrock AgentCore. Intake, storage and processing are decoupled, and every message is archived immutably before the agent handles it. The agent receives process knowledge and working instructions through skills that the owning department maintains. They are loaded at runtime, and only those a given case needs. This keeps the agent's context lean: it works with the instructions relevant to the case at hand rather than one large set of rules covering everything.

Security lives in a deterministic harness around the model. Before the agent starts, the harness derives from the verified sender which supplier data may be accessed and who the reply goes to. Both are pinned in storage the model can neither read nor change. During the run the agent works in its own sandbox, separated from other cases, and a policy broker checks every tool or MCP call before it executes and every result before it returns. Anything not explicitly allowed is denied. A QA subagent then reviews the draft reply and may correct it up to two times, without being able to override any control.

Everything the agent cannot be trusted with is enforced by code outside its reach. It does not decide which supplier data it may access, it can neither see nor change the recipient of a reply and it does not decide whether a mail may leave the system. The harness settles all of this before the first token is generated.

Efstratios BaxivanelisProfessional IT Architect

In Production with Measurable Quality

The first use case covers supplier correspondence in production. Kick-off to go-live, including security clearance, took three months. Even at minimum scale and counting this single use case alone, it supports a seven-figure business case over five years. Every further department that adopts and adapts the solution adds to that figure.

A fixed part of the development process is an evaluation suite of over one hundred test cases that runs with every deployment. It covers various types of request the agent must tell apart, German and English wording, references added in attachments and dedicated tests for prompt injection and the separation of supplier data. If security behaviour or answer quality regresses, the pipeline fails and prevents a rollout to the production system.

A live dashboard assigns every reviewed case to one of seven outcomes, from ‘sent unchanged’ through ‘facts corrected by a person’ to ‘correctly refused’. It also tracks eight KPIs, including the share of cases resolved autonomously, the share of cases blocked unnecessarily and the cost per case.

The dashboard made the hypercare phase far more transparent. The business owner can see how often a draft went out unchanged, how often someone had to correct a fact and how often the system rightly refused a request. This creates clear and transparent quality metrics for the transition to an almost entirely autonomous operation.

Cornelius HöfigExpert IT Architect

What Makes Agentic AI Production Ready

The starting point was an everyday pattern found in every large enterprise: a mailbox full of questions that can only be answered by looking something up internally, worked through by hand one mail at a time. At an international car manufacturer with thousands of suppliers in the purchase-to-pay process, that mailbox is never empty.

Generative AI makes it possible to formulate an adaptive response and the harness allows the model to retrieve the information necessary for that response and create a response file. However, due to prompt injection and non-deterministic behaviour, these same systems can pose significant security risks.

mmkdigital has therefore established guardrails to rule out undesirable scenarios and has aligned the agent's capabilities accordingly.

In addition evaluation mechanisms, observability and tests were implemented. Captured traces show in detail how the agent decides and make targeted improvements at edge cases possible. Test cases catch regressions before they reach production. LLM-as-a-judge evaluation detects misbehaviour in live operation, and every such case becomes a new test case for the next deployment.

The result is a secure, reusable agentic system whose behaviour is defined by the business domain using natural language. A system capable of delivering a business case worth millions from its very first use case. In regulated organisations, it is the architecture and security mechanisms that determine whether an agent is production-ready or merely a promising prototype.

Your challenge,our passion.

Tell us where you are starting from and where you want to go. Together, we design a suitable solution and deliver it.