Skip to main content
← Learning Center
Comparison Guide

Self-Hosted AI vs. API-Based AI: A Security Comparison

Two paths to AI deployment. Two very different security postures. One local desktop tool — Purfect Shield — that protects both by redacting sensitive data before it reaches any model, anywhere.

Architecture at a Glance

API-Based AI

Data leaves your boundary
Your App→Network→Provider API→Provider Server
InfrastructureNone required
Cost ModelPer-token / subscription
Data ResidencyProvider's region
Audit TrailLimited to provider logs

Self-Hosted AI

Data stays on your hardware
Your App→Local Proxy→Your GPU→Your Model
InfrastructureGPU(s) required
Cost ModelUpfront hardware + ops
Data ResidencyYour infrastructure
Audit TrailFull control

Threat Model Comparison

API Risk: High
Self-Hosted Risk: Low
API-Based

Every prompt and response traverses the public internet. While TLS encrypts the connection, the provider's endpoint decrypts and sees the full plaintext. Your ISP, any intermediate network hops, and the provider's infrastructure all touch the encrypted stream. A compromised certificate authority or man-in-the-middle attack at any hop exposes your prompts.

●TLS terminates at provider — plaintext visible to provider
●Network path crosses multiple ISPs and internet exchanges
●Provider may route to different geographic regions
●Certificate transparency logs record your API endpoints
Self-Hosted

Prompts never leave your internal network. Traffic stays within your VPC, private subnet, or even localhost. No third party sees the plaintext, no ISP routing, no certificate authority dependency for the model connection itself.

●Traffic stays within your network boundary
●Can run entirely on localhost for maximum isolation
●You control TLS between app and model server
●No external visibility into which models you're querying

Interactive Decision Matrix

Answer four questions about your organization and get a personalized recommendation on which deployment model fits your security and operational profile.

Team Size & Capacity

How large is your engineering team, and do you have ML ops experience?

Data Sensitivity

What types of data will your AI systems process?

Compliance Requirements

Which compliance frameworks apply to your organization?

Budget & Timeline

What's your budget and deployment timeline?

Security Gaps in Each Approach

Neither approach is perfect. Here are the most common security gaps in each model — and how Shield addresses them regardless of which path you choose.

01
API Gap

The Provider Sees Everything

Every prompt you send to an API provider is visible to their infrastructure in plaintext. Their SOC 2 report certifies their controls — but it doesn't mean your data is invisible to their employees, their logging systems, or a future breach of their platform. This is the fundamental asymmetry of API-based AI: you trust their security for YOUR data.

How Shield handles it: Shield redacts sensitive content locally, before it leaves your machine. The provider receives sanitized prompts — no PII, no secrets, no proprietary code. Even if the provider is breached, your sensitive data was never there to expose.
02
Self-Hosted Gap

Operational Blind Spots

Self-hosted AI keeps data local — but it also localizes your security blind spots. You're responsible for GPU node hardening, model runtime patching, access control, and intrusion detection. Without centralized monitoring, a compromised model or exfiltration attempt can go undetected for months. The data is local — but so is the responsibility to protect it.

How Shield handles it: Shield's tamper-evident hash chain gives you a verifiable audit trail of every redaction event. You can independently verify that no records were altered. Even if your model runtime is compromised, the audit chain tells you exactly what data was processed and when.
03
API Gap

Multi-Provider Sprawl

Most teams don't use one AI provider — they use three or four. Different models for different tasks, each with its own API, its own data retention policy, its own security posture. The attack surface multiplies with each provider you add. Your security is only as strong as the weakest provider in your stack.

How Shield handles it: One local proxy, one configuration, consistent redaction across every provider. Whether you're calling OpenAI, Anthropic, Google, DeepSeek, or a self-hosted model — Shield applies the same filter packs to every request. Add or remove providers without changing your security posture.
04
Self-Hosted Gap

Model Supply Chain Trust

When you download model weights from a hub or registry, you're trusting the provenance of those files. A poisoned model could exfiltrate data through seemingly benign outputs, encode information in token probabilities, or include backdoors that activate on specific inputs. The model runs locally — but you didn't write it, and you can't audit every weight.

How Shield handles it: Defense in depth: even if a model is compromised, Shield redacts sensitive content before the model ever sees it. A poisoned model can't leak what it never received. Combined with output scanning, this creates a two-layer boundary — input sanitization + output validation — that neither API-based nor self-hosted models provide on their own.

Shield Protects Both Paths

Shield is a local desktop application — a single Go binary that runs on your machine and sits between your AI-powered tools and wherever the prompts go. Configure it once with one environment variable. It redacts secrets, PII, and proprietary content before any model — API-based or self-hosted — ever sees your data.

One binary. Zero telemetry.
Runs locally on your machine
One env var to configure
Same rules for all providers
Tamper-evident audit chain
No cloud dependency

Frequently Asked Questions

Not automatically. Self-hosted AI keeps data within your infrastructure, eliminating third-party exposure — but it introduces operational security burdens: you must patch model runtimes, secure GPU nodes, manage access controls, and maintain audit trails yourself. API-based AI offloads infrastructure security to the provider but exposes your prompts and responses to their servers, logging systems, and potentially their training pipelines. The right choice depends on your data sensitivity, team capacity, and compliance requirements. Shield protects both approaches by redacting sensitive content before it reaches any destination — provider API or local model.
Self-hosting directly supports data residency requirements in frameworks like GDPR (Article 44-49 on cross-border transfers), HIPAA (requiring BAAs for any third party that handles PHI), and certain government standards (FedRAMP, ITAR) that mandate data remain within specific geographic or organizational boundaries. However, self-hosting alone doesn't make you compliant — you still need access controls, audit logging, encryption at rest, and documented security policies. Shield's local redaction adds a defense-in-depth layer: even if a self-hosted model is compromised, sensitive data was never present in the prompts it processed.
Yes. Shield operates as a local HTTPS proxy — it intercepts API calls regardless of whether the destination is api.openai.com or localhost:8080 running your own model. Configure Shield with one environment variable (`https_proxy`) and it redacts sensitive content before any prompt reaches any model endpoint. This means you get the same redaction protection whether you're calling a cloud provider, a self-hosted model served via vLLM or llama.cpp, or both simultaneously in a multi-model pipeline.
The assumption that provider security equals your security. Major API providers have strong infrastructure security (SOC 2, ISO 27001), but they still see your prompts in plaintext, log them for safety monitoring, and may use them for service improvement unless you explicitly opt out. The risk isn't the provider being malicious — it's that a provider breach, insider threat, or subpoena exposes YOUR data that you assumed was protected by their certifications. Shield eliminates this gap: the provider never sees the sensitive content, so their security posture becomes irrelevant to your data exposure.
Running production-grade LLMs locally requires GPU infrastructure — typically one or more NVIDIA GPUs with sufficient VRAM. A 7B-parameter model needs roughly 14GB VRAM for full precision inference; quantized versions can run on less. For teams just starting, many use API-based AI while gradually building self-hosting capacity. Shield protects data across this transition — you can start with API providers, add self-hosted models later, and maintain consistent redaction across both, all through the same single environment variable configuration.
Without a proxy like Shield, auditing requires provider-specific logging — and most providers don't give you access to raw prompt logs for privacy reasons. Shield's approach is different: because it runs locally on your machine, it maintains a tamper-evident hash chain of every redaction event. You can verify exactly what was redacted, when, and from which application, without relying on provider audit trails. This hash chain is independently verifiable — you don't need to trust Shield's logs; you can recompute the chain yourself and confirm no records were altered.