Notifications
Clear all
Topic starter
02/08/2026 9:46 am
TL;DR: GenAI systems face prompt injection, model poisoning, data leakage and agentic misuse because their attack surface includes language, data and autonomous actions, according to Akto. Traditional perimeter and static scanning controls do not adequately govern probabilistic model behaviour, so runtime monitoring, policy enforcement and continuous red teaming become the decisive security model.
NHIMG editorial — based on content published by Akto: How to Address Gen AI Model Security Risks, a technical blueprint for continuous protection
By the numbers:
- Only 24% of current GenAI projects incorporate security considerations.
Questions worth separating out
Q: What breaks when GenAI systems are secured like ordinary applications?
A: They miss the main risk surface.
Q: Why do AI agents complicate existing IAM and PAM controls?
A: AI agents complicate IAM and PAM because they often inherit delegated credentials, operate across multiple systems, and keep acting after the initial approval moment has passed.
Q: How do security teams know runtime AI guardrails are actually working?
A: Look for blocked poisoned inputs, flagged anomalous outputs, and traceable enforcement before responses reach users or downstream systems.
Practitioner guidance
- Implement continuous GenAI asset discovery Catalogue every LLM, AI agent and MCP tool in use, including shadow AI surfaced through user workflows and third-party integrations.
- Enforce runtime input and output controls Inspect prompts, retrieved content and tool responses before they reach the model or downstream systems.
- Separate model access from action authority Give each agent only the permissions needed for its task, and gate irreversible actions such as payments, record changes or external communications behind human approval.
What's in the full article
Akto's full blog covers the operational detail this post intentionally leaves for the source:
- Practical examples of input, output and retrieval-layer sanitisation that teams can adapt for production GenAI systems.
- Step-by-step guidance on policy enforcement inside deployment pipelines and access systems for AI assets.
- Runtime guardrail patterns for monitoring model behaviour, blocking unsafe actions and logging tool calls.
- Implementation detail on discovery, inventory and posture management for LLMs, agents and MCP tools.
👉 Read Akto's technical blueprint for continuous GenAI model protection →
GenAI model security - are your controls keeping up in production?
Explore further
02/08/2026 12:38 pm
GenAI model security is becoming a control-plane problem, not an AppSec add-on. The article is right to separate probabilistic model behaviour from deterministic application risk. Once the model can read, reason and act, the relevant questions become who can influence its context, what it can touch, and which actions need approval. That reframes security architecture around runtime control, auditability and least privilege, which is where IAM and PAM disciplines become directly relevant to AI operations.
A question worth separating out:
Q: Which frameworks help teams operationalise AI risk governance?
A: The NIST AI Risk Management Framework is the clearest reference point because it emphasises govern, map, measure, and manage as ongoing functions. Teams should use it to connect policy, evidence, and monitoring rather than treating AI governance as a one-time compliance checkpoint.
👉 Read our full editorial: GenAI model security needs continuous controls, not scan-and-ship
