AI in Trade Show Organization·October 21, 2026·7 min read

Deploying AI Agents Securely: Why the Model Is Not a Security Boundary

Prompt injection is not reliably solved. An agent can still be secure if that does not matter: permissions from the login, changes only by click, no way out. Eight architecture rules and eight questions for vendors.

The security of an AI agent comes from the software around the model, not from the model itself. The server checks data access with the permissions of the logged-in person, a person triggers changes by click, and no tool sends data outside. Even a manipulated model can then reach at most what the logged-in person is allowed to see anyway.

The rules describe the architecture Fairoo builds its AI agents on. Where agents fit in trade show organization in the first place is covered in the overview of AI agents in trade show organization. This article is aimed at IT, procurement and data protection teams at organizers who are evaluating an AI offering.

A cost problem becomes a security problem once tools are added

When AUMA, the Association of the German Trade Fair Industry, asked trade show organizers in 2025 about events that accelerate or slow down AI adoption, “cyberattacks” and “legislation” were named most often (AUMA and Prognos, October 2025, p. 44). The concern is justified, but it often misses the point. A support chatbot that can be talked into writing program code or poems with a clever input is first of all a cost problem: strangers use the paid model for their own purposes. OWASP lists this as Unbounded Consumption, including “denial of wallet”. An agent with tools needs a harder boundary, because there the same weakness does not lead to a snippet of text, but to data access or an action.

Prompt injection: why instructions to the model are not enough

Prompt injection refers to inputs that change a language model's behavior against its instructions. OWASP ranks it first among the risks for LLM applications as LLM01:2025 and notes that it is unclear whether fool-proof prevention exists at all. Two forms need to be distinguished.

• Direct prompt injection: the logged-in person writes the instruction themselves, for example “Ignore your previous instructions and …”.
• Indirect prompt injection: the instruction is hidden in a text the model reads. In a trade show context, that can be a company description an exhibitor enters in the portal, an uploaded document or an incoming message.

This leads to the basic rule of the architecture: the model is treated as an untrusted component. Everything that matters is checked by the software behind it.

Guardrails are soft, authorization is hard

Guardrails remain useful, because they keep the agent on topic. As a security measure, only the right-hand column counts. Will the assistant in the exhibitor portal write code if asked? Possibly. That costs tokens, nothing more, because it still only has the portal's tools and only the permissions of the logged-in person.

The dangerous combination of three

Under the name “lethal trifecta”, Simon Willison describes three properties that together make an agent vulnerable:

• access to private data
• exposure to untrusted content
• a way to communicate externally

When all three come together, an injected instruction can get the model to carry private data outside. Besides tools that send requests to the internet, Willison names loading an image or a link the user clicks as channels, and his recommendation is to avoid the combination entirely. An agent in the exhibitor portal inevitably meets the first two conditions: it works with exhibitor data, and at the latest on the organizer side it reads texts written by exhibitors. Only the third component can be removed.

Eight architecture rules for AI agents in the exhibitor portal

Rules 1 to 7 describe this architecture. Rule 8 adds a recommendation.

As of October 2026: the chat in the Fairoo exhibitor portal is live and answers questions from the exhibitor's data. Proposals as buttons run in the help assistant for organizer teams; in the exhibitor portal they are the next development step, and the analytics assistant in the dashboard runs in the test environment.

• 1. Identity from the session, not from parameters. Tools for exhibitors have no exhibitor parameter. Calling the open tasks always returns the tasks of the logged-in person.
• 2. No permissions of its own for the agent. It acts with the permissions of the logged-in person: an exhibitor with their own data, a project manager with their event.
• 3. Read yes, write only as a proposal. Read calls run without confirmation. For every change, the agent creates a button. Technically, a write tool would be a tool like any other for the model; that none is executed directly is a design decision.
• 4. No tool with an outside connection. The agent sends no emails, calls no external addresses and triggers no webhooks.
• 5. No unchecked links and images. Model answers contain no freely chosen URLs that the interface loads or makes clickable. Navigation runs through buttons whose target the system defines.
• 6. Only the tools of the respective screen. The analytics tools for organizers exist only while the dashboard is open, and the exhibitor portal only offers tasks, catalog, orders and document search.
• 7. Texts that are read are data. Content from documents and exhibitor profiles counts as material, not as instructions. Security does not depend on this: rules 1 to 6 apply even if the model follows an injected instruction.
• 8. Only after login, with usage limits. An agent behind a login cannot be used anonymously as a free language model. Limits per person additionally cap the costs.

The rules match the countermeasures OWASP recommends against excessive agency: only the necessary functions, minimal permissions in connected systems, human approval for consequential actions and permission checks in downstream systems instead of in the model.

What happens in the worst case

With these rules, the worst case is wrong information or an unsuitable proposal on the screen. Before an action runs, the software shows what it will execute after its own checks. The difference between reading and writing justifies the boundary: a faulty read produces a faulty statement that can be spotted and corrected, while a faulty write produces an order, a ticked-off task or a payment. In the exhibitor portal, every paid action is therefore preceded by two steps by the user: clicking the proposed cart and the regular checkout with price and terms. The AUMA study phrases the same principle as “Human-Centric by Design”: AI supports, but does not decide autonomously on admission, pricing or special promotions (p. 45).

Checklist: eight questions for AI agent vendors

Conclusion

Whether a language model can be reliably secured against manipulation is an open question. An agent becomes secure when that does not matter: the server checks permissions, a person confirms changes, and there is no way to carry data outside. Fairoo provides its functions to the agent as tools with the permissions of the logged-in person, in the exhibitor portal as well as in the dashboard. How a read-only agent works in reporting is shown in the article on the year-over-year comparison in floor space sales.

Sources

• OWASP GenAI Security Project: Top 10 for LLM Applications 2025, LLM01 Prompt Injection, LLM06 Excessive Agency, LLM10 Unbounded Consumption, content under CC BY-SA 4.0. genai.owasp.org
• Simon Willison: The lethal trifecta for AI agents: private data, untrusted content, and external communication, June 16, 2025. simonwillison.net
• AUMA and Prognos: Messen im Zeitalter von KI: An der Schwelle zwischen Experiment und Integration (Trade fairs in the age of AI), October 2025, pp. 44 and 45, in German. auma.de (PDF)