AI API security: why there is no standard, and what one would look like

You picked an AI security vendor in a hurry, wired its SDK into every route, and shipped. Now its price tripled, or it had an outage. Switching means rewriting all of it, because there is no shared interface. That is the lock-in this post is about, and why it is worse in security than anywhere else.

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 did not 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, now part of Check Point, NeMo Guardrails, and SafePrompt) ships a different API shape, different field names, different threat taxonomies. There is no way to swap vendors without rewriting every integration. If you are still weighing those vendors, our roundup of the best prompt injection detection tools lays them out.

Why this is specifically bad for security

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

What the standard should look like

The spec does not 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, session_token?: string }
  Header: X-API-Key, X-User-IP

Response:
  {
    safe: boolean,
    threats: string[],
    confidence: number,       // 0.0 - 1.0
    processingTime: number
  }

Three endpoints. That is all.

• /api/v1/validate, single prompt check
• /api/v1/validate/batch, batch check (up to 50 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('extraction_system_prompt')that works across any compliant vendor.

What changes with a standard

Today, switching AI security vendors looks like this:

// Today: vendor lock-in
const result = await fetch('https://api.lakera.ai/v2/guard', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.LAKERA_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ messages: [{ role: 'user', content: userMessage }] })
}).then(r => r.json())
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_API_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. These are nine of the threat labels the reference implementation returns today, covering the OWASP LLM Top 10 attack surface. Getting one shared list agreed across vendors is the part that still needs doing:

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 are publishing the full OpenAPI 3.1 spec and building against it. SafePrompt implements the validate and batch endpoints today, so if you build against those, SafePrompt works out of the box. You can read the spec right now, it is live at the URL below.

What we are asking for

We are not asking Lakera or anyone else to adopt our API shape verbatim. We are 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, five years after the first OAuth draft. Payments took even longer.

AI security is young. Now is the time to get this right.

If you are building an AI security product and want to collaborate on the spec, open an issue at github.com/ianreboot/safeprompt or email [email protected].