Three Layers of AI Security

The uncomfortable reality: Many AI security stacks focus on prevention and monitoring but stop short of producing records that are easy for third parties to review later.

The security stack everyone builds

When organizations deploy AI in sensitive environments, they typically invest heavily in two areas:

Runtime security: prompt injection defense, content filtering, rate limiting
Monitoring: usage dashboards, anomaly detection, post-hoc analysis

Both are necessary, and neither is sufficient. The reason shows up when somebody asks what happened during one particular request.

Layer 1: runtime security

Available

Pre-inference protection

Filters, guardrails, and safety systems that evaluate inputs before they reach the model. Solutions like Protect AI, Robust Intelligence, and Anthropic’s constitutional AI fall here. Vendors can catch threats.

Runtime security is well understood because it mirrors traditional application security. Input validation, rate limiting, and access control all carry over from the web stack, and the tooling has matured quickly.

Layer 2: monitoring & observability

Available

Post-hoc analysis

Logging, dashboards, and analytics that report instrumented system events after the fact. LangSmith, Weights & Biases, and traditional observability tools cover this layer. Vendors can log requests.

Monitoring reports what instrumented systems recorded. It is essential for debugging, for performance work, and for understanding how a system is being used. Its limit is that the record it produces is your own account of your own system, which is the one thing an outside reviewer cannot check.

Layer 3: evidence-grade attestation

The Gap

Third-party checkable records

Signed evidence of what configured safety controls reported for a covered inference, with the record’s format, integrity, and signing path checkable without vendor-system access. Trusted collection, routing, testing, and coverage evidence are still needed to establish actual execution and effectiveness. This layer is still relatively immature.

This is the layer that relatively few teams have built well so far. It is also the layer that emerging regulations and customer reviews increasingly reward.

Why layer 3 matters

The distinction between Layer 2 and Layer 3 is subtle but critical:

Layer 2 (monitoring) says: “Here’s what our logs show happened”
Layer 3 (attestation) says: “Here is a signed record whose covered claims and integrity properties can be checked”

When a regulator, auditor, or investigator asks what happened during a specific AI inference, Layers 1 and 2 can only provide your internal records. Layer 3 produces stronger, tamper-evident records that are easier to defend later, which is why it tends to be the layer that decides how a review goes.

The legal problem: Internal logs can be challenged on integrity and chain-of-custody grounds. Signed attestations and append-only proofs improve record integrity, but they still need governance, retention, and review processes around them.

The regulatory tailwind

The timeline is tightening across several frameworks:

Colorado SB 26-189 (“Automated Decision-Making Technology”), substantive compliance January 1, 2027. It repealed and replaced the 2024 Colorado AI Act and now centers on transparency and disclosure for covered automated decision-making technology (ADMT), including developer documentation and post-decision disclosure of how the technology was used
EU AI Act Article 12 adds automatic logging requirements for covered high-risk AI systems. Under the AI Omnibus in force since July 27, 2026, relevant high-risk obligations apply from December 2, 2027 for Annex III systems and August 2, 2028 for Annex I product-embedded systems
California ADMT Regulations (rule package effective January 1, 2026, with ADMT-specific business compliance phased beginning in 2027 under CPPA guidance) add risk-assessment, notice, access, and opt-out obligations for covered uses

All three increase the importance of reconstructable records, documentation, and operational evidence. The specifics differ, but none of them reward teams that can only point to policy documents after the fact.

What layer 3 actually requires

Evidence-grade attestation is not better logging under a new name. It requires four capabilities:

1. Guardrail Execution Trace

Tamper-evident traces binding a configured control, reported sequence, pass/fail status, and timestamp. The signature makes the covered report checkable; trusted collection, routing, and coverage evidence establish what actually ran.

2. Decision Rationale

A declared, purpose-appropriate context record: selected prompts or commitments, redactions, retrieved-data references, and configuration fields tied to a covered output. It supports investigation without claiming complete reconstruction or access to model reasoning.

3. Independent Verifiability

Cryptographically signed, tamper-evident records whose covered format and integrity properties third parties can check without vendor-system access.

4. Framework Anchoring

Direct mapping to specific control objectives in ISO 42001, NIST AI RMF, and EU AI Act Article 12.

The procurement implication

If you are procuring AI systems for healthcare, or for any other high-stakes domain, this is where your security questionnaire starts to look thin. The standard set of questions stops at the first two layers:

Do you have guardrails?
Do you log requests?
Are you SOC 2 compliant?

Better questions reach the third layer, and they are harder to answer with a certificate:

Can you produce signed records of what configured guardrails reported for a covered inference, with routing and coverage evidence?
Can third parties verify your logs without trusting your internal systems?
Can you produce evidence that would satisfy EU AI Act Article 12 requirements?

The gap in practice: A vendor can answer traditional security questions well and still leave hard questions unanswered about how a specific AI decision was recorded and reviewed.

What we’re building

GLACIS focuses on Layer 3 while treating Layers 1 and 2 as necessary parts of the supervision design. Independently reviewable evidence complements prevention and visibility; it does not replace them or establish that every action was covered.

If you’re a healthcare AI vendor whose deals are stuck in security review, or a healthcare organization trying to figure out what to demand from your AI vendors, I’d love to talk.

Read the full white paper for the complete analysis, including practical questions to ask about evidence integrity and record reconstruction.

Navigate

Solutions

Standards

Three layers of AI security: prevention, visibility, and evidence