Notifications
Clear all
Topic starter
06/09/2026 9:33 am
TL;DR: Security operations teams increasingly need multi-model AI support so investigations can continue across approved providers, governance boundaries, and outage conditions, according to Crogl. The real issue is not model preference but operational continuity, because SOC accountability does not pause when a provider is rate-limited, unavailable, or outside policy.
NHIMG editorial — based on content published by Crogl: The AI SOC Requirement Vendors Don't Talk About: Multi-Model Support
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams handle AI provider outages without breaking SOC operations?
A: They should pre-approve alternate models, test failover paths, and define which workflows can move automatically during an outage.
Q: Why do multi-model AI environments create governance challenges for security teams?
A: Because governance is no longer just about who can use AI, but which model can be used for which task, with what data, and under what fallback conditions.
Q: What breaks when a SOC platform depends on a single AI model provider?
A: Investigations can stall when the provider is rate-limited, unavailable, or changed without warning, and the organisation loses control over continuity.
Practitioner guidance
- Define approved model sets for each SOC workflow Map investigation, enrichment, reporting, and automation tasks to specific approved models so teams know which provider is authorised for each use case and fallback path.
- Build policy enforcement into the AI service layer Place routing, data handling, and approval checks in an internal control layer so users cannot bypass governance by selecting an unapproved model directly.
- Test provider failover under real operational constraints Run exercises for rate limits, outages, and deprecation scenarios so investigators can confirm that approved alternate models preserve continuity without policy drift.
What's in the full article
Crogl's full blog post covers the operational detail this post intentionally leaves for the source:
- How Crogl structures BYOM decision-making across approved models and providers
- Examples of continuity requirements for investigation support, enrichment, and workflow automation
- The article's discussion of provider outages, quotas, and failover conditions in SOC operations
- Why Crogl frames model choice as an accountability issue for security teams
👉 Read Crogl's analysis of multi-model AI support for SOC operations →
Multi-model AI support: what it means for SOC governance?
Explore further
06/09/2026 9:34 am
Multi-model AI support is becoming a governance requirement for SOCs, not an optimisation choice. Security operations teams remain accountable for outcomes even when the model layer changes underneath them. That creates a control problem because approved use, data handling, and continuity all depend on the ability to route work across multiple models under policy. The practitioner takeaway is to treat model portability as part of the governance design, not a nice-to-have feature.
A question worth separating out:
Q: Should organisations treat AI service sessions like privileged non-human identities?
A: Yes, when those sessions can consume paid usage, call tools, or reach sensitive data. They should be owned, monitored, and reviewed as governed identities, because their operational value and blast radius can be as high as a service account or API token.
👉 Read our full editorial: Multi-model AI support is becoming a SOC governance requirement
