Run on a server

The Compose setup publishes the API on 127.0.0.1 by default and the API has no login of its own unless you set an API key. The settings below control network binding, database password, API-key auth and webhook/approval hardening. They come straight from .env.example.

Docker Compose security defaults

Postgres password for the db, app, voice and worker containers. It only applies when the database volume is first created; to change an existing database also run ALTER USER ragleap WITH PASSWORD '...'. Use letters and digits only (it goes into a URL).

# POSTGRES_PASSWORD=

The API is published on 127.0.0.1 by default. Use 0.0.0.0 only behind a firewall or reverse proxy that adds authentication: the API has no login of its own yet.

# APP_BIND=127.0.0.1

Webhook and approval hardening

Telegram: set a secret and register the SAME value as secret_token when calling setWebhook. Without it, webhook requests are now rejected (403).

# TELEGRAM_WEBHOOK_SECRET=

WhatsApp (Twilio): requests without a valid X-Twilio-Signature are rejected (needs TWILIO_AUTH_TOKEN). Local testing only - accept unsigned webhook requests (logs a warning each time):

# TELEGRAM_ALLOW_UNSIGNED=true
# WHATSAPP_ALLOW_UNSIGNED=true

YES/NO approvals are accepted ONLY from the configured owner: the sender must match approval_channel + approval_target set via POST /autonomy.

Optional API-key auth for core/api.py

Unset by default: the API has NO authentication (fine for 127.0.0.1-only access, dangerous if this port is ever reachable beyond localhost). When set, every endpoint except /health and /webhook/* (which verify platform signatures themselves) requires header: X-API-Key: <this value>

# RAGLEAP_API_KEY=

Security policy

Supported Versions

ragleap-rag is under active development. Security fixes are made against the latest published PyPI release only. There is no long-term-support branch at this stage of the project.

Reporting a Vulnerability

Please do not open a public GitHub issue for security vulnerabilities.

Instead, report it privately using one of these methods:

1. GitHub Security Advisories (preferred): open a private report via github.com/antonyrag/ragleap-core/security/advisories/new
2. Email: send details to the address listed on the maintainer's GitHub profile (@antonyrag).

Please include:

• A description of the vulnerability and its potential impact
• Steps to reproduce, or a minimal proof-of-concept
• The affected version(s) of ragleap-rag

What to Expect

This is a solo-maintained open-source project — there is no dedicated security team and no formal SLA. That said, here's the realistic process:

• You'll get an acknowledgment as soon as the maintainer sees the report (typically within a few days).
• If confirmed, a fix will be prioritized over other roadmap work and shipped as a patch release, with the version noted in CHANGELOG.md.
• Credit is given to the reporter in the release notes, unless you'd prefer to stay anonymous — just say so in your report.
• Low-severity issues (e.g. requiring an already-compromised API key, or affecting only local/dev usage with no realistic production exposure) may be fixed on a slower, non-emergency timeline.

Scope

This policy covers the ragleap-rag package itself (packages/ragleap-rag/) and other code in this repository. It does not cover:

• Vulnerabilities in third-party dependencies (please report those upstream — though flagging them here is still welcome so they can be tracked/patched on our side too)
• The separate production ragleap-backend platform, which is a private repository outside this project's scope

Known Limitations (Honest Disclosure)

In the spirit of this project's "verified claims, not marketing claims" standard: ragleap-rag has not undergone a formal third-party security audit. Guardrail hooks (input_guardrails/output_guardrails) are extension points for user-supplied validators — the library does not itself guarantee protection against prompt injection, PII leakage, or malicious document content unless you configure guardrails for your use case.