A Guide to Adopting Tiered AI Defense

August 30, 2026

The open letter on collective cyber defense lays out a decision architecture that many security teams haven’t yet formalized:

“Use capable, lower-cost models for broad coverage, and apply frontier capabilities to the hardest problems.”

This isn’t just a cost recommendation. It’s a security architecture in its own right: broad coverage with fast, cheap models, depth with frontier models only where it’s actually needed. This guide gives you a concrete framework for deciding which task belongs at which tier.

Why “use the biggest model for everything” is a design flaw

Running the most powerful available model on every alert your SIEM generates is slow, expensive, and — counterintuitively — less secure: it eats your budget and your latency exactly when you need speed the most. The right architecture is a tiered triage pipeline, similar to how a human SOC escalates from an L1 to an L3 analyst.

Tier 1 — Low-cost models for mass triage

Tasks that belong here: high volume, known patterns, low risk from a costly false negative.

  • Initial alert classification (is this noise, a likely false positive, or does it need review?).
  • Log normalization and enrichment.
  • Detection of known phishing patterns (lookalike domains, suspicious headers).
  • Automated ticket summaries for the human analyst.

Characteristics to look for in the model for this tier: low latency, low cost per token, good classification performance (no need for deep reasoning).

python

# Simplified example: alert triage with a low-cost model
def triage_alert(alert):
    response = client.messages.create(
        model="low-cost-model",
        max_tokens=200,
        messages=[{
            "role": "user",
            "content": f"Classify this alert as NOISE, REVIEW, or CRITICAL. Alert: {alert}"
        }]
    )
    return parse_classification(response)

Tier 2 — Conditional escalation

Between the low-cost tier and the frontier tier you need an explicit decision rule, not “when in doubt.” Example escalation triggers:

  • Tier 1 classification came back “REVIEW” or “CRITICAL.”
  • The asset involved is on your essential infrastructure list (defined in the technical debt audit post).
  • The pattern doesn’t match any known signature (possible novel attack).
  • There are signs the attack itself is using generative AI (more on this below).

Tier 3 — Frontier models for the hard cases

Reserve the most capable model for what actually needs it:

  • Analysis of novel or polymorphic malware, which requires reasoning about behavior, not just signatures.
  • Investigation of complex incidents with multiple sources of evidence to correlate.
  • Red teaming and simulation of AI-assisted attacks (see the dedicated post on this topic).
  • Generation of response playbooks for scenarios with no precedent in your organization.
  • Review of AI-generated code in high-criticality components (see the dedicated post).

Designing the full pipeline

Incoming alert
      │
      ▼
[Tier 1: Low-cost model] ── NOISE ──► Archive (with random sampling for QA)
      │
   REVIEW / CRITICAL / unknown pattern
      │
      ▼
[Tier 2: Escalation rules] ── doesn't meet criteria ──► Human L1 analyst
      │
   meets escalation criteria
      │
      ▼
[Tier 3: Frontier model] ──► Deep analysis + recommendation
      │
      ▼
Human L2/L3 analyst (final decision — the model doesn't autonomously execute actions in critical cases)

Important point: at tier 3, the model recommends, it doesn’t autonomously execute irreversible actions (isolating a production host, mass credential revocation). That’s the human’s role, or automation with explicit approval — something directly tied to the agentic identity traceability we cover in another post in this series.

Measuring whether the architecture is working

  • Cost per alert processed: should drop significantly versus using frontier for everything.
  • Time to containment on critical cases: shouldn’t get worse — tier 3 should kick in fast when it matters.
  • False negative rate at tier 1: audit periodically with manual sampling to confirm the low-cost model isn’t letting things through that should have escalated.

Implementation checklist

  • ☐ Map your current security tasks onto the 3 tiers
  • ☐ Define explicit escalation rules (not discretionary)
  • ☐ Implement tier 1 with a low-cost model for high-volume triage
  • ☐ Reserve the frontier model only for cases meeting escalation criteria
  • ☐ Ensure irreversible actions require human approval or audited automation
  • ☐ Measure cost, time to containment, and false negative rate periodically

Part of a series on how to put into practice the principles from OpenAI’s open letter on collective cyber defense (August 2026). Back to the full guide.

Continue Reading

The latest handpicked blog articles

Participamos de un encuentro del Posgrado en Gestión Estratégica de la Ciberseguridad de la Universidad del CEMA, donde Marcos Carabajal, CRO de Faraday, compartió una mirada sobre los desafíos actuales

November 2, 2026

Not every workspace carries the same risk. A critical finding in a staging environment doesn’t weigh the same as one in a production system that runs your business, yet most

October 30, 2026

Faraday, BeyGoo y Batuta organizan “Crónica de un ataque anunciado”, un encuentro exclusivo para CISOs y líderes de seguridad que reunirá a tres referentes de la industria para compartir experiencias,

October 29, 2026

Stay Informed, Subscribe to Our Newsletter

Enter your email and never miss timely alerts and security guidance from the experts at Faraday.

Faraday provides a smarter way for Large Enterprises, MSSPs, and Application Security Teams to get more from their existing security ecosystem.

Headquarters

Research Lab & Dev

Solutions

Open Source

© 2025 Faraday Security. All rights reserved.
Terms and Conditions | Privacy Policy
#zsiq_float, .zsiq_floatmain, [id^="zsiq"], [class^="zsiq"], iframe[id*="salesiq"], iframe[title*="chat" i] { display: none !important; visibility: hidden !important; opacity: 0 !important; pointer-events: none !important; }