How should security teams protect GenAI projects at public events and demos?

Security teams should treat GenAI demos as high-risk trust environments. Limit access to test data, isolate integrations, rotate any credentials used in demonstrations, and verify that logging captures prompts, outputs, and tool calls. A public event is often where weak assumptions about data handling, access scope, and exposed secrets become easiest to exploit.

Why This Matters for Security Teams

Public demos compress risk into a short window where assumptions fail fast. GenAI projects often connect to live APIs, sandboxed data, retrieval layers, or operational tools that were never meant to be visible to a crowd. That makes the event environment a prime target for prompt injection, exposed credentials, unintended data retrieval, and overbroad tool access. NIST’s NIST Cybersecurity Framework 2.0 remains useful here because the problem is not the demo itself, but whether governance, access control, and monitoring survive under pressure.

NHIMG research on the LLMjacking threat shows how quickly attackers act once credentials are exposed, while the State of Secrets in AppSec findings underscore how often secret leakage and delayed remediation persist even in security-aware organisations. For public events, that matters because one leaked token can turn a polished showcase into a live compromise. In practice, many security teams discover demo exposure only after an attendee, recorder, or co-presented integration has already accessed something sensitive.

How It Works in Practice

The safest approach is to treat a demo as a disposable trust zone, not a production-like environment. Current guidance suggests designing the GenAI stack so the model, retrieval layer, and tools are all isolated from live systems, with separate identities, separate secrets, and separate logging. That means demo-specific accounts, test datasets with realistic but non-sensitive content, and strict network egress controls so the model cannot reach arbitrary services if a prompt or tool call goes off-script. NIST’s NIST AI 600-1 GenAI Profile aligns well with this approach because it emphasises managing model misuse, data leakage, and operational uncertainty rather than assuming normal application boundaries will hold.

Security teams should also assume the demo environment will be observed and probed. Practical controls include:

• Use ephemeral credentials issued only for the event and revoke them immediately after.
• Limit retrieval to a curated corpus with no secrets, customer data, or internal prompts.
• Log prompts, outputs, retrieval hits, and tool invocations in a tamper-evident way.
• Disable high-risk actions such as email, ticketing, payment, or admin write access unless they are strictly necessary.
• Pre-stage rollback plans so a compromised connector can be cut off without taking the whole demo offline.

NHIMG’s analysis of the Schneider Electric credentials breach is a reminder that exposed access paths are rarely contained to one system once they are discovered. These controls tend to break down when a live backend, shared staging account, or presenter laptop is reused across multiple demos because separation and revocation become operationally inconsistent.

Common Variations and Edge Cases

Tighter demo controls often increase setup overhead, requiring organisations to balance realism against containment. That tradeoff is unavoidable at public events, where a fully connected “real-world” demo can be more persuasive but also far more dangerous. Best practice is evolving for agentic and multimodal demos, especially where the assistant can browse, call tools, or chain actions across services; there is no universal standard for this yet, so teams should document what is intentionally disconnected versus merely forgotten.

Edge cases usually involve hidden dependencies. A demo may be isolated at the application layer but still inherit production secrets through a shared secrets manager, a reused OAuth client, or a convenience integration left enabled for presenters. Another common failure mode is logging that captures prompts but not the tool calls that actually triggered data movement. For public events, that gap matters as much as the model output itself. If the project uses live internet access or external plugins, threat modeling should assume audience-triggered abuse, accidental disclosure, and rapid credential harvesting are all plausible. The right question is not whether the model can answer the question on stage, but whether it can do so without creating an exposure path that outlives the demo.

Related resources from NHI Mgmt Group

• How should security teams protect public eSignature signing URLs?
• How should security teams protect identity services during large DDoS events?
• How should security teams protect sensitive data across SaaS and GenAI workflows?
• How should security teams protect sessions from infostealer-based attacks?