Secure60 AI Protector

Overview

Secure60 AI Protector is a Secure60-managed gateway that enforces guardrails for every upstream LLM backend. Requests flow through Secure60 routing, trigger policy-managed PII/secrets/jailbreak evaluations, and emit a structured audit trail ([s60_audit] JSON) to stdout and Secure60 observability endpoints.

Key Capabilities

Configurable routing — Map ports, URI prefixes, and the X-S60-Backend header to named backends defined in protector.conf.
Policy profiles — Assign each backend a profile that determines enforcement mode and filters for PII, secrets, and jailbreak checks.
PII detection + masking — Block or mask sensitive entities such as PERSON, EMAIL_ADDRESS, and PHONE_NUMBER before they reach the backend or leave the response.
Secrets & jailbreak controls — Keyword heuristics (secret_token, password) and jailbreak phrase monitoring/blocking operate as part of each profile.
Audit trail tracking — Secure60 logging emits [s60_audit] JSON events with decisions, violations, metadata, and optionally forwards them to logging.secure60_endpoint.
Production Hardened Image — The production Dockerfile compiles the Python package into native modules so only compiled artifacts ship in the final image.

Running Secure60 AI Protector

Build and push the production image, then run it with your configs and TLS certs mounted. The image already contains compiled guardrail modules plus the NLP model, so it can start immediately in production environments.

docker buildx build \
  --platform linux/amd64 \
  -f ./Dockerfile \
  -t secure60/s60-ai-protector:1.05 .
docker push secure60/s60-ai-protector:1.05

docker run --rm \
  -p 80:80 \
  -p 443:443 \
  -p 9001:9001 \
  -p 9002:9002 \
  -p 9003:9003 \
  -v "$(pwd)/protector.conf:/etc/s60-protector/protector.conf:ro" \
  -v "$(pwd)/lua-conf:/usr/local/openresty/nginx/conf:ro" \
  -v "$(pwd)/tls-certificates:/usr/local/openresty/nginx:ro" \
  --name s60-ai-protector \
  secure60/s60-ai-protector:1.05

Docker Compose (optional)

services:
  s60-ai-protector:
    image: secure60/s60-ai-protector:1.05
    ports:
      - "80:80"
      - "443:443"
      - "9001:9001"
      - "9002:9002"
      - "9003:9003"
    volumes:
      - ./protector.conf:/etc/s60-protector/protector.conf:ro
      - ./lua-conf:/usr/local/openresty/nginx/conf:ro
      - ./tls-certificates:/usr/local/openresty/nginx:ro

Configuration Reference (`protector.conf`)

`backends`

Name	URL	Profile
`openai`	`https://api.openai.com`	`default-profile`
`anthropic`	`https://api.anthropic.com`	`default-profile`
`mcp-prod`	`http://mcp-service:8001`	`default-profile`
`rag-search`	`http://rag-service:9000`	`default-profile`
`test-llm`	`http://127.0.0.1:5005/test-backend`	`default-profile`
`test-llm-no-email`	`http://127.0.0.1:5005/test-backend`	`no-email-profile`

`routing`

Field	Purpose
`ports`	Map listener ports (`9001`, `9002`, `9003`) to backend names.
`uri_prefix`	URI prefix (e.g., `/proxy`) used for URI-based routing.
`header`	Header name (`X-S60-Backend`) whose value overrides port/URI routing.

`logging`

Field	Description
`secure60_endpoint`	HTTPS endpoint (e.g., `https://110.232.117.100/ingest`) that receives `[s60_audit]` JSON events.

`policy.profiles`

Each profile defines a policy pipeline:

type: usually llm.
enforcement_mode: protect to block traffic, monitor to log only.
input.filters: pii (with mode, entities, score_threshold), secrets, and jailbreak controls.
output.filters: typically used to mask sensitive backend responses.

Profile	Enforcement	Highlights
`default-profile`	`monitor`	Blocks `PERSON`, `EMAIL_ADDRESS`, `PHONE_NUMBER`, blocks secrets/jailbreaks, output filters disabled.
`no-email-profile`	`protect`	Blocks inbound emails/secrets, monitors jailbreak heuristics, masks outbound `EMAIL_ADDRESS`.

When pii.mode is mask, the guardian pipeline anonymizes data instead of blocking. secrets.mode=block uses keyword scanning for secret_token/password, while jailbreak.mode can be block or monitor depending on your tolerance.

Audit Trail & Observability

Secure60 AI Protector emits [s60_audit] JSON for every guardrail evaluation and ships it to stdout and the configured ingestion endpoint. Each entry includes:

event_guardrail_decision, event_guardrail_profile, event_guardrail_mode
violations, violation_types, data_risk_score
HTTP metadata (method, uri, backend, client_ip, server_ip)

Encoded headers (X-S60-*) accompany responses so downstream systems can adapt to the active decision path.

Smoke Tests

curl -k https://localhost:446/proxy/test-llm/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"test","messages":[{"role":"user","content":"Hello Secure60"}]}'

curl -k https://localhost:446/proxy/test-llm-no-email/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"test","messages":[{"role":"user","content":"My email is john.doe@example.com"}]}'

The second request should trigger the no-email-profile and be blocked or masked, which you can see in the audit logs.

Best Practices

Assign profiles to each backend based on sensitivity (PII-heavy vs. general).
Consume [s60_audit] logs through Secure60 ingestion for compliance reporting.
Deploy only the production image in customer environments; dev builds are internal-only.
Bump image tags sequentially (1.05 → 1.06) and keep protector.conf, lua-conf, and certs under config management.