> ## Documentation Index > Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt > Use this file to discover all available pages before exploring further. # Agent Payment Rails Security > The three layer defence built into AV-RAILS. Every block across x402, MPP, AP2 and A2A is a Falcon-1024 signed, offline verifiable decision. ## What it is AV-RAILS ships a three layer defence in front of the payment engine, active by default in a fresh install. It is not a separate purchase and not a bolt on: the same defence sits in front of every protocol the gateway speaks, so you harden once rather than four times. The distinguishing property is not that requests are blocked. It is that every admission and edge decision is a Falcon-1024 signed, content addressed record you can verify offline, without calling back to AlgoVoi and without trusting the operator. Security becomes part of the same evidence estate as your settlement and compliance receipts. ## One defended edge for four protocols An x402 request, an MPP per method charge, an AP2 signed mandate and an A2A task payment all pass through the same admission and edge controls, and all produce the same shape of signed decision record. ## The three layers A fail2ban perimeter driven by runtime signals. Hosts that trip the gateway's own defences are banned at the edge before they reach the application. The Layer 1 admission gate. Structural bounds and a Content-Length byte limit reject oversized and malformed requests before canonicalisation. It reads headers only, never buffers the body, and fails open. Each verdict is a signed ADMIT or REJECT. The Layer 2 runtime edge. IP, geo and ASN blocking, rate and velocity limits, identity allow and deny, and replay and nonce checks. Each verdict is a signed edge decision. Loopback and the health, ready and metrics endpoints are exempt so internal operations are unaffected. ## Security that produces evidence A conventional gateway blocks a request and writes a log line you have to trust. AV-RAILS blocks the request and emits a signed decision that anyone can verify offline. * Every decision carries its own signed reference, for example `edge_decision_ref: sha256:502aafbf...`. * The reason is categorical and machine readable, for example `BLOCK_IP_CIDR`, `BLOCK_GEO_COUNTRY`, `BLOCK_RATE_EXCEEDED`. * A decision is recomputable from its disclosed fields, so a reviewer confirms what happened and why from the artefact alone. * Signatures are Falcon-1024, so a decision made today stays verifiable across a long retention horizon. ## Operator control An operator security console in the control panel exposes the whole defence. View banned addresses, and pause or resume each layer independently at runtime with no restart (a shared toggle store, default on, honoured within seconds). Every change is audit logged. ## Active by default All three layers are active in a fresh AV-RAILS install, wired into both internet edges (the gateway and the control plane) and governed by the one shared panel toggle. Verified behaviour on a clean install: a denied IP returns a signed 403, an oversized body returns 413, and a perimeter ban is applied from the observed signal. ## What this is not It is a defence that produces evidence, not a claim of total security. It does not replace network isolation, a firewall you run in front of the host, secrets management, or the operational hardening the deployment guide covers. Individual decisions are signed and independently verifiable; treat them as per decision artefacts. ## See also * [Self hosted agentic payment gateway](/payment-rails-sqlite), the rails this defends. * [Operator control panel](/operator-control-panel), where the security console lives. * [Security Suite](/security-suite), the same two layer suite available standalone. * [Payment rails deployment guide](/payment-rails-deployment-guide), the full install and hardening walk through.