Every enterprise security vendor has a three-tier support model. Every support tier promises "24/7 response." Every contract has response-time SLAs. On paper, support comparisons look identical. In practice, the operational differences appear the first time a customer needs escalation during an incident — and by then the contract is already signed. Griffin AI and Mythos-class general-purpose tools approach support with different philosophies, and the downstream customer experience diverges noticeably.
What support actually needs to do
Four categories of work:
- Onboarding support. Get the customer to value in the first 30 days.
- Operational support. Answer tier-2 questions, diagnose edge cases, investigate specific findings.
- Incident support. 24/7 response when something the customer depends on is broken.
- Strategic support. Quarterly business reviews, roadmap input, integration planning.
Different vendors prioritise these differently. Griffin AI weights incident and strategic support heavily; Mythos-class vendors more commonly weight onboarding and operational support.
Where the architecture determines support quality
Two direct consequences of the engine-plus-LLM architecture:
Support can diagnose structured outputs deterministically. When a customer asks "why did the platform miss this finding?", Griffin AI support can inspect the engine's call graph, the reachability trace, and the Griffin reasoning step. The diagnosis is mechanical. A Mythos-class support engineer looking at a pure-LLM output has less to inspect — the model's reasoning is not fully transparent, and the support answer is often "the model didn't identify this pattern; we'll investigate."
Incident reproduction is possible. When a customer escalates "the platform behaved strangely on this specific input," Griffin AI support can rerun the engine deterministically and reproduce the behaviour. Mythos-class support often cannot reproduce because the LLM output is non-deterministic. "Works on our end" is the common response.
Tier structure in practice
Tier 1 (product questions, configuration help): both vendor types handle this well. Self-service documentation plus chat support.
Tier 2 (operational issues, integration debugging): Griffin AI's deterministic engine means tier 2 can reproduce issues in a test environment. Mythos-class tier 2 often has to escalate because reproduction is harder.
Tier 3 (incident response, deep debugging): Griffin AI assigns a specific engineer who knows the customer's deployment. Mythos-class tier 3 varies; smaller vendors pool tier 3 across customers, which produces slower context-building during incidents.
The incident-response shape
When a customer has a production incident involving the platform — whether caused by the platform or just requiring its analysis — three things determine how the support interaction goes:
How fast does someone who can help pick up the phone? Response SLAs cover this on paper. Real response times vary.
How deep can the first responder go? A first responder who can trace through the engine's output in real time is worth more than a first responder who can only escalate. Griffin AI trains support to the engine level. Mythos-class vendors with less transparent platforms typically cannot.
Can the responder produce a written RCA? Post-incident, the customer needs a root-cause analysis. Deterministic engines produce clean RCAs. Non-deterministic LLM outputs produce narratives that are harder to defend in a customer's own post-incident review.
A concrete example
A customer hits an incident at 2am: the platform's latest release appears to have regressed the detection of a specific injection class. Engineering has rolled back the affected service to mitigate, but they need to know what happened for their own internal review.
Griffin AI support: reviews the eval harness runs, identifies the specific test case that regressed, confirms the release should have been gated but was not due to a specific infrastructure issue. Produces a written RCA in 48 hours with corrective actions. The customer's own review lands cleanly.
Mythos-class support in the same scenario: investigates, identifies that the underlying model shifted in a recent upgrade. Offers the customer an older model version as a workaround. Cannot produce a deterministic RCA because the model behaviour is not fully reproducible. The customer's review takes more effort to close.
What the support contract should specify
Beyond the standard SLA boilerplate, three specific asks:
- Named escalation engineer. Not a pool — a specific person who knows the deployment.
- RCA commitment. A written RCA within N business days for any tier-3 incident.
- Access to the engine's internal state during diagnosis. The support team needs to be able to look under the hood.
Vendors who agree to all three have mature support programs. Vendors who push back on item three are vendors whose platform is opaque to their own support team.
How Safeguard Helps
Safeguard's support is built around the deterministic engine + Griffin AI architecture. Tier 2 and tier 3 engineers have direct access to the engine's call graph, reachability traces, and Griffin reasoning records. Named escalation contacts are assigned at contract signature for enterprise tiers. RCAs are a standard deliverable for any tier-3 incident. For organisations whose experience with AI-for-security support has been "we'll investigate and get back to you," the diagnosable architecture changes the shape of that conversation.