Academic Paper from 4 Universities Validates the Oktsec Architecture

Researchers from Northeastern University, NYU, UC San Diego, and UIUC published “Agentic AI as a Cybersecurity Attack Surface: Threats, Exploits, and Defenses in Runtime Supply Chains” (Jiang, Yang, Yang, Liu, Ji; accepted at the C4AI4C Workshop @ CAI 2026, arXiv 2602.19555v1). The paper is a systematization of knowledge that formalizes the threat model for agentic AI systems, catalogs known attacks across two supply chains, and proposes a Zero-Trust Runtime Architecture as the defense framework.

Every recommendation in that defense framework maps to a feature Oktsec already ships.

This is not a retroactive claim. The architecture decisions behind Oktsec, from Ed25519 identity to per-agent tool allowlists to runtime content scanning, were made because the threat model the paper now formalizes was already visible in production deployments. When agents assemble their execution context at runtime, when tool selection is probabilistic rather than deterministic, and when agent outputs become inputs for other agents, the security infrastructure has to operate at the same layer. That is what Oktsec does.

The threat model: Stochastic Dependency Resolution

The paper’s central insight is that agentic AI systems create a fundamentally different kind of supply chain. In traditional software, dependencies are declared in lockfiles and resolved at build time. The dependency graph is static. You can audit it, pin it, and reproduce it.

Agents do not work this way. They assemble execution context at runtime through probabilistic decisions. Which tools to invoke, what data to retrieve, how to compose the execution plan: all of these are determined by LLM reasoning on each invocation. The paper calls this Stochastic Dependency Resolution. The attack surface is not fixed at deployment. It shifts with every call.

This leads to the Man-in-the-Environment (MitE) adversary model. The adversary does not need to compromise the model or the infrastructure. They manipulate the environment the agent observes: the data it retrieves, the tools it discovers, the context it reasons over. Because the LLM treats data and instructions equivalently (what the paper terms Prompt-Data Isomorphism), passive data can be upcast to active instructions simply by being present in the context window.

Two supply chains, not one

The paper decomposes the agentic attack surface into two distinct supply chains:

The Data Supply Chain covers everything that enters the agent’s context. This includes indirect prompt injection, in-context learning attacks, knowledge base contamination (PoisonedRAG, AGENTPOISON), and long-term memory poisoning (MINJA). The common thread: adversarial content reaches the agent through legitimate data channels.

The Tool Supply Chain covers the tools agents discover, install, and invoke. The paper breaks this into three phases:

1. Discovery: Hallucination squatting (registering tool names the model is likely to hallucinate) and semantic masquerading (naming tools to exploit similarity-based resolution).
2. Implementation: Hidden backdoors in tool code and transitive dependency exploitation, where a tool’s own dependencies are compromised.
3. Invocation: Over-privileged tool invocation (the tool has more permissions than the agent should) and argument injection (manipulating the parameters passed to a tool).

This decomposition matters because it shows that point solutions are insufficient. Scanning tools at install time does not protect against runtime data poisoning. Scanning prompts does not protect against compromised tool implementations. You need defense across both supply chains simultaneously.

The Viral Agent Loop

The paper’s most important contribution may be the formalization of the Viral Agent Loop: a self-replicating attack cycle where an agent’s output re-enters the system as input for another agent.

In traditional systems, data flows in a directed acyclic graph (DAG). Information moves from source to sink. When the output of one agent becomes the input for another, and that agent’s output feeds back into the first, the topology becomes cyclic. The Morris II worm demonstrated this: adversarial content injected into one agent propagates through the network as each downstream agent processes it, replicates the payload in its own output, and passes it forward. The attack amplifies without further attacker involvement.

This is the pattern that breaks traditional perimeter security. The malicious content does not cross a trust boundary from outside. It originates from within the agent network itself, from a source that was previously trusted. Firewalls, API gateways, and network segmentation do not help when the threat propagates through legitimate agent-to-agent communication channels.

The Viral Agent Loop transforms the agent network from a DAG into a cyclic graph. Traditional security assumes acyclic data flow. When that assumption breaks, every agent becomes both a potential source and a potential sink for adversarial content.

This is precisely why the Oktsec MCP Gateway scans content on both requests and responses. Every message transiting the gateway passes through the full detection pipeline regardless of direction. If adversarial content enters through an agent’s output, the gateway catches it before it reaches the next agent’s input.

What the paper recommends: Zero-Trust Runtime Architecture

The paper proposes a defense framework organized around three pillars:

Pillar 1: Deterministic Capability Binding

Replace semantic similarity with cryptographic registries. When an agent requests a tool, resolution should be deterministic and verifiable, not based on embedding distance. The paper advocates for registry allowlists with cryptographic provenance, where every tool’s identity is verified before execution.

Pillar 2: Neuro-Symbolic Information Flow Control

Apply runtime taint analysis to track data provenance through the agent network. Pair this with cryptographic provenance ledgers so that every piece of data can be traced back to its source. The goal: know where every input came from and what transformations it underwent before reaching a decision point.

Pillar 3: Auditor-Worker Architecture

Separate the agent that performs work from the system that validates it. Semantic firewalls inspect content at trust boundaries. A supervisor model (or system) monitors agent behavior for anomalies. The paper explicitly cites MCP (reference [36]) as a capability-based security protocol and MCP-Guard [37] as a multi-stage defense implementation for this pattern.

The mapping: paper recommendations to Oktsec features

This is the core of the article. The paper’s defense recommendations are not aspirational for Oktsec. They describe shipping features.

Paper recommends	Oktsec implements
Cryptographic provenance, not semantic similarity	Ed25519 identity with message signing on every call
Registry allowlists + cryptographic provenance	Aguara Watch: 42,969 skills monitored across 7 registries
Static scanning before deployment	Aguara Scanner: 153 detection rules (Layer 1)
Runtime content scanning on every call	MCP Gateway: 169 rules, 9-step security pipeline
Capability-based security via MCP	Per-agent tool allowlists defined in YAML policies
Taint tracking (source-to-sink)	Aguara Toxic Flow category: 3 dedicated taint-tracking rules
Defense-in-depth, not point solutions	3-layer architecture: static analysis, process isolation, runtime scanning
Full audit trail	SARIF output and complete audit logging with agent ID, action, verdict, timestamp
Semantic firewalls (Auditor-Worker pattern)	Content scanning on both request and response directions
SLSA/SBOMs for tool integrity	Hash-based rug-pull detection in Aguara Watch
Deterministic tool resolution	Per-agent tool allowlists with no semantic guessing

The alignment is not coincidental. The threat model the paper formalizes is the threat model Oktsec was designed to address. When you start from the premise that agents resolve dependencies stochastically, that data and instructions are isomorphic in an LLM context, and that agent outputs can become agent inputs, you arrive at the same architecture: cryptographic identity, deterministic capability binding, runtime content scanning, and full audit trails.

Mapping the three pillars

Deterministic Capability Binding in Oktsec

The paper argues that semantic similarity for tool resolution is an attack vector. If an agent selects tools based on embedding distance, an adversary can register a malicious tool with a name close enough to the legitimate one to be selected.

Oktsec eliminates this vector entirely. Tool access is governed by YAML policy files that specify exactly which tools each agent can invoke. There is no semantic resolution. There is no embedding distance. Either the tool is on the allowlist or it is denied. This is what the paper calls Deterministic Capability Binding.

On the registry side, Aguara Watch monitors 42,969 skills across 7 public MCP registries. It tracks tool hashes to detect rug-pulls: cases where a tool’s implementation changes after approval. This is the cryptographic provenance the paper advocates, applied to the tool discovery phase.

Neuro-Symbolic Information Flow Control in Oktsec

The paper calls for runtime taint analysis and cryptographic provenance ledgers. In Oktsec, this maps to two features:

• Aguara Toxic Flow rules: Three dedicated detection rules that track taint propagation from source to sink. These identify cases where untrusted input reaches a sensitive operation without sanitization.
• Audit logging: Every message transiting the MCP Gateway is logged with full provenance: agent identity, tool invoked, parameters, content scan verdict, and timestamp. The audit trail is the provenance ledger.

Ed25519 signatures on every message provide the cryptographic binding. You can verify not just that a message was logged, but that it was produced by a specific agent and was not modified in transit.

Auditor-Worker Architecture in Oktsec

The paper proposes separating the entity that performs work from the system that validates it. The MCP Gateway is exactly this separation. Agents (workers) send requests through the gateway (auditor), which applies the full 9-step security pipeline before forwarding to the backend MCP server:

1. Rate limiting
2. Identity verification (Ed25519 signature check)
3. Suspension check
4. ACL enforcement (YAML policy evaluation)
5. Content scanning (169 detection rules)
6. Blocked content filtering
7. Audit logging
8. Anomaly detection
9. Response scanning

The gateway scans both the request (agent to tool) and the response (tool to agent). This bidirectional scanning is what makes it effective against the Viral Agent Loop. Adversarial content in a tool’s response is caught before it reaches the requesting agent and propagates further.

Context: academic validation and enterprise adoption

This paper follows a pattern. In February 2026, NIST published a concept paper on AI agent identity and authorization that mapped to the same Oktsec architecture. Now, independent academic researchers from four universities have arrived at the same conclusions through formal analysis.

Two independent validation signals in the same month matter for enterprise adoption. When a CISO evaluates agent security infrastructure, they need evidence that the approach is grounded in established security principles, not just vendor claims. A NIST concept paper provides policy validation. A peer-reviewed academic systematization provides technical validation. Together, they make the case that the zero-trust runtime approach is not one vendor’s opinion. It is the direction the field is converging on.

The paper also provides precise language for threats that practitioners have been observing informally. “Stochastic Dependency Resolution” gives a name to the problem of agents assembling their context at runtime. “Prompt-Data Isomorphism” explains why indirect prompt injection works at a fundamental level. “Viral Agent Loop” describes the propagation pattern that makes multi-agent systems qualitatively harder to secure than single-agent deployments. This shared vocabulary accelerates adoption because it allows security teams to discuss these threats precisely.

What this means for teams building with agents

If you are deploying AI agents that connect to external tools, this paper describes your threat model. The question is not whether these attacks are possible. The paper catalogs them with citations to working demonstrations. The question is what your defense architecture looks like.

The paper’s answer is a Zero-Trust Runtime Architecture with three pillars: deterministic capability binding, neuro-symbolic information flow control, and an auditor-worker separation. Oktsec is the implementation.

• Static analysis before deployment: Aguara Scanner with 153 rules catches malicious tool implementations before they reach your agents.
• Process isolation: Each MCP server runs in its own sandbox. Compromise of one tool does not propagate to others.
• Runtime scanning on every call: The MCP Gateway applies 169 detection rules on every request and response, catching prompt injection, data exfiltration, and Viral Agent Loop propagation in real time.
• Cryptographic identity: Ed25519 key pairs provide non-repudiable agent identity. Every message is signed. Every signature is verified.
• Complete audit trail: SARIF output for CI integration. Structured logs for compliance. Full provenance for incident response.

The paper is the formalization. Oktsec is the implementation. Both exist today.

Independent academic research from four universities formalizes the exact threat model Oktsec was built to address. Every recommendation in their Zero-Trust Runtime Architecture maps to a shipping feature.

If you are building agents that connect to external tools, this paper describes the threat model. Oktsec is the implementation. The code is open source, the architecture is documented, and the detection rules are public.

We are building this in the open. If you want to talk about agent security architecture, threat models, or how this applies to your deployment, reach out.