faultwall

faultwall  /  how it works

How FaultWall sits between your agents and Postgres.

A proxy runs in your network and speaks the Postgres wire protocol. Agents connect to it with their own key instead of the database password. It applies the rules you set in the FaultWall app to the statements routed through it.

  1. 01Where it runs
  2. 02Connecting an agent
  3. 03What happens to a statement
  4. 04Live today, and next
  5. 05What we're building
  6. 06Fair questions

01  Where it runs

Database traffic stays in your network.

You run the proxy next to your database. The FaultWall app holds agents, keys, rules and decisions. The two talk over a single outbound HTTPS connection that the proxy opens.

YOUR NETWORK
AI agentconnects with its own key
FaultWall proxychecks rules, holds selected writes, blocks the rest
Postgresproxy holds the real password
outbound HTTPS, opened by the proxy
FaultWall appagents, keys, write rules, approvals, activity

DATABASE PATH

Agent to proxy to Postgres. Both connections stay inside your network. Your agent code doesn't change, only its connection string.

CONTROL PATH

The proxy pulls rules and sends held writes for review. In v0.7.0 reviewers see the statement shape, like UPDATE orders SET status = ? WHERE id = ?, not the values.

02  Connecting an agent

Swap one connection string.

# before: the agent holds the database password
postgres://app_user:<db-password>@db.internal/orders

# after: the agent holds only its FaultWall key
postgres://support-agent:<agent-key>@fw-proxy/orders

# check what each agent's DB user can do today
$ faultwall audit --fix
  1. Create the agent in the app. You get a key, shown once. Revoke it any time and the proxy refuses the next connection.
  2. Set its write rules. Allow, block, or hold for review, per agent.
  3. Point the agent at the proxy. Tested with psycopg2, psycopg3, SQLAlchemy, asyncpg and node-postgres. JDBC is not tested yet.
  4. Tighten the database side too. faultwall audit --fix generates the native Postgres privileges for each agent and lists the rules Postgres can't enforce on its own.

03  What happens to a statement

Five outcomes, all from our v0.7.0 test run.

Each result below was checked with a direct read of Postgres, so "unchanged" means the row really didn't change. Synthetic database.


      

    

  


  

    
04  Live today, and next

    
What you can use now, and what we're building with design partners.

    

      
LIVE IN v0.7.0
    
        
  • Per-agent keys, issued in the app, revocable
    • 
        
  • Write rules in the app: allow, block, or hold for review
    • 
        
  • Held writes wait at the proxy until approved or denied
    • 
        
  • Activity view of what each agent ran and what was decided
    • 
        
  • Blocked operations refused at the proxy
    • 
        
  • faultwall audit --fix for native per-agent privileges
    • 
      

      
    

  


  

    
05  What we're building

    
Two pieces past allow and deny, built with design partners.

    
Rules answer whether an agent may run a statement. These answer what it will do to the database, and what happens outside the proxy. We're building both with design partners on real workloads.

    

      

        
Query world model
SHADOW MODE

        
Is this query allowed is one question. Will it slow production down right now is another.

        
    
          
  • Learns each query shape's own latency on a quiet database, from what it has actually observed, not the planner's estimate.
    • 
          
  • Samples live load from pg_stat_activity about once a second, off the query path.
    • 
          
  • Predicts latency under that load and flags queries likely to breach your latency target.
    • 
        

        

          
db load30%

          
predicted42ms

          
target

          
SELECT ... FROM orders JOIN ...ok

        

        
Today: the scorer is in the proxy in shadow mode. It scores and records, and never blocks. We're tuning it on real workloads before it acts on anything. Illustration above, not partner data.

      

      

        
eBPF visibility
PROTOTYPE

        
The proxy sees what goes through it. eBPF sees what Postgres actually runs.

        
    
          
  • Hooks Postgres query start and finish with USDT probes, below the application.
    • 
          
  • Attributes CPU and disk I/O to each query using kernel scheduler and block I/O tracepoints.
    • 
          
  • Catches queries on connections that never touched the proxy.
    • 
        

        

          
agent → faultwall proxysees routed traffic

          
postgresUSDT probes

          
linux kernel, eBPFevery query, cpu, i/o

        

        
Today: working prototype, not shipped. Needs self-managed Postgres on Linux; managed services like RDS don't allow kernel probes. Until then, faultwall audit --fix covers the bypass case with native Postgres privileges.

      

    

  


  

    
06  Fair questions

    
You may not need us. Here's how to tell.

    

      
You can, and some teams already run a shared approval service. FaultWall enforces at the Postgres connection, so you can apply controls without adding approval logic to each agent implementation.

      
Then keep them. FaultWall becomes relevant when you need controlled writes, reviewable exceptions, or one consistent workflow across agents.

      
Yes. The proxy becomes part of the database path. So we start in staging and test compatibility, latency, failure behavior and recovery with your workload before you decide anything.

      
We measure approval volume and turnaround during the evaluation. A lot of repeat requests can mean a rule is too strict. Some sensitive operations should keep requiring review regardless.

    

  


  

    

      
Work with us

      
Bring us one workflow.

      
We'll put it under limits your team agrees on, run it in staging, and give the owner the evidence to decide on production.

    

    Evaluate a workflow with us