#467

[Enhancement]: Native PII & Target Masking for Cloud LLMs (via Microsoft Presidio/LiteLLM Integration)

OpenDEVisionsopened 17d ago

Target Component

External Integrations (LLM/Search APIs)

Enhancement Description

Is your feature request related to a problem? Please describe.

Currently, PentAGI supports powerful enterprise observability features using Langfuse, ClickHouse, Redis, and MinIO. However, when operators configure PentAGI to use commercial cloud-based LLMs (such as OpenAI/Anthropic, or GLM5.3 from providers such as OpenRouter) instead of local deployments, sensitive operational data is sent in cleartext. This includes target IP addresses, client domains, internal subnets, credentials, and potential PII extracted during the exploitation phase. In professional environments, sending this sensitive threat intelligence to external cloud providers violates strict privacy policies and NDA constraints with clients.

Describe the solution you'd like

A native PII/Target Anonymization and Masking feature built directly into PentAGI's LLM client layer. Since PentAGI already utilizes LiteLLM architectures/parses for LLM abstraction, it would be highly beneficial to introduce a toggleable middleware layer capable of intercepting prompts before they leave the environment.

Ideally, this could be driven by environment variables in the .env file, leveraging a lightweight local microservice like Microsoft Presidio (Analyzer/Anonymizer) or native LiteLLM guardrail configurations:

  1. Pre-call (In-Flight Masking): PentAGI masks sensitive data (IPs, URLs, Domains, PII) with placeholder tokens (e.g., ANONYMOUS_TARGET_1) before sending the prompt to the cloud LLM.
  2. Post-call (Unmasking): Upon receiving the response, PentAGI automatically map-replaces the placeholders back to the real operational data before handing the text over to the autonomous agents and local logging stacks.

Describe alternatives you've considered

Local LLMs (Ollama/vLLM): While fully air-gapped local setups solve the privacy issue, complex multi-agent reasoning chains still heavily benefit from the advanced cognitive capabilities of frontier cloud models. External LLM Gateways: Setting up an independent LiteLLM Proxy container with Presidio plugins in front of PentAGI works, but it complicates the infrastructure setup for users and creates potential synchronization issues with data passing to Langfuse and local memory graphs.

Additional context

Integrating this directly into the Go core or via the pre-existing container ecosystem would close a massive gap between open-source agentic pentesting and commercial alternatives (like Darkmoon or NodeZero), making PentAGI fully production-ready for strict corporate security assessments.

Technical Details

No response

Designs and Mockups

No response

Alternative Solutions

No response

Verification

  • I have checked that this enhancement hasn't been already proposed
  • This enhancement aligns with PentAGI's goal of autonomous penetration testing
  • I have considered the security implications of this enhancement
  • I have provided clear use cases and benefits

Activity

1
XinwangTao16d ago

Strong +1 for this. Masking before prompts leave the environment is exactly what enterprise deployments need when cloud LLMs are required, and doing it natively in the client layer beats a separate LiteLLM proxy for keeping Langfuse/local storage consistent.

A few suggestions on top of the proposal:

  1. The mask/unmask layer should also cover the Langfuse trace and local logging pipeline end-to-end — otherwise responses get unmasked for agents while masked placeholders leak into traces, recreating the sync problem you mentioned with the external proxy alternative.
  2. Consider configurable anonymizer rules (IP/CIDR, domains, regex) so legitimate content like test fixtures or documentation examples isn't masked by default.
  3. Keep a per-conversation token map for placeholder stability across multi-turn agent loops; the same target should map to the same placeholder in every turn, or the model may lose the association.
  4. Masking at the client layer is also a nice observability win: local storage stays in original form while only the external call is anonymized, which fits NDA-driven workflows well.