How should security teams prepare for GenAI adoption without assuming model prompts are the only risk?

Why This Matters for Security Teams

GenAI adoption is not just a content problem. It creates a new class of access and abuse exposure because the model can interact with data, tools, APIs, and workflow automations. Security teams that focus only on prompt filtering often miss the larger issue: what the system can reach once it is deployed. That gap shows up quickly in operational environments where copilots, assistants, and agentic workflows are wired into real systems.

Current guidance suggests treating GenAI through the same disciplined lens used for other high-impact capabilities: inventory the use case, classify the data, define allowed actions, and apply controls before scale. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, asset visibility, and protective controls as a programmatic baseline rather than a one-time review. NHIMG research on the 2026 Infrastructure Identity Survey found that only 13% of organisations feel extremely prepared for agentic AI, even as adoption accelerates.

In practice, many security teams discover the real risk only after a model has already been connected to production data or automation paths, rather than through intentional pre-deployment design.

How It Works in Practice

Preparation starts by mapping the full GenAI blast radius, not just the prompt interface. That means identifying each model, agent, workflow, and integration point, then documenting what data sources and actions it can touch. For example, a chatbot may seem low risk until it can query customer records, create tickets, trigger code changes, or invoke cloud APIs. The question becomes less “What did the user ask?” and more “What is the system authorised to do at runtime?”

Security teams should combine policy, identity, and data controls. The NIST AI 600-1 GenAI Profile helps structure risk management around transparency, measurement, and operational safeguards. NHIMG’s OWASP NHI Top 10 is especially relevant when GenAI is paired with autonomous tooling, because the identity and permission model becomes part of the attack surface.

• Inventory every GenAI use case, including internal copilots, third-party apps, and custom agents.
• Classify the data each system can read, generate, store, or exfiltrate.
• Restrict access with least privilege, short-lived credentials, and explicit allowlists for tools and actions.
• Test for prompt injection, data leakage, tool abuse, and unsafe automation before broad rollout.
• Log model outputs, downstream actions, and privilege changes so investigations can reconstruct what actually happened.

For teams handling secrets and infrastructure, NHIMG guidance on the Top 10 NHI Issues is a useful reminder that exposed credentials remain a fast path to abuse. These controls tend to break down in fast-moving environments where developers can connect new tools faster than security can review the resulting permissions.

Common Variations and Edge Cases

Tighter GenAI controls often increase friction for product and engineering teams, so organisations have to balance speed against containment. That tradeoff is real, especially when a model is embedded in customer-facing workflows or internal automation that users expect to “just work.” Current guidance suggests starting with lower-risk sandboxes, then expanding only after the access model, logging, and response paths have been validated.

There is no universal standard for this yet, but several edge cases deserve special attention. Retrieval-augmented generation can leak sensitive context even when prompts are sanitized. Agentic workflows can amplify mistakes because a single bad instruction may trigger multiple downstream actions. And in multi-tenant environments, shared models may create cross-workload exposure if identity boundaries are weak. NHIMG’s Ultimate Guide to NHIs is useful for understanding why static secrets and broad standing access are such persistent failure modes.

Teams should also distinguish between model safety and system safety. A model can be well aligned and still be dangerous if it can access production data, issue privileged requests, or chain tools without runtime policy checks. The safe operating pattern is to govern the entire execution path, not just the text box.

Related resources from NHI Mgmt Group

• How should NHS security teams reduce privileged access risk without disrupting clinical operations?
• How should security teams reduce AWS data security risk without slowing cloud operations?
• How should security teams govern shadow AI without slowing adoption?
• How should security teams reduce privileged access risk in OT without causing downtime?