Find out when someone is already inside your network, and whether it is a person, a script, or an AI agent.
PRIZMA detects intruders who are already inside your network and identifies whether they are a person, an automated script or an AI agent. It relies on decoys that no legitimate user has a reason to open, so every touch is a confirmed breach rather than an alert to triage. When you choose, it contains the source at the host firewall.
A single process on one host, with no external dependencies, designed for networks that cannot be taken offline to investigate. The same host also monitors your organisation's AI agents and sensitive documents, and runs a ten-profile attack simulation against itself every night.
READING
The intruder is now software that reads and obeys. Your defences were built for people.
Until recently an intruder inside a network was a person or a script. In September 2026 the first commercial AI model was released with what its own maker classified as critical cyber capability: it finds unknown flaws and exploits them without step-by-step human guidance, and it is sold by subscription. The next intruder in an essential-services network will read your documents, follow the instructions it finds in them, and adapt, at a cost close to zero.
A perimeter keeps this out for a while. It cannot tell you what happened after it failed, and it fails increasingly through a valid login rather than a broken door. After the incident the regulator, the minister and the board ask one question: what did the intruder do inside, when, and how do we know. A firewall log does not answer it. PRIZMA was built to answer it, with evidence produced on your own premises within the timelines NIS2 sets.
Essential services are attacked as a class, not one at a time. The same platform lets institutions warn one another the moment the same attacker appears at two of them, exchanging fingerprints and never content, so a country's operators act as one network while each keeps its own data.
The pilot takes one afternoon to set up and runs in passive mode: nothing is blocked, everything is recorded. Thirty days later you know what touched your network, and what it was.
From placement to verdict in three steps.
-
1
Place the decoys
Decoys are placed together with your team on the network segments you select, in the locations an intruder examines first. Each is indistinguishable from a genuine asset and unique to your installation. No employee performing normal duties has a reason to open one.
-
2
Record every touch
Every touch is recorded with its timestamp, source, client fingerprint and the actions that followed. A single touch constitutes a confirmed breach. There are no thresholds to tune and no baseline to learn, so detection is effective from the first day.
-
3
Read the session
Five signals distinguish a curious employee from an automated scanner and from an AI agent. They evaluate what the visitor did rather than how quickly, so a patient attacker gains nothing by slowing down. A touch cannot be undone, and neither can the actions that followed it.
Decoys are the starting point. The same host covers five further areas.
All modules write to a single log and a single console. A source observed by two independent modules is treated as confirmed, which is how a slow, careful intruder who touched too little to be classified is still identified.
- Intruders already insideA touch is a confirmed breach; the session is then read to tell a person from a script from an AI agent. Decoys are unique to your installation and change over time, so earlier reconnaissance is no longer accurate.
- Stolen credentials, at the moment of useDecoy sign-in pages, portals and API endpoints that look real and never grant access. Submitting a credential to one of them is evidence of escalation. The same attacker is recognised across portals without any password being stored.
- Your own AI agentsEvery request your agents send to a model passes a checkpoint on your host. Secrets are masked before they leave. Instructions hidden in web pages, tickets or model replies are caught before an agent acts on them. High-risk tool calls are held for human approval. Only the model endpoint you approved is reachable.
- Your documents in someone else's modelEach issued copy of a sensitive document carries its own reference. If that reference appears in traffic to an external model, you know immediately which copy was involved, who it was issued to and which model received it.
- The same attacker at another institutionInstitutions can share fingerprints, never content, through a collector at a national CERT or a trusted intermediary. When the same fingerprint appears at two of them, every participant is warned that a campaign is under way.
- The rhythm of your own sensorsThe platform learns the normal pattern of your log traffic and reports a source that spikes, a source it has not seen before, or a source that goes quiet, each with an explanation.
One page per incident, with the reasoning shown.
The incident page is what an operator reads before pressing Block: the verdict, the five signals that produced it, and the touches in the order they happened. Every figure on it links to the underlying records.
Verdict, confidence and the signals on one screen; each fired signal shows its evidence and its points. In passive mode the block action only counts what it would have done, so you can measure the effect before you switch it on.
Four counters, each linked to the records behind it. The threats list shows the verdict, the fired signals, the touches and the time of the last one.
One row per source: verdict, confidence, touches, decoy types, module, last touch, state. The filter is by verdict: all, AI, human, undecided.
Screens from the current build, demo data, addresses from documentation ranges.
Nothing is blocked until you authorise it, and only within the limits you set.
| Mode | What it does | Your guarantee |
|---|---|---|
| Passive | Records every touch and alerts your webhook, syslog or mailbox. The console shows the verdict and counts what a block would have done. | It never touches your firewall, never drops a packet and never ends a session. Nothing is blocked. |
| Approval | Holds the source for a person. One click blocks it at the host firewall, and the action is written to the audit log with the operator's name. | It never acts on its own. A source waits until an operator decides, however obvious the verdict looks. |
| Sharp | Slows sessions judged automated with high confidence, then drops them at the host firewall. The action is logged and the evidence package is sealed at that moment. | It never blocks a session judged human. Those go to a person, in every mode. |
Sharp mode blocks by source address at the firewall of the host that carries the decoys, and works alongside your network firewall.
Facts you can verify.
- 0dependencies
The runtime is Node.js 22 and nothing else. There are no third-party packages to audit, and the entire code base is readable.
- 526automated checks
Run on every change, covering the classifier, the agent firewall, cryptography, the portal and the console. The figure is reported by the test run.
- 5 + 1signals
Five signals that remain valid against an attacker who deliberately slows down, plus tempo, which is measured and displayed but does not determine the verdict.
- 3export formats
Evidence packages follow the NIS2 Article 23 timeline, early warning within 24 hours and incident notification within 72 hours. Each holds the verdict, the timeline, the indicators and a chain-of-custody hash, with an optional RFC 3161 timestamp that an auditor can verify offline with standard tools, and exports as text, JSON and STIX 2.1 for your SIEM or your regulator.
- 10attacker profiles
Replayed every night against a fresh, isolated copy of the installation, evasive profiles included. The scorecard is available each morning, and every change to the platform is measured against it.
- 2026independent review
Independently reviewed in September 2026, module by module. Summary available on request.
Built for networks that cannot be switched off
Energy, water, transport and public administration, where an investigation cannot mean downtime. PRIZMA runs behind your firewall and endpoint tools and watches for the intruder they let through, usually the one holding a valid login.
It sits beside your network, not in the path of your traffic, and installs nothing on your endpoints or your control systems. If the host fails, nothing else does.
The scoring is a set of readable rules, not a model. Your team can see why every verdict was reached, and adjust the weights to your environment.
Runs entirely on your premises. Nothing leaves your network unless you choose to send it.
Run it in passive mode for thirty days.
One host, the segment you choose, a console for your team and a report at the end. Nothing is blocked unless you enable it.
- Week 0Assessment. Before anything is placed, an optional AI-assisted review of the code you authorise us to examine identifies the areas an intruder would target first. Findings appear in the same console as all other events.
- Day 1Placement. Decoys are placed with your team, where the assessment indicates, in one afternoon.
- Days 2–30Watch. Passive mode. Every touch is recorded, judged and alerted. Nothing is blocked.
- Day 30Report. What was touched, when, and by what kind of actor, with supporting evidence for each entry: a one-page summary for the board and the full record for the regulator.
Thirty days without a touch is also a meaningful result.
Institutions, partners and investors reach us at the same address.
- HostOne Linux machine or container, reachable from the segment you want to watch. Two CPU cores and two gigabytes of memory are sufficient.
- RuntimeNode.js 22. No other packages, no database server, no agents on your endpoints or your control systems.
- TimeOne afternoon to install and place the decoys. About half an hour a week to review the console, unless a decoy is touched.
- AccessToken or passkey sign-in for operators, read-only roles for auditors, console and reports in Serbian and English. Every operator action is written to the audit log.