Several years ago, we started Archipelo by looking upstream.

Cybersecurity had become increasingly effective at examining software after it was created: source code, dependencies, applications, cloud infrastructure, configurations, vulnerabilities, and runtime activity.

But every piece of software begins somewhere.

It begins with an actor.

For most of software history, that actor was primarily a human developer. Then developers began working alongside AI copilots. Copilots became increasingly capable agents. Agents began operating tools, executing commands, modifying files, interacting with infrastructure, using credentials, and changing persistent software state.

Software actors have always executed.

What changed was the autonomy, scale, complexity, and consequence of that execution—and therefore the importance of establishing a verifiable history of what actually occurred.

Our architecture evolved with it.

We Started With the Actor

In 2025, we introduced Developer Security Posture Management, or DevSPM.

The thesis was straightforward: software security had a blind spot.

Security systems could scan code. They could analyze dependencies. They could inspect applications and cloud environments. They could detect activity in production.

But the actors creating the software remained a security blind spot.

This mattered because risk could be introduced before software ever reached production—through the actions, tools, credentials, environments, and decisions involved in creating it.

And those actors were no longer exclusively human.

Our early DevSPM work explicitly treated developers and AI systems as software actors. It connected identity and behavior with the context in which software was being created. DevSPM provided identity-aware observability, behavior-linked telemetry, and risk analysis tied to human and AI authorship.

To understand software risk, look upstream at the actors introducing it.

Then the Execution Boundary Expanded

At first, AI primarily assisted software creation.

A developer remained the principal actor. An AI system suggested a function, completed a block of code, explained an error, or generated an artifact. The human generally decided what to accept and what to execute.

Increasingly capable agents change that relationship.

They can operate tools themselves. Read and write files. Execute commands. Call APIs. Modify repositories. Use credentials. Interact with infrastructure. Spawn processes. Produce artifacts. Change persistent state.

None of these actions is fundamentally new.

What is changing is how much consequential execution can occur autonomously, across multiple actors and systems, before a human can reconstruct what happened.

The progression is:

Human developer — writes and executes software

↓

Human + copilot — co-create software

↓

Human + agent — create, modify, and execute

↓

Agents + tools + automation — execute across systems and persistent state

The important change is not simply who writes the code.

It is the expanding scope of execution—and the resulting need to establish its history.

Observing the Actor Is Not the Same as Verifying the Execution History

DevSPM made the actor the center of analysis.

That remains important.

But knowing who an actor is, or observing its behavior, does not establish a verifiable history of what actually occurred.

Several different questions emerge:

Identity — Who is the actor?

Authority — What is the actor permitted to do?

Execution — What consequential execution occurred?

State — What changed as a result?

These questions interact. They are not interchangeable.

An identity system can establish that an actor possesses a credential.

An authorization system can establish what that credential permits.

An observability system can report activity associated with the system.

A security system can infer whether that activity appears dangerous.

None of those functions, by itself, establishes a verifiable record connecting consequential execution to the resulting software state.

That is the deeper problem.

The Unit of Analysis Expanded

Traditional software security often reasons through artifacts.

A developer writes code. Code enters a repository. A build produces an artifact. The artifact is deployed.

The resulting chain is:

Developer → Code → Build → Artifact → Deployment

Autonomous software adds another chain:

Actor → Tool → Action → State → Actor → Tool → Action → State

One actor can create information that another actor later consumes.

One execution can produce an artifact used by a later execution.

Credentials discovered during one run can alter what becomes possible during another.

A file, database, package repository, cache, artifact store, or external service can carry state between otherwise separate actors.

The software supply chain is increasingly accompanied by an execution chain.

Once consequential execution becomes distributed across actors, tools, environments, and persistent state, observing individual actors is no longer sufficient to reconstruct what happened.

The execution history becomes part of the security problem.

The OpenAI–Hugging Face incident later provided a concrete example of this pattern. Execution became distributed across multiple agents, persistent information, credentials, tools, and infrastructure. An individual agent transcript could not by itself explain the resulting system behavior.

The incident did not produce this architecture. It illustrated the problem our architecture was already designed to address.

This is not fundamentally an AI problem.

It is a systems problem.

From DevSPM to Salmon

This changed what we needed to build.

DevSPM asked:

Who is creating and modifying the software, what are they doing, and what risk are they introducing?

The expanding execution boundary required another question:

What consequential execution occurred, how did it relate to prior execution, and what software state resulted?

The underlying direction remained upstream.

The architectural boundary expanded.

We built Salmon for that expanded boundary.

Salmon is Execution Verification Infrastructure.

Its purpose is to establish verifiable execution records for supported consequential software execution within explicitly defined verification boundaries.

The architecture is:

Humans + Agents + Automation

↓

Consequential Execution

↓

Salmon — Execution Verification

↓

Verifiable Execution Record

↓

Machine-Consumable Execution Evidence

↓

AI Systems · Cybersecurity · Infrastructure · Audit · Forensics · Governance

The distinctions matter.

Execution Verification Infrastructure is the category.

Verifiable Execution Record is the core primitive.

Machine-Consumable Execution Evidence is the output downstream systems consume.

Salmon is not the system that makes every downstream judgment. Its role is specific: establish execution evidence with explicit verification properties and boundaries so other systems can reason from it.

Why Verifiable Execution Evidence Matters

The need for execution history does not end with the human investigating what happened.

As software execution becomes increasingly autonomous, execution evidence must increasingly be consumable by machines.

Security systems need execution evidence to detect, investigate, and respond.

AI systems need execution evidence to evaluate and supervise the actions of other software actors.

Infrastructure and developer platforms need execution evidence connecting consequential execution to the state their systems produce and maintain.

Audit, forensic, verification, and governance systems need execution evidence to reconstruct events, attribute actions, and apply external rules.

These systems perform different functions. They should not be collapsed into one category.

They share a common requirement:

They need reliable evidence of what actually executed.

This is why Execution Verification belongs at the infrastructure layer.

Salmon establishes the execution record. Other systems consume that evidence for reasoning, verification, investigation, response, and governance.

Evidence Before Inference

This distinction matters more as security systems themselves become increasingly autonomous.

AI systems are getting better at inference.

They can correlate events, classify behavior, identify anomalies, reconstruct likely sequences, recommend remediation, and increasingly act on their conclusions.

But better inference does not produce better evidence.

A highly capable model can reason over incomplete evidence.

It can reason over incorrectly attributed evidence.

It can reason over mutable records.

It can reason over a transcript produced by the same actor whose behavior is being evaluated.

Increasing inference capability does not repair the underlying evidentiary problem.

This leads to a core architectural principle:

Do not rely on probabilistic inference to reconstruct execution history when the relevant execution evidence can be established and verified directly.

Evidence generation and evidence interpretation are different functions.

Salmon operates on the evidence side of that boundary.

It does not replace identity systems, authorization, runtime security, observability, AI monitoring, containment, alignment, or governance.

Those systems answer different questions.

Salmon establishes the execution record from which downstream systems can reason.

From Observability to Verification

We began by looking upstream.

Instead of asking only whether software contained risk, we asked who—or what—was creating it, what those actors were doing, and what context surrounded their actions.

That led us to DevSPM.

As software execution became more autonomous, distributed, multi-actor, and consequential, the problem expanded.

Observing the actors remained necessary.

But it was no longer sufficient.

What changed was the requirement for evidence.

We needed to establish what actually executed, how execution related across actors and time, and what state resulted.

That led us to Salmon.

DevSPM made software actors observable.

Salmon makes their consequential execution history verifiable.

The mission did not disappear.

The execution boundary expanded.