Where Security Fits in an AI Agent Stack

Overview

Three frontier labs reported agent boundary escapes within weeks this summer — lab-to-internet paths, unauthorized cross-company access, unsanctioned actions on infrastructure.

If you build orchestration for a living, that sequence should feel familiar. We spend energy on the loop: tools, context, planner graphs, retries. Security often lands next to “system prompt rules” and “tool allowlists.”

That is the wrong layer for authority.

NVIDIA's agent stack breakdown draws the line cleanly:

The harness guides what an agent tries. The infrastructure controls what an agent can do.

Both matter. Only one is authoritative.

The stack people actually ship

The emerging agent stack converges into roughly five layers:

Layer	Role
Distribution / product	How users start and supervise agents
Meta-harness	Multi-agent coordination
Harness	Loop, tools, sessions, context
Secure runtime	Policy on effect paths
Inference / data plane	Model calls and data movement

Capability research keeps pushing the harness upward. NVIDIA's AVO work hitting 100% on ARC-AGI-3 is a reminder: long-horizon agents get better at finding routes the original instructions never anticipated.

That is exactly why a programmable harness is a weak place to put security guarantees. A layer designed to be modified cannot reliably enforce against its own modification.

Behavioral vs infrastructure controls

Split the world into two buckets:

Kind	Examples	Nature
Behavioral	prompts, model safeguards, harness steering, LLM-as-judge	Probabilistic guidance
Infrastructure	runtime policy on files, processes, network, credentials	Deterministic authorization

NVIDIA's AI Red Team is blunt about the first bucket: defenses in the same control plane as the LLM — especially prompt-based defenses — are routinely subverted.

So the rule becomes:

Above proposes. Below decides.

Models, agents, and harnesses propose actions. Runtime and infrastructure authorize them. No layer grants itself authority.

Six gaps that keep showing up

When authorization can be influenced by the agent or by untrusted data, the same holes recur:

• Rules split across prompts, models, harnesses, and infra — nobody owns the boundary
• Standing credentials wider than the current task needs
• Untrusted tool output treated as instructions
• Uncontrolled external effects (egress, file writes, process spawn)
• Compounding delegation failures when agents share memory and call peers
• Incomplete audit evidence when something goes wrong

And the antipattern that quietly undoes the rest: treating the secure runtime as “just another tool” the harness can invoke after launch.

"A control the agent can decline to invoke is not a control."

What this looks like in code

The orchestrator plans. The runtime gates effects. Policy is fixed at launch — not rewritten mid-run by a clever tool call.

// Purpose: harness proposes; runtime authorizes before any side effect
type ProposedAction =
  | { type: "writeFile"; path: string; content: string }
  | { type: "http"; method: string; url: string }
  | { type: "spawn"; cmd: string; args: string[] };

interface RuntimePolicy {
  // Established at launch — not modifiable by the agent mid-run
  allowWrite(path: string): boolean;
  allowEgress(url: string): boolean;
  allowSpawn(cmd: string): boolean;
}

async function execute(
  action: ProposedAction,
  policy: RuntimePolicy,
  audit: (event: object) => void
) {
  switch (action.type) {
    case "writeFile":
      if (!policy.allowWrite(action.path)) {
        audit({ denied: action });
        throw new Error("write denied by runtime policy");
      }
      break;
    case "http":
      if (!policy.allowEgress(action.url)) {
        audit({ denied: action });
        throw new Error("egress denied by runtime policy");
      }
      break;
    case "spawn":
      if (!policy.allowSpawn(action.cmd)) {
        audit({ denied: action });
        throw new Error("spawn denied by runtime policy");
      }
      break;
  }
  audit({ allowed: action });
  return perform(action);
}

The important part is not the switch. It is that policy lives below the agent boundary and cannot be opted out of.

NVIDIA's OpenShell framing is similar: out-of-process policy across network, filesystem, process, and inference — closer to a browser-tab model for agents than another prompt instruction.

Orchestration graphs are not security policy

I've been building orchestration graphs for years. The DAG plans the work. It sequences tools. It retries failed nodes. It does not decide what files get written or what network calls go out.

That is a runtime job. Established at launch. Below the agent boundary.

If you hand a subagent a child scope, give it a child runtime ceiling it cannot exceed — not a longer system prompt that says “please stay in the sandbox.” Graphs coordinate. Runtimes decide.

Design rules that hold

• Nothing above the line grants itself authority
• Policy lives below the agent boundary
• Check every effect path
• Prefer just-in-time access over standing credentials
• Isolate sessions and preserve audit records

What to stop doing

Stop	Why
Securing only the prompt	Same plane as the model — routinely subverted
Allowlists only in harness config	Agent-modifiable layers are not authoritative
Standing API keys in the agent env	Broader than the current task
LLM-as-judge as egress policy	Guidance ≠ authorization
Subagents inheriting parent credentials	Delegation without a ceiling

Takeaway

The future is not “secure the prompt.”

It is above proposes; below decides.

Harnesses and graphs steer what an agent tries. Runtime and infrastructure decide what it can do. If your stack lets the loop skip, rewrite, or politely ignore the security layer, you do not have a security layer — you have a suggestion. Put authorization below the agent boundary, check every effect path, and keep that policy out of the agent's reach.