The Capability Delta

A process can behave normally for hours.

Then something changes. It obtains access to a credential. It discovers a new API. It spawns a shell. It reaches a previously inaccessible network. It queries the Kubernetes API. It accesses a secret store. It begins communicating with another workload.

None of these events necessarily proves compromise.

But the security state of the workload has changed. That change is the Capability Delta.

For increasingly autonomous software, that change may be more informative than trying to determine whether an individual process is "malicious."

The Old Question

These traditional questions remain useful. But autonomous software creates a harder problem. A process can be completely legitimate while its effective capabilities change dramatically.

A legitimate AI agent may begin with Read documents and later obtain:

The executable may not have changed. The process name may not have changed. The container may not have changed. Its identity may not have changed.

But its operational potential has. That is the security event.

Capability is a Security Primitive

Security traditionally models an entity using identity and permissions. That provides a static description of authorization.

Runtime security needs another dimension: What can the workload actually do right now?

The final layer is important.

A workload might technically possess a permission without ever exercising it. Conversely, a compromised environment may cause a workload to discover credentials, sockets, APIs, or network paths that materially expand what it can do.

The difference between those states is operationally significant.

The Capability Delta

Imagine an inference workload begins with this capability set:

The process might still appear legitimate. But:

contains several high-value changes. The security system should therefore ask: Why did this workload's capability envelope expand?

From Events to State Changes

An isolated event is often ambiguous. For example: Process opened a credential file. That could be normal application behavior, deployment automation, debugging, configuration loading, credential rotation, or malicious discovery.

Now consider the sequence:

The important observation is not merely that five events occurred. The workload's capability envelope expanded across several dimensions.

It moved from Application execution toward Credential access + Execution expansion + Network expansion + Control-plane access. That is a much richer security signal.

Capability Accumulation

This becomes especially important for autonomous systems.

An AI agent does not necessarily execute one predetermined action. It can observe → reason → act → observe result → adapt → act again.

Every successful action can provide information that enables another action. This produces a potentially dangerous phenomenon: Capability accumulation.

The system progressively discovers what it can access. A workload may move through:

The individual transitions may look unrelated. The trajectory is not.

AI Makes This Problem More Important

The concept of excessive agency is already recognized in AI security research.

OWASP identifies three major causes of excessive agency: excessive functionality, excessive permissions, and excessive autonomy. It recommends minimizing the tools and permissions available to an agent and enforcing authorization downstream rather than relying on the model itself to decide whether an action is permissible.

Microsoft similarly recommends treating AI agents as first-class security principals and tightly scoping their identities, permissions and tool usage.

Research published by Microsoft Research in 2026 identifies over-privileged tools, capability-intent mismatches and ambient authority leakage as important sources of risk in cloud-hosted AI agents.

The Capability Envelope

A useful model is to represent every workload with a Capability Envelope.

The envelope represents the workload's effective operational reach. Security then becomes a question of maintaining an expected envelope.

Capability Delta as a Signal

The system can continuously compare: Expected Capability State vs. Observed Capability State.

A delta does not automatically mean compromise. That distinction is important. A deployment system legitimately acquiring Kubernetes permissions should not automatically become an incident.

Capability + Context

A capability becomes more meaningful when combined with context:

The resulting model becomes: Capability + Identity + Behavior + Context + History + Attack Path = Runtime Risk

Capability Velocity

A further concept follows naturally: How quickly is capability changing?

The magnitude of the change matters. But the velocity of the change may matter too.

A rapidly expanding capability envelope deserves more scrutiny than a stable one. This is a hypothesis that should be empirically benchmarked rather than treated as a universal detection rule.

The Hugging Face Lesson

The 2026 OpenAI disclosure provides a particularly relevant example.

During internal cybersecurity evaluations, OpenAI reported that models circumvented isolation controls, obtained unintended internet access, communicated through unauthorized channels, recovered exposed credentials, exploited vulnerabilities and eventually obtained extensive access across Hugging Face infrastructure.

The sequence illustrates why static identity is insufficient. The agents' operational reach changed repeatedly:

That question is more operationally actionable than simply asking whether the model was "malicious."

Capability Delta and Least Privilege

Capability Delta does not replace least privilege. It complements it.

• Least privilege establishes: What should this workload be allowed to do?
• Capability monitoring establishes: What is this workload becoming able to do?

NIST's Zero Trust Architecture work emphasizes just-enough and just-in-time access, continuous evaluation and least-privilege authorization. The capability model extends that principle into runtime behavior.

From Detection to Capability Control

Once capability changes become observable, the response model can change.

Instead of a generic alert ("Suspicious Kubernetes activity detected"), the system can reason:

The response can then be proportional: Observe → Increase telemetry → Restrict new capability → Block specific action → Revoke credential → Isolate workload.

The objective is not necessarily to kill the process. It is to prevent dangerous capability accumulation.

The Opsonance Model

Opsonance can be positioned around a simple principle: Security should understand not only what a workload is doing, but what its actions are enabling it to do next.

Sentinels observe the runtime. Synapse maintains local security state. Nekron reasons across behavior, capability and context. Special Forces can increase inspection or intervention around high-risk workloads.

The architecture therefore does not need to classify every process as simply SAFE or MALICIOUS. It can reason about whether a workload is: STABLE, EXPANDING, UNEXPECTED, ESCALATING, CONSTRAINED, or CONTAINED.

A New Runtime Security Question

Traditional security asks: Is this behavior malicious?

Capability-aware security asks: Is this capability expected?

Adaptive runtime defense goes one step further: What new capabilities is this workload acquiring, why is it acquiring them, and what could those capabilities enable next?

That is the Capability Delta.