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

If you wire a provider’s SDK into every route, changing providers can spread work across the application. Keep request formatting, verdict mapping and error handling in one adapter. Your routes can use that stable contract while you test a replacement provider’s behavior.

What is a specification, and what is interoperability?

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.

Stripe is a provider API. OAuth and OpenTelemetry have separate standards and interoperability mechanisms. Those categories don’t prove that every infrastructure service has a universal interface or that payment processors are interchangeable.

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

The SafePrompt and Lakera contracts shown here differ in request fields, authentication and verdict meanings. An adapter can contain provider-specific changes in one place. You still need to test the new provider’s behavior, enabled categories and outage policy. If you’re 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’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.

# Proposed application contract (not an adopted cross-vendor standard)
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[] would need an agreed, versioned taxonomy before you could write logic like if threats.includes('extraction_system_prompt') that works across any compliant vendor.

What changes with a standard

Before migration, inventory each provider contract:

// Provider contracts are different; credentials alone can’t switch them.
// Lakera: /v2/guard, Authorization: Bearer, messages, flagged.
// SafePrompt: /api/v1/validate, X-API-Key + X-User-IP, prompt, safe.
// Decide settings and test matching input fixtures before migration.

Your application can normalize the different verdict fields:

// Application-owned contract, not a vendor-neutral SDK.
function normalizeVerdict(provider, responseOk, result) {
  if (!responseOk) return { decision: 'unavailable', provider }
  if (provider === 'safeprompt' && typeof result?.safe === 'boolean') {
    return { decision: result.safe ? 'allow' : 'deny', provider,
             threats: Array.isArray(result.threats) ? result.threats : [] }
  }
  if (provider === 'lakera' && typeof result?.flagged === 'boolean') {
    return { decision: result.flagged ? 'deny' : 'allow', provider,
             threats: [] } // Map enabled detector labels explicitly in your adapter.
  }
  return { decision: 'unavailable', provider }
}

// Network errors, timeouts and invalid JSON also map to unavailable.
// Only decision === 'allow' may continue to the protected operation.
// SafePrompt SDK calls require sp.check(text, { userIP: endUserIp }).

Migration changes the endpoint, authentication, input format, verdict mapping and enabled detector settings. SafePrompt also requires the end user’s IP; derive it from trusted connection data rather than accepting a caller-supplied forwarding header. Preserve timeout and error handling at the adapter boundary.

How do you test a provider migration?

Replay the same ordinary and attack inputs through both adapters, including the full retrieved content your model receives. Verify allow, deny, HTTP error, timeout, malformed JSON and missing or non-boolean verdicts. Keep user identity forwarding, retention settings and application permissions explicit; a compatible response schema doesn’t establish equal protection or privacy practices.

The OpenAPI specification defines how to describe an HTTP API. It doesn’t certify provider adoption, detector accuracy or equivalent threat coverage.

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, describing injection-related patterns within the OWASP LLM Top 10. They don’t cover the whole list, including supply-chain or access-control failures. Getting one shared list agreed across vendors is the part that still needs doing:

Keep the provider’s raw category names alongside any application mapping. Give the mapping a version and rerun fixtures when a taxonomy or policy changes; equivalent spelling doesn’t prove equivalent detection.

What does SafePrompt publish today?

This proposal concerns prompt-security APIs. Use the SafePrompt quick start to evaluate the concrete request contract.

SafePrompt publishes an OpenAPI 3.1 document for its own API. 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’s live at the URL below.

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?

A shared prompt-security contract would need agreement on request fields, verdict meanings and error behavior. Publish those details and migration fixtures so application teams can evaluate compatibility before switching providers.

AI security is young. 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 [email protected].