How it works
What happens when one of the 146 agents runs, how its findings persist between scans, and how the Runtime Shield stops an attack while the fix ships. Each step names the code that does it, and the recordings are of it running.
One agent run
- 1
Size limit
Requests over 2 MB are refused on the wire, before they are read.
backend/body_limit.py
- 2
Access gate
Who is calling, whether they subscribe, and their limits: per address for visitors, per day for accounts. Visitors trying a free-preview agent get a smaller model.
backend/main.py, TierGateMiddleware
- 3
Secrets masked
Keys, tokens and passwords in the input are replaced before any model sees them.
backend/credential_redactor.py
- 4
Scanner pass
On the agents that have one, an established open-source scanner runs first, so the model reasons over its findings and not only the raw input.
11 scanners, verified in the production image every build
- 5
Model, in a fixed shape
Claude answers in a typed schema the server validates; an answer that does not fit is an error, not a report. Refusals are caught and logged.
backend/llm_client.py
- 6
Checks in code
Rules the model cannot override, for example: secrets masked again in the output, a severity a scanner confirmed that the model cannot talk down, required caveats added.
each agent module
- 7
Findings saved
When the caller names a target, each finding gets a stable fingerprint and is compared with the last scan.
backend/findings.py
Findings that persist
A scan is compared with the last one on the same target, so a team sees what changed instead of the whole list again.
| New | Not seen on this target before. |
| Still open | Seen again on a re-scan. |
| Reopened | Was fixed, and came back. |
| Resolved | A clean re-scan no longer reports it. |
New and reopened findings go to the team's Slack and to signed webhooks, and a CI run can set a GitHub check that fails on new findings. Delivery runs in the background, so a slow webhook never holds up a scan.
Stopping the attack while the fix ships
An agent can write the code fix, but it still has to be reviewed and deployed. Until then the Runtime Shield blocks attacks on that flaw. The customer runs it in their own infrastructure; their traffic never passes through Xaish, only the rules do.
- 1
Agent #146 writes a virtual patch
From the attack traffic, a WAF rule aimed at this application's own flaw.
Adaptive Network Defense
- 2
A person approves it
Nothing is enforced until someone with access approves it; every change is in the audit log.
Runtime Shield page, POST /api/runtime/rules
- 3
The server refuses anything that loosens protection
Only deny rules, in a reserved id range; no allow, no rule removal, no engine changes.
backend/runtime_rules.py
- 4
The customer's shield pulls it
OWASP Coraza with the Core Rule Set, run by the customer in front of their app. It loads new rules every minute without a restart, and rolls back if a set fails to load.
runtime-shield/, sync-patches.sh
| Request in the video | Shield |
|---|---|
| GET /products?id=42 | 200 passed |
| GET /products?id=1' OR '1'='1 | 403 blocked |
| POST /api/profile {"bio": "<script>alert(1)</script>"} | 403 blocked |
| POST /api/profile {"display_name": "Eve", "role": "admin"} | 200 passed |
| Virtual patch installed | |
| POST /api/profile {"display_name": "Eve", "role": "admin"} | 403 blocked |
| POST /api/profile {"display_name": "Mallory", "is_admin": true} | 403 blocked |
| POST /api/profile {"display_name": "Eve Smith"} | 200 passed |
| POST /api/profile {"bio": "My role at work is admin of the book club."} | 200 passed |
Measured on a corpus of 65 attacks and 38 ordinary requests: 58 of 65 attacks blocked, 1 of 38 ordinary requests wrongly blocked, 0.8 ms added per request. CI rebuilds the shield and re-runs the measurement on every change.
The demos page has recorded runs of the agents and their measured accuracy; any free-preview agent can be run from its own page.