Enterprise AI security now depends on runtime control beyond the model

At a glance

What this is: DeepKeep’s program participation is framed around enterprise AI security moving beyond model-level safeguards to runtime control, evidence, and governance across production environments.

Why it matters: For IAM and security teams, the key issue is that AI agents and applications can access data, tools, and workflows in ways that conventional review cycles and model-centric controls do not fully govern.

Context

Enterprise AI security now extends beyond model quality into the runtime layer where retrieval, tools, external services, and enterprise data interact. That is where policy enforcement, evidence capture, and access control determine whether an AI system behaves safely in production.

This matters because AI applications and agents can produce one outcome during evaluation and another in live use, especially when they process untrusted content or operate across languages and modalities. The governance problem is not only what the model can say, but what the system can do.

Key questions

Q: What fails when AI security focuses only on the model instead of the runtime system?

A: Model-only controls miss the application harness, where retrieval, tool calls, third-party services, and enterprise data access determine what the system can actually do. A model may look safe in testing and still produce harmful actions in production. Security teams need controls that govern runtime behaviour, not just generated output.

Q: Why do multimodal AI systems create new governance risks for identity teams?

A: Because the system can be reached legitimately and still be manipulated after access is granted. Identity controls may authenticate the user or service, but they do not stop attacker instructions buried in images from altering what the model says or does. That makes execution boundaries and content trust part of governance.

Q: How should teams evidence AI policy decisions for audit and incident response?

A: They should retain logs for blocked actions, allowed actions, tool invocations, and policy outcomes in a format that operations and compliance teams can review. Without those records, organisations cannot reconstruct what the system did, why it did it, or whether a control failed at runtime.

Q: How should organisations govern agents that access enterprise data and tools?

A: Treat them like privileged production workloads. Define what data they can retrieve, what tools they can call, what actions require approval, and how those permissions are audited, reviewed, and revoked as the system changes.

Technical breakdown

Why model-level safeguards are not enough for enterprise AI

A model can be evaluated as safe and still become risky once it is embedded in an application or agent harness. The harness adds retrieval pipelines, tool invocation, third-party services, runtime policy decisions, and data access paths that the model itself does not control. That means the security boundary shifts from output quality to action governance. In production, a legitimate request can trigger retrieval of poisoned content, tool execution, or an unauthorized downstream effect even when the model response appears harmless. The operational question is therefore whether the surrounding system constrains behaviour at runtime, not whether the model passed a benchmark. See the AI Agent Authorisation Guide.

Practical implication: Treat the application harness as the primary control surface and scope review, policy, and logging to runtime actions, not only model output.

How multilingual and multimodal inputs expand the attack surface

Once AI systems accept images, audio, video, or multiple languages, the policy problem becomes less deterministic. A control tuned to English text may miss the same malicious instruction in another language or embedded in an image frame. This creates a detection gap across prompt filtering, content moderation, and downstream action approval. Multimodal systems also widen the trust boundary because untrusted content can arrive through channels that traditional text-only review did not anticipate. Security teams therefore need controls that inspect input context, not just the prompt string, and that apply consistently across modalities rather than assuming one content type behaves like another. See the Generative AI Data Loss Prevention Guide.

Practical implication: Validate safety controls across every supported modality and language, then test whether policy decisions remain consistent when content format changes.

Operational evidence is now part of AI security architecture

Enterprise AI security is increasingly judged by whether teams can explain what happened after a system acted. That requires preserving policy decisions, runtime events, and investigation-ready evidence in a form security operations, audit, and compliance teams can use. Without that evidence, organisations cannot confidently distinguish a blocked action from an allowed one, or reconstruct why an agent reached a particular result. This is especially important when AI systems touch regulated data or external tools. The architecture therefore needs observability and accountability built into the control path, not bolted on after deployment. See the Access Review Checklist.

Practical implication: Design AI controls to emit investigation-grade evidence for every policy decision, tool action, and blocked or allowed runtime event.

NHI Mgmt Group analysis

Runtime governance, not model performance, is now the decisive AI security control plane. The article correctly shifts attention from what a model can generate to what the surrounding application can do with retrieval, tools, and enterprise data. That is the point where unsafe action becomes possible and where policy must be enforced. For security teams, the practical conclusion is that model approval alone does not establish operational safety.

Multimodal and multilingual behaviour creates a governance gap that traditional text-centric review cannot close. A control that works on English prompt text may fail against the same intent expressed in another language or embedded in an image or video frame. That means security policy has to be evaluated by input channel, not assumed to transfer across modalities. The practitioner takeaway is to test policy consistency under real production content diversity.

AI runtime evidence is becoming a security requirement, not a nice-to-have. The article highlights the need to preserve security findings, policy decisions, and runtime evidence for incident response and compliance. That aligns with a broader shift toward auditability of AI behaviour, especially when systems can access sensitive data or external services. The practical conclusion is that evidence capture must be designed as part of the control architecture.

AI agent governance now intersects with non-human identity management. Once an application or agent can access enterprise data and external tools, its authority, scope, and offboarding become identity questions as much as model questions. AI agent identities need ownership, access boundaries, and lifecycle controls, or the system will drift beyond what security teams can confidently govern. The practitioner implication is to treat agent access as a governed identity surface, not a feature flag.

The named concept here is runtime policy drift. This is the gap between what a system is approved to do during evaluation and what it is allowed to do once exposed to real inputs, tools, and production data. The more modalities, services, and languages the system supports, the larger that drift can become. Security programmes should measure and contain runtime policy drift before it becomes an operational incident.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
• Read next: AI Agent Authorisation Guide

What this signals

Runtime policy drift: enterprise AI systems often pass evaluation and still behave differently once they are exposed to live retrieval, tools, and production data. That shift means programme owners need controls that measure what the system can do after deployment, not just how it scored before release.

The governance gap will widen as AI deployments become more multimodal and more integrated into business workflows. Security teams should expect that evidence, policy consistency, and access boundaries will become the main differentiators between demonstrable control and unmanaged behaviour in production.

For practitioners

• Define the AI runtime control surface Map retrieval, tool use, external services, model artifacts, and enterprise data access as one governed security boundary.
• Test policy consistency across modalities Run the same safety and authorization checks against text, image, video, and multilingual inputs to expose inconsistent enforcement.
• Capture investigation-grade AI evidence Log policy decisions, blocked actions, allowed actions, and tool invocations in a form that supports incident response and audit review.
• Assign ownership for AI agent access Document who owns each agent, what systems it can reach, and how its access is revoked when the deployment changes.

Key takeaways

• Enterprise AI security now depends on governing the runtime layer where retrieval, tools, and external services can change system behaviour.
• The hardest risk is not a weak model alone but a control gap between evaluation and production execution.
• Security teams need evidence, policy consistency, and agent ownership to keep AI systems inside approved boundaries.

Related NHI Mgmt Group resources: Identity Governance for AI Agents Guide · Access Review Checklist · AI Agent Authorisation Guide

Key terms

• Runtime policy drift: Runtime policy drift is the gap between how an API is supposed to behave and how it actually behaves in production. It often appears after release when configuration changes, new integrations, AI-generated endpoints, or business logic changes alter exposure without a corresponding governance update.
• Multimodal Attack Surface: The combined set of risks created when an AI system accepts text, images, audio, video, or other input types. Each modality can carry instructions, malicious content, or policy evasions that do not look the same to controls tuned for plain text.
• Agentic AI Identity: The complete set of credentials, permissions, and governance controls applied to an autonomous AI agent, covering authentication, authorisation, action logging, and access revocation. Distinct from traditional NHI because agent identities are often ephemeral, delegated, and multi-hop.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners connect access control and lifecycle discipline to the broader AI governance work their programmes now require.