Shield: bot management and AI agent defence
Block bad bots, AI scrapers and credential stuffing.
Shield sits in front of your website or API, on your own servers. It learns how your real visitors behave and blocks any source whose requests show it is not one of them. Every block comes with its reason. No rules to write, no traffic sent to us, and a flat price.
What Shield stops
The automated traffic that costs you money.
Bots made most of the web's traffic in 2024, and AI has made them cheaper to run and better at looking human (Imperva 2025 Bad Bot Report). Shield is built for the attacks that get past CAPTCHAs and rule lists.
Credential stuffing and account takeover
Bots replay leaked usernames and passwords against your login until one works. Shield sees a source sending login after login in a way your customers never do, and blocks it, usually within a few requests.
Web scraping and AI crawlers
Scrapers copy your prices, listings and content, and AI crawlers take it to train and feed AI products. Shield sees the sweep: a source moving through your site in a way people do not.
AI agents and automated browsers
AI agents can fill in forms, fetch files and claim to be any browser. Shield judges what a source does, not what it says it is: which request follows which, and how it reacts when it is refused. A user-agent string can be set to anything. That pattern cannot.
API abuse, fake sign-ups and bot surges
Floods of fake accounts, ticket and checkout bots, and automated calls against your API. Shield blocks the sources behind them inline, so your application, your database and your real customers never carry the load.
Against a rogue AI agent: in our public showcase, a reconstruction of the Services Australia portal incident with simulated traffic, Shield stopped the agent from its third request and blocked every request when it switched addresses, without blocking any of 600 legitimate visitors. See the showcase.
All five figures come from one recorded run on CSIC 2010, a public web attack dataset published by researchers, so anyone can check them.
How quickly an attacker is blocked
| Decided after | Attacking sources blocked | Genuine visitors wrongly blocked |
|---|---|---|
| 2 requests | 73.38% | 0 of 9,000 |
| 3 requests | 91.69% | 0 of 6,000 |
| 5 requests | 99.68% | 0 of 3,600 |
| 10 requests | 100.00% | 0 of 1,800 |
Measured on CSIC 2010: 25,065 attack requests and 36,000 normal ones. No genuine visitor was wrongly blocked at any point.
Why it is different
The same job as the cloud bot services, inside your own network.
Cloudflare, DataDome and HUMAN inspect your traffic on their network. Shield inspects it on yours.
| Cloud bot services (Cloudflare, DataDome, HUMAN) | Senua Shield | |
|---|---|---|
| Where it runs | In the vendor's cloud. Your traffic leaves your network. | On your servers, or fully offline. Your traffic stays. |
| What it learns from | The vendor's global bot data | Your own normal traffic |
| Price | By traffic, so the bill rises during an attack | Flat licence. Traffic is never metered. |
| Why it blocked | A score you cannot see inside | The reason, written out for every block |
| Footprint | An edge service or an appliance | 29 MB of memory, about 0.09 ms a request, about 11k requests a second on one core (CSIC 2010) |
Our figures are the CSIC 2010 results above. Vendor details are from their own product documentation.
How it works
Learn what normal looks like. Block what does not fit.
There is nothing to train in advance, no attack list to supply and no threshold to pick. We do not use models: no LLMs, no SLMs, no GPU and no AI token costs.
Step one
It learns your normal traffic
Shield watches your live requests (paths, methods, the shape of parameters and headers, and the order they come in) and learns how your site is really used. Nobody labels anything. That is how it catches a bot it has never seen: it does not need to recognise the attack, only that this is not how your site is used.
Step two
It scores each source
Every request gets a score for how far it sits from your normal traffic, and that score is added to the source making the requests. One odd request is not enough: real people send odd requests all the time, so a single request never blocks anyone.
Step three
It blocks when the requests agree
When a source's requests keep agreeing that it is not behaving like your visitors, Shield blocks it, usually by the third request. That is fast enough to stop an attack and careful enough that one strange request from a real customer never locks them out.
You set a false-block budget: how many genuine visitors you are willing to risk blocking, for example no more than 1 in 1,000. Shield works out its block level from your own traffic and shows it to you, with when and how it was set.
"By the third request" is the measured CSIC 2010 result above.
Why it blocked
Every block explains itself.
When a hidden score blocks a customer, your support team has nothing to tell them and your auditor has nothing to read. Shield records the reason with every block, in the console and in the export.
Why this source was blocked
Blocked- Source
- 203.0.113.47
- Network
- AS64512, EXAMPLE-HOSTING
- First seen
- 2026-09-21 03:14:08 AEST
- Blocked at
- 2026-09-21 03:14:09 AEST
- Requests seen
- 3
- Verdict
- Block source-level, by consensus
The requests that agreed
| # | Request | Departure | Verdict |
|---|---|---|---|
| 1 | POST /account/login | 0.41 | Allowed |
| 2 | POST /account/login | 0.78 | Watched |
| 3 | POST /account/login | 0.86 | Blocked |
In words
Three consecutive credential submissions to the same endpoint, each with a parameter and header structure this application has not been used with, and with inter-request timing that no genuine session here has produced. The three requests agree with one another, so the verdict is applied to the source rather than to any one request.
shield: source 203.0.113.47 blocked after 3 requests departure 0.86 (learned normal for /account/login) agreement 3 of 3 requests departing contributing parameter-shape, header-order, inter-arrival action block source, 30 min, auto-review on expiry operator note override available; this block is reversible
Sample verdict. The addresses, network and timings are examples; the structure of the explanation is the product's.
Answerable support calls
When a customer says "I was blocked", the answer is on screen: which requests, how far they departed, and which behaviours contributed. The operator can lift the block from the same view.
An audit trail that reads
Every verdict, its reason and every operator override are recorded and exportable. For a security operations centre or a compliance review, "the score said so" is not an answer; this is.
Overrides are the exception
Allow and deny lists exist for the cases where policy, not behaviour, decides, such as a partner's scanner or a payment provider's callback. They are not how you are expected to run the product day to day.
How you run it
Inline, in front of your application, on your hardware.
Shield runs beside the reverse proxy you already have and answers each request with allow or block, on the same path.
Reverse proxy connector
Inline via nginx, HAProxy or Envoy. The connector ships with the product, so the integration is a proxy configuration change, not an application rewrite. The verdict is returned on the request path in about 0.09 ms.
The latency figure is the CSIC 2010 measurement above.
Install in one command
yum or dnf on RHEL, CentOS and Amazon Linux; apt or a .deb on Ubuntu and Debian; a self-extracting .sh anywhere else; or a single container. It comes up as a service and the licence activates it.
Cloud and air-gapped
AWS and Azure images with Terraform; the data plane stays in your own account and region. For an air-gapped site the licence is an offline signed file you install by hand, with no call home to verify it.
What a deployment looks like
Nothing in that diagram makes an outbound connection to us. There is no threat-intelligence feed to subscribe to and no traffic sample to upload, because Shield learns from the only traffic that matters: yours.
Pricing
One flat price, whatever happens.
- Up to 10 sites
- 10 activated instances
- Traffic unlimited and not metered
- Inline mitigation, console, alerting
- Every block explained on one screen
- Annual is AUD $17,990
- Shield, Pulse, Discern, Vitals
- Cheaper than the $2,396 sum
- One console, one subscription
- 25 domains, 250 monitors, 100 hosts
- Every product, unlimited caps
- Offline licence activation
- No call-home for verification
- Enterprise fleets: Contact us
Prices, meters and the 3-day grace period are read from one price file. All amounts include 10% GST (AU). Subscriptions are arranged with our team directly, on your own hardware, with a guided setup.
Why it holds up
Measured in public. Learnt from your own traffic.
The figures on this page were measured on CSIC 2010, a public web attack dataset, so anyone can check them. On your own site, Shield learns from your own traffic, and every block carries its reason.
No signatures, no rule packs and no vendor feed to check every week. The one recurring task is re-learning your normal when your traffic really changes, which we budget at $2,000 to $5,000 a year, against $27,000 to $39,000 a year for tuning a rule-based firewall.
Government agencies, the defence supply chain, banks, health services and critical infrastructure, and online businesses that want a flat, self-hosted price instead of a bill that grows with every attack.
Put Shield in front of one site.
Tell us what you need to protect and which proxy sits in front of it, and we will show you how Shield learns your normal traffic from there.