CipherShield

Redact, vault, and policy-gate every prompt before it reaches an LLM. Fail-closed secret isolation with AES-256-GCM — measured 0/11 leakage on our test corpus.

Comment

🛡️ CipherShield AI

💡 Inspiration

Security teams, DevOps engineers, and developers face a massive dilemma today: AI models like Claude, GPT-4, and local LLMs are incredibly useful for incident triage, log analysis, and root-cause investigation. However, incident logs, stack traces, and API dumps often contain sensitive operational information, including production API tokens, private IP addresses, database credentials, and encryption keys.

Sending raw text directly to cloud LLM providers presents serious security and compliance risks, including accidental credential leakage.

CipherShield AI addresses this trade-off with a local-first, secret-isolating gateway that enables engineers to leverage AI-powered analysis without transmitting their original credentials, secret mappings, or sensitive identities to external LLM providers.

🛡️ What It Does

CipherShield AI acts as a security boundary between your workstation and external LLM providers.

1. Pre-Flight Secret Detection and Tokenization

Scans incident reports, logs, and API dumps using modular pattern detectors for:

  • api_token
  • bearer_token
  • password_kv
  • email
  • ipv4

Sensitive values are replaced with stable placeholders, such as [SECRET_01] and [IP_01], before requests leave the local environment.

2. Encrypted Local Vault

Secret-to-placeholder mappings are encrypted at rest using AES-256-GCM.

The vault encryption key and original secret mappings remain within the local backend and are never intentionally transmitted to the LLM provider.

The authenticated encryption operation is expressed as:

$$ (C,T)=\operatorname{AES\text{-}GCM}_{K}(N,P,A) $$

where:

  • (K) is the 256-bit encryption key.
  • (N) is a unique nonce.
  • (P) is the plaintext.
  • (A) is optional authenticated additional data.
  • (C) is the resulting ciphertext.
  • (T) is the authentication tag.

Decryption succeeds only if authentication is valid:

$$ P=\operatorname{Dec}_{K}(N,C,A,T) $$

If authentication fails, the application rejects the record instead of accepting tampered data.

3. Fail-Closed Outbound Policy Gate

Before transmission, CipherShield inspects the final serialized JSON payload intended for the LLM.

Let (x) represent an outbound request and (P(x)) represent the configured security policy. The transmission decision is:

$$ \operatorname{Allow}(x)= \begin{cases} 1, & \text{if } P(x)=\text{PASS}\ 0, & \text{otherwise} \end{cases} $$

If the request contains detectable secrets, forbidden content, or prohibited tool calls, it is blocked. If the policy gate cannot validate the request, transmission is denied.

4. Bidirectional Response Inspection

CipherShield scans LLM responses before rendering them in the UI to detect whether known secrets have been echoed or exposed.

The response-handling rule is:

$$ \operatorname{Render}(y)= \begin{cases} 1, & \text{if } S(y)=\text{PASS}\ 0, & \text{otherwise} \end{cases} $$

where (y) is the model response and (S(y)) is the response security inspection result.

This mechanism helps detect known-secret leakage but cannot guarantee detection of every possible reconstruction or disclosure.

5. Controlled and Audited Restoration

Placeholder restoration is disabled by default. An authorized analyst can explicitly restore placeholders in the local environment when necessary.

Restoration requires authorization and generates an audit event according to the configured policy.

6. Interactive Security Lab

The Security Lab allows judges and security auditors to test defenses against:

  • Prompt injection
  • Secret extraction attempts
  • Forbidden-category requests
  • Tampered ciphertext
  • Malicious response echoing

The lab demonstrates the gateway's behavior under adversarial conditions.

⚙️ How We Built It

Backend Engine

  • Modular architecture separating detection, tokenization, cryptographic vaulting, provider adapters, and policy enforcement.
  • Pydantic v2 request and response validation.
  • Configurable input-size limits through MAX_INPUT_CHARS.
  • Final-payload inspection immediately before HTTP transport dispatch.

Cryptographic Vault

The vault uses the Python cryptography library to implement AES-256-GCM authenticated encryption.

The key size is:

$$ |K|=256\text{ bits} $$

The corresponding key length in bytes is:

$$ \frac{256}{8}=32\text{ bytes} $$

A unique nonce must be used for each encryption operation under the same key. Authentication failure causes decryption to be rejected.

LLM Integration Layer

  • Provider-agnostic HTTP client compatible with OpenAI-style APIs.
  • Strict request timeouts and bounded output handling.
  • Transport-level security hooks.
  • Deterministic mock provider for offline demonstrations, testing, and CI without API keys.

Frontend Dashboard

Built with Next.js 14, TypeScript, and Tailwind CSS, the dashboard includes:

  • Overview: Security status and evaluation summaries.
  • Analyze: Redaction previews and outbound payload inspection.
  • Security Lab: Interactive adversarial security scenarios.
  • Vault: Local vault and protected mapping management.
  • Evaluation Dashboard: Security test results and performance metrics.

The frontend does not receive provider API keys or raw vault encryption keys.

All-in-One Docker Deployment

  • Multi-stage container build.
  • tini as the container's init process.
  • Process supervision for the frontend/reverse proxy and FastAPI backend.
  • Non-root execution to reduce container-level privileges.

🔬 Measured Evaluation and Results

The automated evaluation suite, scripts/run_security_eval.py, was tested against an adversarial corpus of 18 documents.

Metric Reported Result
Known-secret leakage in outbound payloads 0 out of 11
Forbidden requests blocked 2 out of 2
Adversarial attack attempts neutralized 12 out of 12
False-positive rate on benign operational text 0.0%
Local preprocessing latency, P50 0.34 ms
Local preprocessing latency, P95 0.66 ms
Automated tests passed 116

Secret Leakage Rate

The observed leakage rate is calculated as:

$$ R_{\text{leak}}= \frac{N_{\text{leaked}}} {N_{\text{known secrets tested}}} \times100\% $$

For the reported evaluation:

$$ R_{\text{leak}}=\frac{0}{11}\times100\%=0\% $$

This result applies only to the tested secrets and outbound payloads. It is not proof of universal resistance to secret leakage.

Forbidden Request Blocking Rate

$$ R_{\text{block}}= \frac{N_{\text{blocked forbidden requests}}} {N_{\text{forbidden requests tested}}} \times100\% $$

For the reported evaluation:

$$ R_{\text{block}}=\frac{2}{2}\times100\%=100\% $$

These metrics describe the current evaluation suite and its tested scenarios, not a guarantee against all possible attacks.

🧗 Challenges We Faced

1. Inspecting the Exact Outbound Payload

Inspecting Python dictionaries or Pydantic models alone can leave room for serialization differences, transformations, or unexpected fields to bypass earlier checks.

We addressed this by inspecting the final serialized request immediately before HTTP transport dispatch.

2. Deterministic Tokenization

Replacing repeated occurrences of the same IP address or token with different placeholders can make incident analysis confusing.

We implemented deterministic, document-scoped tokenization so that repeated occurrences of 192.168.1.1 consistently map to [IP_01].

This preserves relationships between events while withholding the original IP address from the remote model.

3. Bidirectional Threat Modeling

Protecting outbound prompts is only half the problem. An LLM can respond to adversarial instructions by echoing secrets or producing sensitive information in unexpected formats.

We introduced response inspection before content reaches the UI, adding a second security boundary for detecting known-secret leakage.

4. Honest Security Claims

Local encryption and secret tokenization are not equivalent to encrypted inference or homomorphic encryption.

CipherShield AI is a local secret-isolating gateway. The remote LLM receives readable, sanitized text, while the original secret mappings and vault encryption key remain local.

Its security depends on detection coverage, policy enforcement, key management, and deployment configuration.

🏆 Accomplishments We're Proud Of

Zero-Setup Demonstration

Users can launch and explore the application through Docker without an OpenAI API key or external internet connection, thanks to the deterministic mock provider.

Interactive Security Lab

Evaluators can attempt prompt injections, corrupt ciphertexts, and observe how the system responds to policy violations.

Defense-in-Depth Security

The project documents its threat model, key lifecycle requirements, policy enforcement boundaries, and security tests, linking implementation requirements to automated verification.

Provider-Agnostic Architecture

The LLM integration layer supports OpenAI-compatible APIs, allowing different compatible providers to be integrated without coupling the core security architecture to one vendor.

🚀 What's Next for CipherShield AI?

1. Local Embeddings and ML-Based Detection

Extend regex-based detection with lightweight, on-device transformer models and tools such as DeBERTa and Microsoft Presidio to improve the detection of sensitive named entities, proprietary identifiers, and internal code names.

2. Enterprise Key Management

Integrate with HashiCorp Vault, AWS KMS, and Azure Key Vault to support centralized key policies, secure key rotation, and stronger key isolation.

3. CLI and Shell Proxy

Build a lightweight terminal proxy that integrates with developer workflows and AI-assisted tools, including workflows involving curl, kubectl, and other command-line utilities.

4. Streaming Tokenization

Support real-time tokenization and detokenization for streaming LLM completions delivered through Server-Sent Events (SSE), ensuring that streamed responses pass the appropriate security checks.

5. Stronger Adversarial Evaluation

Expand the security corpus and introduce broader red-team testing, including encoding-based secret evasion, Unicode normalization, partial-secret reconstruction, and provider-specific serialization edge cases.

6. Enterprise-Grade Auditability

Add structured security audit logs, configurable retention policies, role-based access control, and stronger operational monitoring without unnecessarily retaining sensitive plaintext.

🔐 Our Mission

CipherShield AI makes AI-assisted incident response safer by keeping sensitive operational secrets under local control.

Our goal is to help developers, DevOps engineers, and security teams benefit from modern AI while maintaining a clear security boundary between private infrastructure and external AI services.

Built With

  • aes-256-gcm
  • ai-gateway
  • cryptography
  • cyber-security
  • dlp
  • docker
  • docker-compose
  • fastapi
  • incident-response
  • llm-security
  • next.js
  • privacy-preserving-ai
  • prompt-injection-defense
  • pydantic
  • pytest
  • python
  • rest-api
  • reverse-proxy
  • security
  • sqlite
  • tailwindcss
  • typescript
  • vitest
  • zero-trust
Share this project:

Updates

Submission history