AI's last mile: why pilot projects fail at integration and how to secure them

What is meant by the "last mile"

The term "last mile" is inseparable from the WAN world, and it fits equally well here. It comes from logistics: transporting goods over a thousand kilometres is efficient, but the final metres to the front door are expensive and error-prone. The same applies to AI. The model is the long-haul route that someone else has built and paid for. The last mile is everything in between: the tool the model uses to create a ticket, the database it pulls context from, the account under which it acts, the human who takes ownership of the result, and the logs that later prove what happened.

What matters is the shift that has taken place over the last two years. As long as AI merely produced text, the risk was limited to incorrect answers. As soon as assistants call tools, write to systems and trigger follow-up actions, a text generator becomes an actor with credentials. In late 2025, OWASP published its own risk list for agentic applications, which, alongside the classic prompt injection, specifically names goal hijacking, tool misuse, identity and privilege abuse, and poisoning of memory and context. None of these risks originate in the model — they all arise on the last mile.

Where the real difficulties lie

The agent has no identity of its own

In most pilot projects, the assistant runs under the developer's account or with a service account that was granted broad permissions "temporarily". Convenient for testing, but a blind spot in production. No access can later be attributed to a specific AI action, no permission can be revoked selectively, and a compromised prompt automatically inherits all the rights of the human behind it. Surveys from spring 2026 show that only a fraction of organisations have full visibility into which agents are talking to which systems. It follows that organisations enforcing least privilege for agents report incidents significantly less often than those that do not.

Untrusted content becomes trusted action

A model does not distinguish between instruction and content. An email, a PDF, a web page or a database field can contain text that looks like a command, and the model will execute it if given the opportunity. In a plain chat, that is merely annoying. In an agent that can send emails, move files or approve orders, it is a complete attack path with no malicious code, no exploit, and no login required. The documented incidents from 2025 and 2026 almost all follow this pattern: crafted content enters the context, and the agent acts on someone else's behalf.

Tool connectivity as a new supply chain

The Model Context Protocol (MCP) has established itself as a standard through which assistants reach tools and data sources. This significantly accelerates integration, but it shifts a well-known problem to a new location: every MCP server is a piece of software with its own provenance, its own permissions, and its own description, which the model reads and follows. A manipulated — or simply poorly built — server can slip instructions into the model ("tool poisoning"), eavesdrop on data, or carry out actions that were never intended. In practice, such servers are often fetched by business departments from public repositories without ever going through an approval process.

Shadow AI arises from friction

Where the official solution is too slow or too restricted, employees resort to their own tools, browser extensions and free services. The data then sits entirely outside any control, and the incident is only discovered once it has already occurred. Outright bans tend to reinforce this effect rather than contain it.

Context and memory as data stores

Assistants that remember conversations and intermediate results accumulate customer data, internal decisions and, occasionally, credentials someone has pasted into a prompt — over weeks. Without a defined lifecycle for this memory, an unclassified data pool emerges that neither the backup concept nor the deletion concept is aware of.

The human at the end of the chain

The last mile does not end at an API, but with a person who takes ownership of the result. If that person does not know how reliable the output is, they will either wave it through unchecked or not use it at all. Both are security problems: the former due to unnoticed errors, the latter because the process then runs informally, bypassing the solution altogether.

What the solution architect can actually do

The good news: not one of these problems requires a new security philosophy. These are the familiar zero-trust principles, applied to an actor that reads text and derives actions from it. The following measures have proven robust in real projects:

1. Give every agent its own non-human identity

An agent receives its own account in the identity directory, with short-lived tokens instead of static API keys, its own group membership, and a named owner. If it acts on behalf of a human, the delegation is represented explicitly ("Agent X acting for user Y") rather than sharing the identity. This makes access attributable, permissions revocable, and audit questions answerable.

2. A gateway between model and tools

Instead of connecting every agent directly to every system, all tool calls run through a central mediation layer. There, authentication, authorisation at the tool and parameter level, rate limits and logging are all enforced in one place. With fifty agents and twenty target systems, that would otherwise mean up to a thousand individually maintained integration points; with a gateway, it is fifty plus twenty. This is also the point at which inputs and outputs can be checked against known injection patterns, without the business application ever needing to know about it.

3. Tools as an allowlist, not a library

Each agent is given exactly the tools its use case requires, scoped as narrowly as possible: "create a ticket in project A" rather than "full ticketing system access". Read and write tools are separated, and MCP servers are treated like any other software component: with provenance checks, version pinning, inspection of tool descriptions for hidden instructions, and an approval process before they are connected to a production model.

4. Irreversible actions need a human

Anything that moves money, deletes data, communicates externally or changes permissions is prepared by the agent but confirmed by a person. This is not a stopgap, but the answer to the fact that prompt injection cannot be reliably prevented. What matters is that confirmation is informed: the person sees exactly which action, with which parameters, based on which source, is about to be triggered — not just an "OK?".

5. Validate outputs before they take effect

Model outputs are never fed directly into shell commands, SQL queries, code interpreters or approval workflows. Between model and effect sits a schema check with a strict format, value validation and an error path. Anything that does not match the expected schema is discarded and logged.

6. The AI runtime environment as its own zone

From a network perspective, an agent backend is a system with high exposure (it processes third-party content) and high impact potential (it holds credentials). It therefore belongs in its own segment with controlled egress. Outbound connections are permitted only to approved model endpoints and the gateway — no direct connections into business networks, and no outbound connections to the open internet "just in case the model wants to search for something". Data exfiltration via a compromised agent then fails at the zone boundary, rather than being left to chance. For OT environments this applies twice over: an assistant analysing plant data reads from a historian copy in the DMZ, never from the cell network.

7. Memory and context with a lifecycle

Whatever an agent stores is classified, given a retention period, and included in the deletion process. Credentials and personal data are masked before storage. Anyone using conversation histories to improve the model needs a legal basis for doing so, plus technical separation from production data.

8. Logging that answers questions

For every action, it must be possible to reconstruct which agent, on whose behalf, with what input context, which tool, which parameters, and what result. This is the foundation for the reporting obligations under NIS2 (the German implementation act has been in force without a transition period since December 2025), as well as for the evidentiary obligations that the EU AI Act requires for high-risk applications from December 2027. The transparency obligations under Article 50 of the AI Act have already applied since 2 August 2026: users must be able to recognise that they are interacting with AI, and generated content must be machine-readably marked.

9. The official solution must be the more convenient one

The antidote to shadow AI is an approved access route that is fast, integrated into everyday work tools, and accompanied by clear data classification. Anyone who knows what they may and may not paste in, and who does not need to raise a ticket with IT support to use it, will take the controlled route.

Sequence in practice

Anyone currently facing the leap from pilot to production should not start by purchasing detection tools, but by asking their own architecture four questions:

1. Under which identity does the agent act, and who can revoke those permissions?
2. Which tools does it have, who approved them, and which of these are irreversible?
3. Which third-party content enters its context, and what happens if it contains a command?
4. Where can it send data, and what stands between it and the business network?

Whoever can answer these four questions has the last mile under control. Everything else, from injection filters to agent inventories, builds on this. Without this foundation, they remain expensive add-ons for a base that cannot bear the load. But let's be honest: a great deal of know-how, including from specialists, is and will remain necessary as AI usage develops.