What is an MCP security proxy? A practical JanuScope example

Where the rules apply

The connection follows three steps:

1. The assistant asks an MCP tool to do something.
2. JanuScope checks the request before forwarding it to the configured server.
3. When the server responds, JanuScope applies the configured result-redaction rules before returning the response to the assistant.

This gives the request and the response separate controls. A policy can permit a useful read, refuse a covered write, or redact a matching value in an allowed response. The homepage illustration shows those three outcomes with sample data.

Example: add JanuScope to a PostgreSQL connection

Start with a working PostgreSQL MCP connection and a database role restricted to the intended access. The bundled postgres-crystaldba Lens uses Postgres MCP Pro in restricted mode and adds proxy checks, matching-value redaction, schema context, and an audit log.

The setup requires Node.js 20 or later and uvx available to the MCP client. In the existing MCP configuration entry, replace its launch fields with:

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "postgres-crystaldba"]
}

This is an excerpt, not a replacement for the whole configuration entry. Keep the existing entry name, DATABASE_URI, and other environment settings. Restart the MCP connection after saving the configuration.

Review the PostgreSQL Lens before using it. Its rules cover specified tools, SQL arguments, field names, and patterns. Adapt those rules to the access and information that the connection should allow.

Add redaction to read-only access

Use read-only permissions to control which operations the connection can perform. Add the PostgreSQL Lens to filter matching sensitive values from the results returned to the assistant.

The PostgreSQL Lens includes matching rules for email addresses and named sensitive fields. Matches are replaced with [REDACTED] before the assistant receives them. Redaction follows the configured field names and value patterns; review those rules for the data you want to filter.

For example, consider this illustrative JSON text returned by a tool:

{
  "order_id": "ORD-1042",
  "email": "[email protected]",
  "status": "paid"
}

The PostgreSQL Lens's email rules replace the matching value before the response reaches the assistant:

{
  "order_id": "ORD-1042",
  "email": "[REDACTED]",
  "status": "paid"
}

The order ID and status remain available for the task. The Lens configuration defines the matching rules and replacement value.

Combine the Lens with database roles, approved column access or reviewed views to control which source fields the connection can read. The sensitive-data guide explains this PostgreSQL setup.

When this approach fits

JanuScope applies a reusable policy to existing MCP connections without modifying the upstream server. Database, filesystem and API tools configured through JanuScope use the controls defined in their Lens. Direct calls to the same service outside those connections use the service's own permissions.

Policy checks and result redaction run locally. A remote database or API receives the allowed requests your configured MCP server sends to it. Your AI client receives results after JanuScope applies the Lens's redaction rules.

If the client uses a cloud model, it can send those results and tool descriptions to that provider. When schema context is enabled, those descriptions also include table and column information to help the assistant plan its queries. The PostgreSQL Lens enables this context by default.

The PostgreSQL Lens records call outcomes in a local audit file. Apply filesystem permissions appropriate for the data it records. The security model describes how these controls fit together.

Begin with the setup guide and the bundled Lenses. Choose the preset for the tool already in use, review its rules, and keep the underlying service permissions aligned with the intended access.