The short version. Almost every security control a bank runs, the antivirus on the laptop, the firewall at the perimeter, the WAF in front of the app, works the same way underneath: it holds a list of known-bad things and blocks what matches. That model was already losing a slow war against novel attacks. It is now losing a fast one, because attackers can generate original, working exploits at machine speed while a signature still takes a human days to write. The only defense that scales in the other direction is to stop enumerating the infinite bad and start enumerating the finite good: learn what each system is actually supposed to do, and refuse the rest. That is positive security. This paper is the case for it, the honest limits of it, and how Nemesis builds it in three layers, Edge at the network, Sentinel at the application, Omniguard at the transaction.
The asymmetry just changed, and finance is the target
For thirty years the attacker and the defender were roughly matched on speed. Someone found a new technique, it circulated, vendors wrote a signature, everyone updated. The defender was always a step behind, but it was one step, measured in days or weeks, and most organizations survived in that gap.
That gap is closing on the wrong side. Autonomous offensive systems, the same class of technology we build in Nemesis Red, can now enumerate a target, find a weakness, and produce a working exploit without a human in the loop, in minutes, in parallel, across thousands of targets at once. The cost of generating a novel attack variant has fallen faster than the cost of any other part of the chain. The cost of writing the signature that stops it has not moved.
For a financial institution this is not an abstract worry. Banks, insurers, payment companies and fintechs are the highest-value targets on the internet, and they carry the most expensive attack surface: decades of legacy core systems that cannot be casually rewritten, wrapped in thousands of APIs, mobile apps, partner integrations and web front ends, all sitting on top of money that moves in real time. The average cost of a breach in financial services runs well into eight figures once fraud, remediation, regulatory penalty and customer loss are counted. An attacker that can generate original attacks at machine speed, against an institution defended by lists of yesterday's attacks, is a losing position stated plainly.
The rest of this paper is about why the defense is built the way it is, why that design has a structural ceiling, and what defense looks like when you invert it.
How the tools actually work, and what they have in common
It helps to be concrete about the machinery, because the shared flaw is easier to see once you have looked at each piece.
Antivirus, and endpoint detection after it. Classic antivirus keeps a database of signatures, byte patterns and hashes that identify known malware. A file arrives, the engine compares it against the database, a match means quarantine. Later generations added heuristics, is this file shaped like known-bad, and behavioral detection, is this process doing something known-bad at runtime. Each generation broadened the definition of bad, but the question never changed: does this match something we already know is dangerous?
Firewalls, from packet filters to next-generation. The earliest firewalls filtered packets by port and address, allow 443, deny that range. Stateful firewalls tracked whole connections rather than lone packets. Next-generation firewalls added deep packet inspection and an intrusion prevention system, a library of signatures for known network attacks, so the box could look inside the traffic and drop anything matching a known exploit pattern. More intelligence at each step, but again the same core: a list of known-bad patterns, matched against the wire.
Web application firewalls. A WAF sits in front of the application and inspects HTTP requests against rules for known attack shapes, the classic signatures for SQL injection, cross-site scripting, path traversal. A request that matches a rule is blocked. A request that does not is passed to the app.
Three different layers, three different vendors, one identical design underneath. Every one of them is a negative security model: it maintains an enumeration of bad things and blocks what matches. Security researcher Marcus Ranum named the trap two decades ago and called it enumerating badness. The problem is arithmetic. The set of bad things is unbounded and grows every day. The set of things you have a signature for is finite and always behind. You are trying to complete an infinite list, one entry at a time, against an adversary who adds to it faster than you can.
flowchart LR T["Incoming request"] --> FW["Firewall / IPS<br/>match known-bad<br/>ports, IPs, exploit sigs"] FW --> WAF["WAF<br/>match known-bad<br/>request patterns"] WAF --> AV["Endpoint AV / EDR<br/>match known-bad<br/>files and behavior"] AV --> APP["Application<br/>and data"] N["Novel AI-generated attack<br/>no signature exists yet"] -. "matches nothing,<br/>passes every layer" .-> APP
Why the breach happens anyway, with every box checked
Institutions that get breached are rarely the ones that skipped the controls. They have the firewall, the WAF, the EDR, the audits, the compliance checkmarks. They get breached because the negative model has failure modes that no amount of the negative model can fix.
It cannot see what has no signature. A zero-day, or now an AI-generated variant, is by definition absent from every list. It passes because there is nothing to match. This is not a gap in coverage that a better list closes; it is the permanent leading edge of an infinite list.
The dangerous attacks look like your own traffic. The breaches that hurt most are not exotic payloads. They are a perfectly well-formed request asking for an object that belongs to someone else. Change the account number in GET /api/statements/1001 to 1002 and read a stranger's statement. There is nothing malicious in that request to match, no injection, no anomaly a pattern matcher would flag. It is a legitimate-looking request for an illegitimate object, and a signature engine is structurally blind to it because the fact that account 1002 is not yours lives in your application, not in anyone's signature database.
Valid credentials defeat the whole premise. Phished or stolen credentials, a compromised employee session, a rogue insider, none of these trip a known-bad pattern, because the traffic is authorized. The negative model asks does this look like a known attack. Credential abuse looks like a Tuesday.
The false-positive tax quietly turns the controls off. Because the patterns are generic and the same for every customer, they flag legitimate traffic that happens to resemble an attack. The team drowns in exceptions, and the rational response, the one that happens in real operations every day, is to turn the WAF down to log-only and stop trusting the alerts. A control set to log-only is a control that is not controlling.
And now the treadmill runs faster than the humans. Every failure above predates AI. What AI changes is the clock. When novel variants can be produced continuously and cheaply, the interval between a new attack existing and a signature existing stops being the safe gap most institutions survived in. It becomes the window the attacker lives in, permanently.
None of this is a reason to remove the firewall or the EDR. They still stop the enormous volume of commodity, already-known attacks, and that volume is real. The point is narrower and sharper: the negative model has a ceiling, you are already near it, and the attacks that get through the ceiling are precisely the ones that end up in the breach notification.
Turn the model around
If the bad is infinite and the good is finite, defend the finite side.
A positive security model does not ask does this look like a known attack. It asks does this look like what this system is supposed to do, and treats everything else as suspect. Instead of enumerating infinite badness, you learn a bounded envelope of legitimate behavior, and deviation from that envelope is the signal. The idea is not new in principle, a default-deny firewall rule and application allowlisting are both positive security, but two things make it newly practical and newly necessary: the attacks that now dominate are deviations from normal rather than matches against known-bad, and machine learning can now learn a rich behavioral envelope that a human could never write by hand.
flowchart LR
subgraph NEG["Negative model"]
B["enumerate the infinite bad<br/>always one variant behind"]
end
subgraph POS["Positive model"]
G["enumerate the finite good<br/>deviation is the signal"]
end
B --> L["novel attack MISSED<br/>no signature to match"]
G --> W["novel attack CAUGHT<br/>it is not normal"]
The inversion is the whole point. A novel attack, the exact case the negative model cannot see, is visible to the positive model for the same reason it was invisible to the other: it has never been seen before, so it is not part of normal, so it stands out. You do not need to have catalogued the attack in advance. You need to have learned the system's own normal.
There is an honest cost to state alongside the benefit, and we would rather name it than imply the model is a force field:
- A learning period. A positive model has to learn normal before it can enforce, so there is a baseline phase. The answer is staged rollout, observe, then alert, then enforce, not a switch thrown blind on day one.
- In-envelope abuse is the real gap. An attack that uses only normal-looking actions in a normal-looking order, entirely inside the learned envelope, does not deviate and is not caught by behavioral defense alone. That gap is narrow, but it is real, and a vendor who claims none is not measuring.
- The baseline has to be yours. A model learned across all customers treats your legitimate weirdness as an anomaly and hands back the false-positive problem you were escaping. Normal is per-tenant or it is noise.
Positive security is a strong layer, the strongest available against the unknown attack, and it works best on top of the negative controls that still handle the known volume, not as their replacement.
Positive vs negative, stated plainly
- The question. Negative: does this match known-bad? Positive: does this match known-good?
- What it needs to work. Negative: a signature for every attack, forever. Positive: a model of your own normal, learned once and kept current.
- The unknown attack. Negative: invisible, no signature exists. Positive: visible, it is not normal.
- The well-formed request for the wrong object. Negative: passes, nothing to match. Positive: flagged, the access pattern deviates.
- Stolen valid credentials. Negative: passes, traffic is authorized. Positive: the session behaves unlike the account's learned normal.
- The false-positive failure. Negative: generic rules flag legitimate traffic, teams disable enforcement. Positive: a per-tenant baseline treats your normal as normal.
- Effect of better AI on the attacker. Negative: worse, variants are generated faster than signatures. Positive: neutral to better, novelty is the very thing it flags.
- The honest gap. Negative: everything it has not yet seen. Positive: abuse that stays entirely inside your learned normal.
How Nemesis builds it: three layers of one idea
Positive security is not a single product. An attacker touches an institution at the network, at the application, and at the transaction, so the envelope has to be learned and enforced at all three. That is exactly how the Nemesis platform is arranged: three engines, one model, defense in depth without three false-positive problems.
flowchart TB
V["Visitor · API client · transaction"] --> E
subgraph PS["Positive-security envelope · learn, then observe, then enforce"]
direction TB
E["Nemesis Edge · network layer<br/>good origins, routes, geographies, rates"]
S["Nemesis Sentinel · application layer<br/>good request shapes, object access,<br/>call sequences · web · API · LLM"]
O["Nemesis Omniguard · transaction layer<br/>good account and payment behavior,<br/>per customer, per channel"]
E --> S --> O
end
O --> C["Core systems · money · data"]
PS -. "anything off-baseline" .-> D["deny with evidence<br/>learned-vs-observed diff"]
Nemesis Edge, at the network. Edge is the positive-security layer at the perimeter, in the shape of a modern programmable edge. Rather than only holding a list of bad IPs, it learns the good: which origins and routes are legitimate, what request rates and geographies are normal for this property, what a healthy client looks like. It runs learn, then observe, then enforce, so a property can be brought under enforcement without a blind cutover, and off-baseline traffic is refused at the edge before it ever reaches the app.
Nemesis Sentinel, at the application. Sentinel is the behavioral engine for web apps, APIs and LLM features. It learns a per-tenant envelope of the application's own normal, the request shapes and parameter types, the object-access patterns that reveal a user walking IDs across a tenant boundary, the response shapes that make bulk exfiltration visible, and the call sequences real workflows produce. It is the layer that catches the boring, dangerous attacks a signature WAF cannot: the well-formed request for the wrong object, the workflow run out of order, the response that returns ten thousand records where one is normal. It installs in one line and never reads your source or your data; what the SDK sends is a structural sketch of a request, hashed on the device, not the payload. For LLM features it learns the behavioral boundary that a keyword guardrail cannot, what your model is actually supposed to be asked and supposed to answer.
Nemesis Omniguard, at the transaction. The final layer is the money itself. Omniguard learns the normal behavior of each account and payment flow, per customer and per channel, and flags the transaction that deviates, the transfer that fits no prior pattern, the sequence that looks like account takeover rather than the account's owner. This is where intrusion defense and fraud defense stop being separate disciplines: both are the same question, is this the legitimate party behaving legitimately, asked at the layer where the loss actually occurs.
The three share a design that makes them deployable where WAFs and RASP historically stalled. Enforcement is staged and gated on readiness, with a shadow mode that shows what would have been blocked before anything is. Every block ships with its evidence, the learned-versus-observed diff, so an engineer sees in seconds why a request was stopped and can approve a legitimate one with a click. And every baseline is per-tenant, so your normal is treated as normal.
The money argument
Security spend is usually justified by fear, which is a poor way to size a budget. Positive security has a cleaner economic case, and for a financial institution it is the case that matters.
It reduces the breach that the negative model was always going to miss. The expensive breaches in finance are the novel intrusion, the business-logic abuse, the credential-driven account takeover, exactly the classes that have no signature and pass the perimeter. Moving the catch rate on those from near zero to high is not a marginal improvement to an already-covered risk; it is coverage of the risk that was uncovered, and it is the risk that produces the eight-figure loss.
It cuts the operational cost of the false-positive treadmill. A per-tenant learned baseline produces far fewer false positives than generic global rules, which means fewer exceptions to write, fewer analysts spending the week tuning, and fewer controls quietly disabled. The negative model has a hidden running cost measured in salaried hours; positive security lowers it.
It scales without scaling headcount. The negative model's labor grows with the attack catalog, someone has to keep writing and tuning rules forever. A learned model's labor is mostly the initial integration; after that it maintains its own picture of normal as the application changes. Against an attacker whose costs are falling, a defense whose costs also fall is the only affordable long-run position.
The blunt version: the negative model asks you to spend more every year to stay in the same place, and still lose to the attack it has never seen. Positive security asks for the integration once, then lowers both the breach risk and the running cost. In a sector where a single missed intrusion clears the entire annual security budget several times over, that is not a marginal trade.
What to demand
- Positive or negative? Does the control learn your normal and refuse the rest, or match a generic list of known-bad? Both belong in the stack, but be clear which job each one is doing, and make sure the unknown-attack job is actually covered.
- Can it stop the well-formed request for the wrong object? If a control cannot stop user A from reading user B's record when the request is otherwise valid, that risk is unaddressed today, and it is the risk that breaches you.
- Per-tenant or global baseline? A global model reintroduces the false positives that turn controls off. Insist the baseline is yours.
- Does it read your code or your data? A defense that needs only the shape of traffic is one you can actually turn on in a regulated environment.
- Is enforcement staged, with evidence on every block? Observe, then alert, then enforce, with a shadow mode and a learned-versus-observed diff, is the difference between a control you trust and one you disable.
- What does it admit it misses? In-envelope abuse is the honest gap in positive security. A vendor who claims to miss nothing is not measuring, and is the wrong vendor for money.
The attacker's cost of inventing a new attack just fell through the floor, and it will keep falling. No list of yesterday's attacks catches tomorrow's, and there is no longer a comfortable gap between the two. The defense that scales in the same direction as the threat is the one that stops trying to name every bad thing and starts knowing, precisely and per-tenant, what good looks like, at the network, in the application, and on the money.
Nemesis builds positive security in three layers: Edge learns good traffic at the network, Sentinel learns your application's own normal for web, API and LLM, and Omniguard learns normal account and payment behavior, each enforcing with evidence on every block. autogon.ai