Should organisations treat multimodal AI as part of their identity and access model?

Why This Matters for Security Teams

Multimodal AI can process text, images, audio, video, and structured data in a single workflow, which makes it more than a content engine when it is connected to tools or production systems. The security question is not whether the model is “intelligent enough” to count as an identity, but whether it can act with authority, consume sensitive inputs, or trigger side effects. That is why governance should follow function. Where the system can initiate actions, it needs the same discipline applied to other governed non-human actors: scoped permissions, logging, review, and clear ownership.

This is where identity and access design becomes practical. A multimodal model may receive prompts, retrieve records, invoke APIs, generate approvals, or surface recommendations that influence downstream decisions. Each of those actions creates a control point. Treating the model as outside the access model often leaves a gap between what the system can do and what the organisation believes it can do. The OWASP Non-Human Identity Top 10 is useful here because it frames machine actors around identity lifecycle, secrets, privilege, and oversight rather than around user-like authentication alone.

In practice, many security teams encounter misuse only after a model has already accessed data or called a tool beyond its intended role, rather than through intentional governance design.

How It Works in Practice

Operationally, the right model is to classify the AI system by its effective authority, not just by its interface. A passive multimodal assistant that only summarizes uploaded content needs strong data handling controls, but a system that can search repositories, send messages, update tickets, or approve transactions needs a defined identity posture. That usually means assigning a service identity, mapping approved tools, constraining secrets, and enforcing policy at the orchestration layer. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is a good anchor for translating this into access control, audit, configuration, and accountability requirements.

Practitioners should separate the model itself from the surrounding agentic workflow. The model may generate output, but the wrapper, gateway, or agent runtime usually makes the decision to call tools or release data. That means the access model should cover:

• which data classes the model may ingest and retain
• which APIs, systems, and functions it may invoke
• which approval steps are required before side effects occur
• how prompts, outputs, and tool calls are logged for review
• how secrets, tokens, and certificates are stored and rotated

Current guidance suggests treating multimodal inputs as a trust boundary issue as much as a content issue. Images, audio, and documents can carry malicious instructions, hidden data, or policy-evading prompts, so validation needs to happen before the model is allowed to reason over them. That is especially important in workflows that combine retrieval, memory, and external actions. The secure pattern is least privilege plus explicit policy checks at every transition from observation to action. These controls tend to break down in loosely governed automation stacks because tool permissions are embedded in application code instead of being centrally enforced.

Common Variations and Edge Cases

Tighter control over multimodal AI often increases operational overhead, requiring organisations to balance safer access boundaries against workflow speed and model usefulness. That tradeoff is real, especially where teams want low-friction assistants for knowledge work or customer support.

Not every multimodal system should be placed fully inside an identity framework. A standalone model used only for internal summarisation may be governed more like a data processing service than a privileged actor. By contrast, a model that interprets screenshots, drafts responses, and submits actions should be treated much more like a managed identity with delegated authority. The boundary is the level of effect, not the modality itself.

There is no universal standard for this yet, but best practice is evolving toward a risk-based classification: read-only systems, decision-support systems, and action-capable systems should not share the same access model. Edge cases include temporary evaluation environments, shadow deployments, and vendor-hosted model services where the organisation cannot directly control runtime permissions. In those cases, the minimum bar is to restrict data exposure, review contractual controls, and document who owns the model’s operational identity. This becomes especially important when the system handles personal data, regulated content, or sensitive internal records.

Related resources from NHI Mgmt Group

• How should organisations handle privileged access when workloads and AI systems are part of the model?
• How should organisations govern digital identity when AI is part of the service model?
• Why does identity security become harder when workloads and AI agents are part of the access model?
• How should IT teams govern identity access when AI becomes part of the operating model?