Prometheus Project — Architecture

A Five-Layer Architecture for AI Agent Runtime Governance

Most AI security discussion happens before the agent runs. Input validation, system prompt design, model selection. This is the wrong place to put all of your controls.

Casey Gager Prometheus Project 2026
The real attack surface in an agentic system is what happens between the prompt and the action. An agent that passes every pre-flight check can still be redirected mid-task, manipulated into scope creep, or drifted into behavior that looks like compliance and isn't. Runtime governance is the set of controls that exist after the model responds and before the effect lands in the world.

This document describes the five-layer architecture that the Prometheus system uses. Each layer addresses a distinct threat class. The layers are not redundant — removing any one of them opens a gap the others cannot close.

The architecture is implementation-agnostic. The Prometheus reference implementation uses Python, K3s, and a custom policy engine. The layers generalize to any agentic framework.


The Five Layers

In execution order — each layer runs before handing to the next

L1
Input Sanitization and Spotlighting pre-prompt

Indirect prompt injection attacks embed adversarial instructions in data the agent retrieves — documents, tool outputs, external APIs. Spotlighting marks the boundary between trusted instruction and untrusted data so the model can distinguish them. Sanitization strips known injection patterns before retrieval content reaches the model. Neither is sufficient alone: sanitization is pattern-matching against a known-bad list; spotlighting is structural and survives novel attacks.

L2
Session Manifest declared_intent

Every agent session opens with a structured declaration: what task it is performing, what tools it is permitted to use, and what scope it is operating within. The manifest is not a suggestion — it is the authorization record for the session. All downstream controls check against it. An agent that attempts an action outside the declared scope fails at L3 before the action executes. The Prometheus implementation uses a declared_intent annotation pattern injected at session initialization.

L3
Pre-execution Intent Gate DIRA

Before any tool call executes, the agent's stated intent and the actual action are compared against the session manifest. This is Dual-Intent Runtime Authorization (DIRA): verify that the stated reason for an action is consistent with the declared session purpose, and that the action itself is within policy. A file read consistent with the stated task passes. A network call to an external endpoint not in the declared scope is blocked, regardless of how the agent frames it. DIRA is the enforcement point — the gate that every action must pass through.

L4
Runtime Policy Enforcement policy engine

A policy engine evaluates each action against a configurable rule set: data classification, resource limits, rate bounds, privilege constraints. This is not the same as L3. DIRA checks intent alignment; the policy engine checks resource-level constraints independent of intent. An agent with legitimate intent can still violate a data classification policy. An agent within declared scope can still exceed rate limits. L4 catches the class of violations that are policy infractions rather than intent deviations.

L5
Behavioral Drift Detection BDD / Watcher

A single-session view is insufficient. An agent that passes every per-action check in isolation can still exhibit a pattern of behavior — across sessions, across time — that represents a systemic drift from intended operation. Behavioral Drift Detection (BDD) maintains a baseline of expected behavior across dimensions including topic distribution, tool usage patterns, and confidence calibration. Deviation from baseline triggers investigation, not automatic block. The distinction matters: L3 and L4 block actions; L5 surfaces patterns for human review. The Prometheus implementation uses a monthly Watcher analysis pass over session logs.


What Each Layer Addresses

Indirect Prompt Injection

Adversarial instructions embedded in retrieved data. The model follows them because it cannot distinguish instructions from content.

Primary: L1 (Spotlighting) — Secondary: L3 (DIRA catches scope violations)
Scope Creep

The agent expands its operational scope incrementally — each step looks locally reasonable, the aggregate represents a privilege escalation.

Primary: L2 (manifest) + L3 (DIRA enforcement) — L5 catches slow drift
Confused Deputy

A high-privilege agent is manipulated into performing an action on behalf of a lower-privilege caller that the caller could not perform directly.

Primary: L3 (DIRA) + L4 (policy engine privilege checks)
Jailbreak via Framing

The agent is convinced to perform a blocked action by reframing it as something permitted. Intent alignment check is the specific defense.

Primary: L3 (DIRA dual-intent check)
Data Exfiltration

The agent routes sensitive data to unauthorized destinations, either through adversarial direction or misconfigured tool scope.

Primary: L4 (data classification policy) — L2 manifests destination scope
Long-horizon Drift

No single session crosses a threshold. The behavioral pattern across many sessions reveals an accumulating deviation that per-session controls miss.

Primary: L5 (BDD / Watcher) — only layer that can detect this class
Design Principle

The layers are not equivalent. L1–L4 operate per-action and can block. L5 operates across sessions and surfaces for review. Treating L5 as a block mechanism produces false positives at high rates. Treating L1–L4 as a detection mechanism means the action has already executed. The distinction determines how you wire the controls.


What This Architecture Does Not Cover

This is a runtime governance architecture. It does not replace model alignment work, system prompt design, or pre-deployment red-teaming. It assumes those exist and asks: what controls survive when they fail?

It also does not address the supply chain. A compromised tool, a compromised model, or a compromised retrieval source operates inside the trust perimeter. L1 mitigates retrieval manipulation; it does not cover tool or model compromise. That is a separate problem with a separate control set.

Finally: this architecture addresses a single agent. Multi-agent systems — where agents spawn other agents, where trust is delegated across agent boundaries — introduce an authorization problem that a session-scoped manifest cannot fully solve. That is the open research question in the Prometheus project.


References