Apps Safety Company News
Get started

The threat has changed. For three decades, the adversary behind most attempted compromises of production infrastructure was a human — a human with a script, a human with a toolkit, a human with patience. Defenses were designed accordingly. Pattern-matching worked because humans reused techniques. Scheduled scans worked because humans operated on human timescales. Queues of alerts worked because humans could triage them at human speed. The entire discipline of operational security was built around the assumption that on the other side of the wire there was another person.

That assumption is no longer sound. The adversary behind a growing share of attempted compromises is an autonomous agent — software that reads documentation, reasons about code, generates novel payloads, adapts to error responses, and enumerates attack surfaces at speeds no human can match. The tools that defenders have relied on for decades were not designed for this adversary. Signatures describe techniques that the agent does not need to reuse. Severity scores describe generic vulnerabilities, not the specific path through your system. Alert queues overflow with findings that no human team can process. The defensive posture has to change with the threat. What we are building is the defense that matches it.

The closed loop

Prion is an autonomous system that operates a closed loop over your infrastructure. It reads the code — every repository, every configuration file, every infrastructure-as-code definition, every policy document that describes how the system is supposed to behave. It models that system as a living graph rather than a static inventory, tracking how components communicate, what data flows between them, what permissions govern access, and how the behavior changes under different conditions. Against that model, it reasons about how the system can fail — not by matching against a list of known issues, but by generating hypotheses about the specific conditions under which this specific system breaks. When it finds a flaw, it synthesizes a patch. It verifies the patch. It opens the change. Every step is recorded; every step is reversible.

Verification before the patch ships

The step we consider most important in the loop is the one most systems skip. When Prion proposes a change, it does not ship it into the pull request as a suggestion for a tired reviewer to rubber-stamp. It provisions an ephemeral copy of your infrastructure — a shadow twin — and runs three gates against the patched version before the change is ever offered for human review.

The first gate is functional. Prion runs the project's existing test suite — unit, integration, end-to-end — against the patched code. If any test that passed before the patch fails after it, Prion iterates on the synthesis. A patch that closes a security flaw by breaking the product is not a fix.

The second gate is adversarial. Prion's own offensive agent attacks the patched system with the exploit it just identified, along with variants the system generates from that exploit and a library of related techniques it has seen before. If any variant succeeds against the patched code, Prion iterates. A patch that closes the specific instance of a flaw but leaves the class of flaw intact is an incomplete defense.

The third gate is performance. Prion runs the project's benchmarks and compares the patched system to the baseline. If the patch introduces a regression in latency, throughput, or resource use beyond a configured threshold, Prion reports the tradeoff explicitly instead of shipping it quietly. A patch that quietly degrades production is a different kind of failure that still matters.

Only when all three gates pass does Prion open a pull request — and when it does, the request arrives with signed evidence of each gate. The reviewer does not have to trust the agent. The reviewer can read the receipts.

Cross-system reasoning

A significant class of serious vulnerabilities does not live inside any one file. It lives in the interaction between code, configuration, permissions, and deployment — conditions that are each innocuous individually and compromising in combination. A server-side request forgery that would have been low-severity under a restrictive permissions model becomes critical under a permissive one. A dependency with a minor parsing bug becomes a path to privilege escalation when the service that uses it runs with elevated access to a secrets store. These failures cannot be found by reading any single file. They have to be reasoned about across layers.

Prion reasons across the full surface — source code, infrastructure definitions, admission policies, identity and access configuration, secrets topology, runtime telemetry. Vulnerabilities that cross layers are found as a first-class concern rather than as an incidental output of a scanner that only looks at one file at a time.

Two modes of operation

Prion runs in two modes that share the same underlying reasoning and differ in how aggressively they act.

The first is analyst mode. The system reads, reasons, patches, verifies, and opens a pull request for human review. The human retains the final authority. This mode is appropriate for changes to code, to infrastructure, and to configuration where the pace of iteration is bounded by code review cycles. It is the default.

The second is operator mode. The system watches live traffic and runtime behavior, detects an attack in progress, and acts to contain it — cutting suspicious sessions, quarantining compromised workloads, rolling back a deployment that began misbehaving immediately after shipping. Operator mode is configurable: some actions can be fully autonomous at the customer's policy; others require a human to confirm within a bounded window. A global switch stops the mode immediately. Every action, in either direction, is recorded and reversible.

Recognizing the machine on the other side

An attacker that is itself an autonomous agent behaves differently from a human. It explores breadth-first in a way a human would not. It adapts payloads between requests in a pattern that reveals the agent is reasoning about the responses it received. It operates at speeds that make human fatigue irrelevant. These behaviors leave signatures — not signatures of a specific payload, but signatures of a thinking adversary. Prion is trained to recognize them. When the system identifies that the attacker is itself an agent, the defensive response changes: aggressiveness rises, tolerance for error falls, human review is escalated automatically. This is the capability we believe will define defense in the years ahead, and it is the one we are investing the most research against.

What Prion is not

Prion is not a replacement for the established components of a security program. Firewalls still matter. Access controls still matter. Secure development practices still matter. Prion operates above the layer those tools address. It is not infallible. Agents make mistakes, miss things, and occasionally propose changes that should not ship. The value of the closed-loop design is that every step is verified, every action is recorded, and every decision is reversible — not that any step is assumed to be correct. Autonomy is earned incrementally against a record, not granted by default.

Why this matters now

The infrastructure that modern organizations depend on is more complex, more interconnected, and more autonomous than anything that has come before. The attackers that target that infrastructure are moving in the same direction. The window in which defensive tooling built for human adversaries can keep up with agent adversaries is closing. What we are building is what comes next — and what comes next has to be designed, from its foundation, for a condition in which both sides of the wire are machines.

Current status

Prion is in active development and deployed inside a restricted cohort of partners operating critical infrastructure. We are not offering a general public release. Access is granted on the basis of architectural review and the fit between the customer's threat model and the system's capabilities. Engineering organizations that want to participate can request access through the console.

The defender has to match the attacker. Both sides of the wire are now machines.