Skip to main content

Supply Chain Risk: What Happens When Your AI Provider Is Compromised

An AI provider compromise is not just an availability problem. It is a trust-boundary failure. If the provider is suspected of leaking prompts, mishandling credentials, training on restricted traffic, or serving manipulated behavior, the question is no longer "Can we keep the app online?" The question becomes "How fast can we stop sending the wrong traffic to the wrong place without losing control of everything else?" Keeptrusts is useful in that moment because the gateway lets you change routing, request controls, and evidence collection at one decision point instead of patching every application separately.

Use this page when​

  • You need a concrete response plan for a provider-side compromise, not a generic vendor-risk checklist.
  • You want to understand how provider failover interacts with request-boundary controls and audit evidence.
  • You need to keep some AI traffic running while you remove or quarantine an affected provider.

Primary audience​

  • Primary: Technical Engineers and Security responders
  • Secondary: Technical Leaders, AI platform owners, AI Agents

The control map​

The five shortest reference pages to keep open while you read are Rate Limits, Audit Logger, Prompt Injection Detection, Block Prompt Injection Attacks Before They Reach Your Models, and Prevent Sensitive Data Leaks in AI Requests.

The problem​

When people hear "provider compromise," they often picture downtime. That is the visible failure, but it is not the most important one. The more dangerous scenario is silent degradation of trust.

The provider might still answer requests while no longer meeting your security assumptions. A rotated or leaked provider credential may allow misuse. A contract or backend change may suddenly invalidate your zero-retention posture. A provider-side incident may create uncertainty about whether prompts, outputs, or metadata were exposed. In the worst case, the provider stays reachable and your application keeps sending traffic because nothing at the application layer knows the trust model changed.

Direct-to-provider integrations make this hard to contain. Each client has to be changed independently. Some clients will keep using the compromised provider longer than others. Some teams will respond by shutting everything off, which is safe but operationally expensive. Others will keep traffic flowing because they have no practical way to distinguish low-risk from high-risk workloads during the incident.

That is exactly where a gateway helps. The response should not be binary. You want to answer four separate questions quickly.

  • Which traffic must stop immediately?
  • Which traffic can fail over to an approved backup provider?
  • Which traffic must now satisfy stricter routing guarantees?
  • What evidence do we have about what was blocked, rerouted, or still allowed during the incident window?

If you cannot answer those four questions at runtime, your incident response depends on hope and email.

The solution​

Keeptrusts gives you a containment pattern that maps cleanly to a provider compromise.

First, treat providers as replaceable targets behind the gateway rather than hardcoded dependencies in applications. providers.targets, routing strategy, fallback, and circuit breakers let you move traffic away from a suspect target without changing client code.

Second, make routing governance-aware. Data Routing Policy filters provider targets before selection based on declared data_policy metadata. That matters during a compromise because you may suddenly need to require zero-data retention, no training, in-memory handling, or local-only processing on every remaining target.

Third, harden the request boundary while the incident is active. Prompt Injection Detection does not solve provider compromise by itself, but it prevents attackers from turning the moment of confusion into an input-boundary attack. When trust is already degraded, you want the upstream traffic that still flows to be as narrow and well-formed as possible.

Fourth, keep observability explicit. Audit Logger is an allow-only marker in the chain, but it makes audit logging an active, visible control in the gateway decision stream. Evidence then comes from events, exports, and escalation workflows around that stream. That distinction matters: do not confuse the marker policy with retention enforcement handled elsewhere in the platform.

Finally, use rate limits to protect the backup lane. Compromise events often create retry storms, manual testing spikes, or sudden traffic concentration on a secondary provider. A failover plan without quotas is just a new incident waiting to happen.

Implementation​

This example shows a practical containment configuration: one suspect primary target, one backup target, strict data-routing requirements, explicit prompt-boundary defense, and rate limits to keep the backup lane stable.

pack:
  name: provider-compromise-containment
  version: 1.0.0
  enabled: true

providers:
  routing:
    strategy: ordered
  fallback:
    enabled: true
    triggers:
      - rate_limit
      - server_error
      - timeout
    max_fallback_attempts: 1
  circuit_breaker:
    enabled: true
    consecutive_failure_threshold: 3
    cooldown_seconds: 60
    half_open_successes: 1
  targets:
    - id: suspect-primary
      provider: openai
      model: gpt-5.4-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: false
        training_opt_out: true
        retention_days: 30
        allow_internet_egress: true
        local_only_processing: false
    - id: backup-zdr
      provider: anthropic
      model: claude-sonnet-4-20250514
      secret_key_ref:
        env: ANTHROPIC_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true
        sanitized: true
        accepts_tokenized_input: true
        allow_internet_egress: false
        local_only_processing: true

rate_limits:
  per_team:
    rpm: 120
    tpm: 300000
    max_parallel_requests: 20
  global:
    rpm: 400
    tpm: 900000
    max_parallel_requests: 60

user_rate_limit:
  header: "X-User-Id"
  strategy: sliding_window
  window_seconds: 60

policies:
  chain:
    - prompt-injection
    - data-routing-policy
    - audit-logger

policy:
  prompt-injection:
    use_embedding: true
    detection:
      embedding_threshold: 0.8
      attack_patterns:
        - "ignore.*previous.*instructions"
        - "reveal.*system.*prompt"
        - "print.*hidden.*instructions"
    encoding:
      decode_base64: true
      normalize_unicode: true
      detect_homoglyphs: true
    boundaries:
      enforce_delimiters: true
      reject_fake_boundaries: true

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    require_in_memory_only: true
    allow_internet_egress: false
    local_only_processing: true
    on_no_compliant_provider: block
    log_provider_selection: true

  audit-logger: {}

Two operational details matter here.

The first is that the suspect provider stays visible in configuration until you are ready to remove it entirely, but the policy requirements ensure it is excluded from compliant traffic. That gives responders a controlled transition instead of an all-or-nothing cutover.

The second is that the backup target is not just "another provider." It is a provider that meets the stricter requirements you care about during the incident. That is the difference between failover and safe failover.

After you deploy the containment config, validate the live decision stream immediately:

kt policy lint --file policy-config.yaml
kt events tail --since 15m --json

The point of that check is not only to confirm that requests still flow. It is to confirm that the right requests flow, the suspect provider is being excluded, and the reason codes make sense.

Results and impact​

The immediate benefit is containment without blind shutdown. High-risk traffic can be blocked or rerouted while lower-risk traffic continues through a compliant backup lane.

The second benefit is cleaner forensics. Because decisions are still made at the gateway, the event stream gives you a reliable picture of what was blocked, what was rerouted, and when the new configuration took effect. That is much more useful than trying to reconstruct behavior later from scattered application logs.

The third benefit is architectural leverage. Once providers are treated as governed targets instead of embedded dependencies, supply-chain response becomes a configuration and verification task rather than a multi-week emergency refactor.

This is why provider governance is not just an uptime topic. It is a security design choice. The compromise is bad enough on its own. You do not want your response model to make it worse.

Key takeaways​

  • A provider compromise is a trust-boundary incident, not only a service outage.
  • Failover only helps if the backup path still satisfies your routing and data-handling requirements.
  • Keep Prompt Injection Detection active during provider incidents so the remaining traffic lane stays narrow and defensible.
  • Use Audit Logger as the explicit marker that audit visibility is active, then rely on events and exports for evidence.
  • Protect the backup lane with Rate Limits so incident-driven traffic spikes do not create a second failure.

Next steps​