didericis/bot-bottle
1
0
Fork 0
Code Issues 3 Pull Requests 3 Actions 25 Packages Projects Releases Wiki Activity

docs: research on DLP alternatives to pipelock #192

Merged
didericis merged 4 commits from research/dlp-alternatives into main 2026-06-04 14:27:32 -04:00
Conversation 2 Commits 4 Files Changed 1
+505
didericis-claude commented 2026-06-04 13:21:55 -04:00
Collaborator
Copy Link
Copy Source

Investigates replacing pipelock with a custom mitmproxy-based DLP addon that supports per-route configuration and response-specific rules.

docs/research/dlp-alternatives-to-pipelock.md

Summary

Pipelock lacks support for per-route response scanning rules, making it impossible to skip DLP scanning for large binary downloads while keeping scanning for other traffic. This research document proposes building a custom mitmproxy addon that:

  • Supports per-route DLP configuration (aligned with bot-bottle design)
  • Handles response-specific rules (skip scanning for .whl files, etc.)
  • Reduces sidecar count (consolidate into egress proxy)
  • Focuses on AI-specific threats (tokens, prompt injection)

Recommendation

Build the mitmproxy addon in three phases:

  1. MVP: Token detector + entropy checker
  2. Prompt injection detection
  3. Hardening and optimizations

See document for detailed analysis, tradeoffs, and implementation plan.

Investigates replacing pipelock with a custom mitmproxy-based DLP addon that supports per-route configuration and response-specific rules. [docs/research/dlp-alternatives-to-pipelock.md](https://gitea.dideric.is/didericis/bot-bottle/src/commit/c94a2542bdab58097e90317e92ba266bc29fe86f/docs/research/dlp-alternatives-to-pipelock.md) ## Summary Pipelock lacks support for per-route response scanning rules, making it impossible to skip DLP scanning for large binary downloads while keeping scanning for other traffic. This research document proposes building a custom mitmproxy addon that: - Supports per-route DLP configuration (aligned with bot-bottle design) - Handles response-specific rules (skip scanning for .whl files, etc.) - Reduces sidecar count (consolidate into egress proxy) - Focuses on AI-specific threats (tokens, prompt injection) ## Recommendation Build the mitmproxy addon in three phases: 1. MVP: Token detector + entropy checker 2. Prompt injection detection 3. Hardening and optimizations See document for detailed analysis, tradeoffs, and implementation plan.
didericis-claude added 1 commit 2026-06-04 13:21:56 -04:00
docs: research document on DLP alternatives to pipelock
test / unit (pull_request) Successful in 36s
Details
test / integration (pull_request) Successful in 47s
Details
d3c2d9e8f6 
Investigates replacing pipelock with a custom mitmproxy-based DLP addon
that supports per-route configuration, response-specific rules, and
AI-specific threat detection (tokens, prompt injection).

Recommends building the addon in-repo to align with bot-bottle's
per-route design model and keep security logic auditable.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
didericis commented 2026-06-04 13:41:24 -04:00
Owner
Copy Link
Copy Source

Ok, let's go with custom addon for mitmproxy. We'll have two phases:

Phase 1 - Secret Exfiltration

  1. Scan all packet responses by default
  • Can be disabled per route
  1. Scan for the following patterns:
  • Token patterns
  • Different encodings of the secrets that we pass to cred-proxy
egress:
  routes:
    - host: api.anthropic.com
      dlp:
        outbound_detectors: [tokens_patterns, known_secrets] # default/same as if you didn't pass dlp
    - host: github.com
    - host: internal-service.corp
      dlp:
        outbound_detectors: false

Phase 2 - Prompt Injection Protection

  1. Scan all incoming packet responses by default
  • Can be disabled per route
  1. Do a naive scan for prompt injection attacks
egress:
  routes:
    - host: api.anthropic.com
      dlp:
        outbound_detectors: [tokens_patterns, known_secrets]
        inbound_detectors: false
    - host: github.com
       dlp:
         inbound_detectors: [naive_injection_detection] # default/same as if you didn't pass dlp
    - host: internal-service.corp
      dlp:
        outbound_detectors: false
        inbound_detectors: false
Ok, let's go with custom addon for mitmproxy. We'll have two phases: ## Phase 1 - Secret Exfiltration 1. Scan all packet responses by default - Can be disabled per route 2. Scan for the following patterns: - Token patterns - Different encodings of the secrets that we pass to cred-proxy ```yaml egress: routes: - host: api.anthropic.com dlp: outbound_detectors: [tokens_patterns, known_secrets] # default/same as if you didn't pass dlp - host: github.com - host: internal-service.corp dlp: outbound_detectors: false ``` ## Phase 2 - Prompt Injection Protection 1. Scan all incoming packet responses by default - Can be disabled per route 2. Do a naive scan for prompt injection attacks ```yaml egress: routes: - host: api.anthropic.com dlp: outbound_detectors: [tokens_patterns, known_secrets] inbound_detectors: false - host: github.com dlp: inbound_detectors: [naive_injection_detection] # default/same as if you didn't pass dlp - host: internal-service.corp dlp: outbound_detectors: false inbound_detectors: false ```
didericis added 1 commit 2026-06-04 13:57:26 -04:00
docs: accommodate PR feedback on detector architecture
test / unit (pull_request) Successful in 42s
Details
test / integration (pull_request) Successful in 50s
Details
49f77f2d1e 
Per feedback from PR 192:

- Restructure around outbound_detectors (requests to upstream) and
  inbound_detectors (responses from upstream)
- Rename to 'secret exfiltration' detection for Phase 1
- Add 'known_secrets' detector for provisioned credentials
- Make scanning enabled by default per detector type
- Clarify that multiple encodings of secrets should be checked

Phase 1 now focuses on preventing outbound credential leaks.
Phase 2 handles inbound prompt injection attacks.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
didericis added 1 commit 2026-06-04 14:03:11 -04:00
docs: remove time estimates and add LLM-based detection analysis
test / unit (pull_request) Successful in 35s
Details
test / integration (pull_request) Successful in 45s
Details
e6b3cd1824 
- Remove all time estimates (2-3 weeks, 1-2 weeks, etc.)
- Add detailed analysis of using LLM for prompt injection detection
- Survey existing models (none purpose-built for this)
- Sketch DistilBERT fine-tuning approach (~67MB quantized)
- Analyze latency/footprint tradeoffs (50-150ms vs. <5ms for patterns)
- Recommend pattern-based Phase 2, with LLM as optional Phase 2b
- Include code sketch of LLM detector with timeout fallback
- List open questions for LLM deployment

Conclusion: Patterns are faster/simpler for now; LLM only if patterns
miss sophisticated attacks in production.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
didericis added 1 commit 2026-06-04 14:14:38 -04:00
docs: evaluate CaMeL prompt injection framework for integration
test / unit (pull_request) Successful in 34s
Details
test / integration (pull_request) Successful in 43s
Details
test / unit (push) Successful in 36s
Details
test / integration (push) Successful in 54s
Details
c94a2542bd 
Add analysis of Google DeepMind's CaMeL (arXiv:2503.18813), which
prevents prompt injections architecturally rather than detecting them.

Key findings:
- CaMeL operates at the agent execution layer (P-LLM/Q-LLM split +
  capability-based data flow tracking), not the network layer
- Not a replacement for pipelock/DLP — different threat surface
- Not viable today: research artifact, requires agent rearchitecture,
  doubles LLM costs, 7% utility loss on AgentDojo
- Worth watching: its capability model could complement bot-bottle's
  network controls if it matures into production software

Also clarifies pipelock's actual detection capabilities (no prompt
injection detection) and adds naive detector sketch.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
didericis commented 2026-06-04 14:27:22 -04:00
Owner
Copy Link
Copy Source

Will do the following in 4 follow up PRs:

  1. Strip out pipelock
  2. Do phase I part 1 (token detection)
  3. Do phase I part 2 (known secret detection)
  4. Do phase II (naive prompt injection detection)
Will do the following in 4 follow up PRs: 1. Strip out pipelock 2. Do phase I part 1 (token detection) 3. Do phase I part 2 (known secret detection) 4. Do phase II (naive prompt injection detection)
didericis merged commit c94a2542bd into main 2026-06-04 14:27:32 -04:00
didericis deleted branch research/dlp-alternatives 2026-06-04 14:27:32 -04:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
didericis-claude (didericis (claude)) didericis-codex (didericis (codex)) didericis-gemma (gemma) didericis
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: didericis/bot-bottle#192
Delete Branch "research/dlp-alternatives"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?