Security that starts in the code.

Microsegmentation divides the network into segments. Picosegmentation divides the program code into layers and zones. The layers are input, processing and output. Processing is further divided into zones: a password is handled in a different zone than a simple HTTP call.

Between two zones there is exactly one passage, the gate. That is where the decision is made whether an operation may take place. There is no second way. An effect only happens at a gate in the code.

This leads to the most important sentence on this page: a bug may sit in its zone. It cannot be used for the effect of another zone, because the way there does not exist.

A boundary where checking stops is a gap. Microsegmentation closes that gap in the network. Picosegmentation closes it in the code, exactly where bugs actually happen.

Computer science has known the individual building blocks for decades, such as permissions attached to objects, type checking and separated privileges. The protection only comes from the closed architecture that joins them into a whole inside the code. Aviontex developed this architecture.

In October 2026 PHP servers around the world had to be updated urgently. Two holes in the core of PHP allowed running foreign code without logging in (CVE-2026-109618 and CVE-2026-109619, fixed in PHP 8.5.12). In the first, an upload exhausts memory and the cleanup treats a half finished request as valid. In the second, state from one request slips into the next.

Both follow the same pattern as many holes before them: something that should only be data reaches an effect it was never meant for. With Picosegmentation that way does not exist. This makes PHP a good thought experiment. It is not a criticism of PHP. PHP has fixed many of these problems itself over the years.

The basic problem: classic PHP had only one type for almost everything, text. Four properties came on top:

• Input everywhere. $_GET, $_POST and $_COOKIE could be read on any line, unchecked.
• Full effect for everyone. Whoever reached the database connection could do anything with it.
• One flat space. Every function could call every other function.
• Soft boundaries. eval, include and unserialize undermined any order.

So any value from a request could be used anywhere for any effect: as a database query, as HTML, as a file name, as a shell command or as code. Read does not mean trustworthy. Stored does not mean approved.

The proof takes seconds. Take a known class of bugs in which text from the network reaches an effect. Then ask which passage it took to get there. With Picosegmentation that passage does not exist. This holds not for single holes but for whole classes.

heap->overflow = 0;
zend_bailout();

while ((line = get_line(self)) && line[0] != '\0') {
    ...
    zend_llist_add_element(header, &entry);
}

if (Z_ISUNDEF(PG(http_globals)[where])) {
    return 0;
}
potential_session_id = zend_hash_find(
    Z_ARRVAL(PG(http_globals)[where]), PS(session_name));

Nobody has to change millions of lines of code at once. Just as microsegmentation grows segment by segment in a running network, Picosegmentation grows zone by zone in the code. You begin at the critical place, where data turns into an effect: where data comes in from the network, where something is stored and where something is executed.

This one gate already takes a path away from an attack. Every further update brings the next zone while the software stays in use. Nothing changes on the outside: interfaces and behaviour stay the same. This is days and weeks, not years.