Direct Access

Direct access is the default path through the Sidecar. A request arrives, the Sidecar decodes it, evaluates it against the rules you wrote, and forwards it. The response comes back through the same gate and sensitive values are rewritten before they reach the client. Nothing about this path is probabilistic. The same statement produces the same decision every time, there is no third-party API in the chain, and the only latency added is a parse and a scan.

Configuration

A listener is one upstream. Add policy to control what reaches the resource, and mask to control what comes back. Both are optional and independent.

config.yaml

pii:
  entities: [EMAIL_ADDRESS, US_SSN]

listeners:
  - name: appdb
    protocol: postgres          # postgres | mssql | http
    listen: 127.0.0.1:15432
    upstream: appdb:5432
    connection: appdb

    policy:
      enforce: true
      rules:
        - name: no-destructive-sql
          type: operation
          operations: [drop, delete, truncate]
          message: destructive statements are not permitted on appdb

    mask:
      enabled: true
      rules:
        - {name: emails, entity: EMAIL_ADDRESS, strategy: redact}

Validate before deploying — nothing needs to be running:

hoop start sidecar --config config.yaml --validate

config OK: 1 listener(s)
  appdb            postgres  enforcing 1 rule(s) + masking

policy.enforce defaults to false. Without it a listener inspects and audits but denies nothing, so a misconfigured rule cannot take production down on first deploy. That is the right way to roll out, and the wrong way to leave it.

What the user sees when a rule denies

The refusal is written in the protocol’s own frame, always to the client, carrying the message you wrote:

PGSSLMODE=disable psql -h 127.0.0.1 -p 15432 -U appuser -d appdb \
  -c 'DELETE FROM customers WHERE id = 1;'

FATAL:  destructive statements are not permitted on appdb

That is a real pgwire ErrorResponse, so the developer reads the reason in psql rather than watching a connection drop. On an HTTP listener the equivalent is a 403 with an X-Hoop-Denied header.

Direct or Agentic?

Both paths run in the same Sidecar and a listener picks per rule, so this is not an either/or for the deployment — only for a given class of statement.

	Direct Access	Agentic Access
Decides with	rules you wrote	a language model classifying the statement
Determinism	same input, same verdict	a classification, with a cache
Latency added	parse and scan	a model call, roughly 100 ms to 2 s uncached
External dependency	none	your model provider
Failure mode	fails closed	fails open by default
Best for	effects you can name — destructive verbs, protected tables, forbidden paths	intent you cannot enumerate in advance

The usual shape is direct rules for everything nameable, and an ai_analysis rule as the backstop for the rest.

Guardrails

Every rule type, and how a rule set resolves to a verdict.

Data Masking

Detection, masking strategies, and entity rules versus column rules.

Agentic Access

Let a model classify the statement and pick the tool.

Config File Reference

Every listener field, inheritance between listeners, and what startup refuses.

Getting Started

Core Concepts

Features

Control Plane Setup

Sidecar Reference

Configuration

What the user sees when a rule denies

Direct or Agentic?

Next

Guardrails

Data Masking

Agentic Access

Config File Reference

​Configuration

​What the user sees when a rule denies

​Direct or Agentic?

​Next

Guardrails

Data Masking

Agentic Access

Config File Reference

Configuration

What the user sees when a rule denies

Direct or Agentic?

Next