Why AI Security Needs an API Standard (And What It Should Look Like)

Every Infrastructure Category Has a Standard. Except This One.

Think about the last time you integrated authentication. You probably used OAuth 2.0 or OIDC. You didn't have to choose between incompatible auth systems — you chose a provider (Auth0, Clerk, Supabase), and the interface was standardized.

Same for payments. Stripe defined the interface. Dozens of services are Stripe-compatible. You can switch processors without rewriting your checkout code.

Same for observability. OpenTelemetry defined the interface. Your traces work across Datadog, Honeycomb, Jaeger — any backend that speaks OTLP.

AI security has none of this. Every vendor — Lakera, NeMo Guardrails, and SafePrompt — ships a different API shape, different field names, different threat taxonomies. There's no way to swap vendors without rewriting every integration.

Why This Is Specifically Bad for Security

Vendor lock-in is annoying in most categories. In security, it's dangerous for a few specific reasons:

What the Standard Should Look Like

The spec doesn't need to be complex. The UNIX philosophy applies: do one thing well. An AI security gateway should validate a prompt and return a structured result.

# ai-security-gateway-spec v1.0
POST /api/v1/validate
  Body:  { prompt: string, sessionToken?: string }
  Header: X-API-Key, X-User-IP

Response:
  {
    safe: boolean,
    threats: string[],
    confidence: number,       // 0.0 – 1.0
    processingTimeMs: number,
    passesUsed: number
  }

Three endpoints. That's it.

• /api/v1/validate — single prompt check
• /api/v1/validate/batch — batch check (up to 10 prompts)
• /api/v1/usage — quota and billing info

The response schema is the important part. safe: boolean is the primary decision signal. threats: string[] uses a shared enum so you can write logic like if threats.includes('system_prompt_extraction')that works across any compliant vendor.

What Changes With a Standard

Today, switching AI security vendors looks like this:

// Today: vendor lock-in
import Lakera from '@lakera/guard'
const guard = new Lakera({ apiKey: process.env.LAKERA_KEY })
const result = await guard.detect({ input: userMessage })
if (result.flagged) throw new Error('Blocked')

// Switching vendors = rewriting every integration

With a standard interface, every vendor looks the same to your code:

// With a standard: swap freely
import SafePrompt from 'safeprompt'
const sp = new SafePrompt({ apiKey: process.env.SAFEPROMPT_KEY })
const result = await sp.check(userMessage)
if (!result.safe) throw new Error('Blocked')

// Same interface. Any compliant vendor works.

The only thing that changes is which API key you configure. Your application code — the part that handles blocked prompts, logs threat categories, and alerts on anomalies — stays identical.

The Threat Taxonomy Matters as Much as the Schema

Half the value of a standard is the shared vocabulary. The spec defines nine threat categories that cover the full OWASP LLM Top 10 attack surface:

Using shared category names means your alerting, logging, and incident response tooling works regardless of which vendor detected the threat.

SafePrompt Is the Reference Implementation

We're publishing the full OpenAPI 3.1 spec and implementing it exactly. SafePrompt's API already conforms to the spec — if you build against the spec, SafePrompt works out of the box.

What We're Asking For

We're not asking Lakera or anyone else to adopt our API shape verbatim. We're proposing a conversation: what should the standard look like?

The AI security category is young enough that we can still establish interoperability before lock-in calcifies. Auth took until OAuth 2.0 (2012) to get a standard — eight years after the category existed. Payments took even longer.

AI security is two years old. Now is the time to get this right.

If you're building an AI security product and want to collaborate on the spec, open an issue at github.com/ianreboot/safeprompt or email support@safeprompt.dev.