# AGF — Agentic Governance Framework

> A reference architecture for governed agentic systems.
> Integrates NIST AI RMF, OWASP, CSA, EU AI Act, ISO/IEC 42001,
> OpenTelemetry, Singapore IMDA, MITRE ATLAS, and academic research
> into a single coherent governance framework.
>
> Website: https://agf.jessepike.dev
> GitHub: https://github.com/jessepike/agf

## Pages

- [AGF Documentation](/docs): A reference architecture for governed agentic systems.
- [Composition Patterns](/docs/overview/composition-patterns): Four progressively governed architectures — from Minimum Viable Control to a Full Governed Agentic System. Start with five primitives and grow as stakes demand.
- [The Rings Model](/docs/overview/rings-model): A concentric architecture for governed agentic systems — four rings, one fabric, one substrate.
- [Trust Ladders](/docs/overview/trust-ladders): How agentic systems earn autonomy — a governance pattern for calibrated, evidence-based trust that starts expensive and gets cheaper.
- [What is AGF?](/docs/overview/what-is-agf): The Agentic Governance Framework — a synthesis of NIST, OWASP, CSA, EU AI Act, and academic research into a composable reference architecture.
- [AI Engineering Profile](/docs/profiles/ai-engineering): Which primitives to implement first, and how they compose into governed agentic systems.
- [GRC Profile](/docs/profiles/grc): EU AI Act mapping, NIST alignment, control crosswalks, maturity model, and evidence generation.
- [Observability Profile](/docs/profiles/observability): Event architecture, correlation engine, detection patterns, and operational playbooks for agentic systems.
- [Platform Profile](/docs/profiles/platform): Deployment modes, environment architecture, MCP integration, and cost of governance.
- [Security Profile](/docs/profiles/security): Threat modeling, OWASP mappings, three-level security model, and incident response for governed agentic systems.
- [Decision Intelligence](/docs/reference/decision-intelligence): Governed decision-making systems with structured persistence, belief revision, and multi-agent governance pipelines.
- [Governance Framework](/docs/reference/governance-framework): The top-level operating model — governance functions, agent lifecycle, risk classification, and enterprise integration.
- [Agentic Observability](/docs/reference/observability-concept): The unified monitoring, detection, and response layer — a SIEM pattern for agentic systems.
- [The 19 Primitives](/docs/reference/primitives): Named patterns for governed agentic systems — runtime, lifecycle, and substrate primitives organized into the Rings Model.
- [Architecture Diagrams](/docs/resources/diagrams): Visual reference models for the AGF framework — rings, security, deployment, observability, and more.
- [How the Documents Relate](/docs/resources/relationship-model): The hub-and-spoke architecture of AGF documents and how the concept areas connect.
- [Standards Alignment](/docs/resources/standards-alignment): How AGF maps to NIST, OWASP, CSA, EU AI Act, ISO, OpenTelemetry, Singapore IMDA, and MITRE ATLAS.
- [Shared Vocabulary](/docs/resources/vocabulary): Canonical terminology used across all AGF documents.

## Full Content

---
# AGF Documentation
> A reference architecture for governed agentic systems.
URL: /docs

See: /docs


---
# Composition Patterns
> Four progressively governed architectures — from Minimum Viable Control to a Full Governed Agentic System. Start with five primitives and grow as stakes demand.
URL: /docs/overview/composition-patterns

The nineteen AGF primitives don't all activate at once. They compose into progressively more governed architectures — each stage independently valuable, each stage a foundation for the next.

[Image: Composition Patterns — Progressive Build-Up from Minimum Viable Control to Full Governed System]

Organizations start at Minimum Viable Control and grow toward Full Governed as stakes, scale, and regulatory requirements demand. This is not a binary choice — it is a maturity continuum.

## The Four Patterns

### Minimum Viable Control

**The floor for any consequential agent system.**

Primitives: Bounded Agency (#7) + Identity (#14) + Provenance (#6) + Observability (#10) + Environment Governance (#19, minimal)

What it gives you: agents that can't exceed their scope, actions that are attributable, an audit trail, and scoped operating environments.

This is Ring 0 only — no verification layer yet. But it's more governance than most organizations have today. If you're starting from zero, start here.

### Validation Pipeline

**Ring 0 + Ring 1**

Primitives: Minimum Viable Control + Separation of Producer/Verifier (#1) + Validation Loops (#2) + Structured Output (#5)

What it gives you: verified outputs before release. The fundamental principle — the agent that creates output must not be the sole agent that validates it — becomes structural rather than manual.

The key addition is the [Rings Model's](/docs/overview/rings-model) core insight: Ring 1 provides an independent verification layer that loops until convergence and can challenge as well as confirm.

### Governed Decision Flow

**Ring 0 + Ring 1 + Ring 2**

Primitives: Validation Pipeline + Governance Gates (#8) + Policy as Code (#9) + Transaction Control (#16)

What it gives you: policy-evaluated, human-gateable decisions with side-effect management.

Ring 2 adds two classes of gates:
- **Adaptive gates** relax as agents build a track record through [Trust Ladders](/docs/overview/trust-ladders)
- **Mandatory gates** never relax — irreversible actions, regulatory requirements, and legally mandated reviews always fire

This is the pattern for most regulated enterprise deployments.

### Full Governed Agentic System

**All rings, all primitives, zero trust at every boundary**

Every ring active. Every primitive engaged. The environment optimization loop improving the substrate continuously.

What it gives you: the complete governance architecture for high-stakes, regulated, enterprise-grade agentic systems.

This includes:
- Ring 3 (Learning) observing execution patterns and proposing improvements
- Security Intelligence monitoring trust trajectories and behavioral baselines
- Evaluation & Assurance (#18) running continuous regression
- The self-improving loop: Ring 3 proposes, Ring 2 validates, governance decides

**The invariant across all levels:** The system can suggest governance changes. It cannot enact them autonomously.

## Cost of Governance

Every ring adds overhead. AGF is designed for proportional activation:

| Stakes | Ring Activation | Overhead Multiplier |
|--------|----------------|-------------------|
| Low-stakes task | Ring 0 + minimal Ring 1 | Near-zero |
| Medium-stakes task | Ring 0 + Ring 1 + adaptive Ring 2 | 1.5–3× Ring 0 alone |
| High-stakes decision | All four rings, mandatory gates | 3–5× Ring 0 alone |
| Critical-stakes system | All rings + enhanced Security Intelligence | 5×+ Ring 0 alone |

[Trust Ladders](/docs/overview/trust-ladders) are the primary cost optimization mechanism. As trust builds through demonstrated performance, verification intensity decreases and governance gates relax. The system starts expensive and gets cheaper.

Empirical reference points: policy evaluation overhead at 0.43s total across 7,000+ decisions (~0.06ms per decision, Microsoft AGT); AI gateway routing at 11μs per request at 5K RPS (Bifrost). Governance overhead is measurable and manageable at production scale.

## The Self-Improving Loop

[Image: Implementation Phases Roadmap — from foundational controls through full governed system]

Once Ring 3 is active, AGF is designed to get better over time:

1. **Ring 3 observes** execution patterns across all rings
2. **Ring 3 proposes** improvements — better prompts, tighter thresholds, calibrated trust levels, optimized environment configurations
3. **Ring 2 validates** — governance evaluates whether the proposed change stays within policy
4. **Evaluation & Assurance (#18) tests** — regression suites verify the change doesn't degrade known-good behaviors
5. **The change deploys** — with staged rollout and monitoring

This loop applies to both pipeline performance (Ring 3 improves how agents produce outputs) and the agent operating environment (Ring 3 improves context composition, instruction architecture, and tool provisioning through Environment Governance #19).

## Key Tensions

AGF names seven tensions between primitives with architectural resolutions. Three are central to composition:

**Governance vs. Latency.** More governance means more safety but more latency. Resolution: deployment mode selection. Wrapper mode accepts latency for governance clarity; graph-embedded mode minimizes latency at the cost of audit complexity. The Mode Selection Matrix in the [Reference Architecture](/docs/reference/architecture) is the decision tool.

**Self-Improvement vs. Reproducibility.** Ring 3 makes the system better, but changes make it harder to reproduce past behavior. Resolution: Ring 3 changes go through versioned configuration management. Every configuration state is traceable and reproducible. The system improves forward; it doesn't drift.

**Environment Optimization vs. Governance Integrity.** The environment optimization loop makes agents more effective, but the environment is the control surface. Resolution: separate the optimizable (context priorities, tool descriptions, session policy) from the inviolable (governance policy, authorization boundaries, security constraints). The loop can improve the agent's experience within governance boundaries; it cannot move the boundaries.

## Where to Start

If you are responsible for an agentic system in production today, the practical question is: which pattern are you at?

- **No scope constraints, no attribution, no audit trail** → Start at Minimum Viable Control
- **MVC in place, outputs reviewed manually** → Move to Validation Pipeline
- **Verification structured, governance ad hoc** → Move to Governed Decision Flow
- **Regulated, high-stakes, or autonomous** → Full Governed

Each stage is independently valuable. The goal is not to reach Full Governed as fast as possible — it's to match governance intensity to the stakes of what you're building.

---

*For the complete primitive catalog including all 19 patterns, see the [AI Engineering Profile](/docs/profiles/ai-engineering). For how composition patterns map to regulatory requirements (EU AI Act, NIST AI RMF), see the [GRC Profile](/docs/profiles/governance-risk-compliance).*


---
# The Rings Model
> A concentric architecture for governed agentic systems — four rings, one fabric, one substrate.
URL: /docs/overview/rings-model

Most agentic systems in production today have no structural governance. The agent produces output, and either a human reviews it or nobody does. There's no verification layer, no policy evaluation, no audit trail, and no mechanism for the system to improve over time.

The Rings Model is a vendor-neutral logical architecture that organizes governance into four concentric rings — **Execution, Verification, Governance, and Learning** — plus a cross-cutting fabric and an environment substrate.

[Image: The Rings Model — Governed Agentic Systems]

## The Four Rings

### Ring 0 — Execution

The core agent performs its domain task. It generates text, writes code, makes a recommendation, extracts data, or executes an action. Ring 0 is where the work happens.

Without governance, Ring 0 is all there is. **Most deployed agentic systems today are Ring-0-only.**

### Ring 1 — Verification

A separate process evaluates Ring 0's output against quality criteria. The fundamental principle: **the agent that creates output must not be the sole agent that validates it.**

Ring 1 can loop — sending output back to Ring 0 for revision until it converges on acceptable quality. Ring 1 can also challenge — a dedicated adversarial critique role whose mandate is to find flaws, not confirm quality.

**What Ring 1 answers:** Is this output correct? Is it complete? Does it meet quality standards?

### Ring 2 — Governance

Policy evaluation and authorization. Ring 2 determines whether a verified output should be released, using explicit governance rules (Policy as Code), human-reviewable gates, and organizational policy.

Ring 2 enforces two classes of gates:
- **Adaptive gates** relax as the system proves reliability through [Trust Ladders](/docs/overview/trust-ladders).
- **Mandatory gates** never relax. Irreversible actions, regulatory requirements, and legally mandated reviews always fire, regardless of trust level.

**What Ring 2 answers:** Should this output be released? Does it comply with policy? Who authorized it?

### Ring 3 — Learning

The system improves over time. Ring 3 observes execution patterns, calibrates trust levels, tunes verification thresholds, and proposes configuration changes.

Critically: **Ring 3 proposes. It does not autonomously enact.** All Ring 3 proposals pass through Ring 2 governance and Evaluation & Assurance testing before deployment.

> The box can get smarter inside. It cannot grow itself.

**What Ring 3 answers:** How can the system get better? What should change?

## The Fabric

Cross-cutting infrastructure that makes the rings composable:

- **Structured Output Persistence** — rings communicate through schema-conformant artifacts, not raw text
- **Event-Driven Observability** — every ring emits structured events, creating the shared nervous system
- **Identity & Attribution** — every action carries authenticated identity context through every ring
- **Provenance Chains** — every output carries its full decision history
- **Error Handling & Recovery** — checkpointing at ring boundaries, graceful degradation
- **Security Fabric** — input sanitization, output scanning, containment, identity verification at every boundary

## The Rings Are Logical, Not Physical

This is the key architectural insight. The concentric ring diagram depicts one deployment mode — **wrapper mode**. But the rings are a *logical* architecture. How they manifest physically depends on the system type.

[Image: Ring Deployment Modes — Wrapper, Middleware/Interrupt, and Graph-Embedded]

### Wrapper Mode

Rings literally wrap execution. Sequential: Ring 0 produces → Ring 1 verifies → Ring 2 governs → output releases.

**Best for:** Batch pipelines, document processing, regulatory assessments.

### Middleware / Interrupt Mode

Ring logic fires at specific decision points — tool calls, data access, state mutations. The agent executes continuously; rings intercept at defined boundaries. MCP is the canonical implementation.

**Best for:** Coding agents (Claude Code, Cursor), ops automation, multi-step task agents.

### Graph-Embedded Mode

Verification, governance, and security run concurrently with execution. Speculative execution with a release gate.

**Best for:** Conversational agents, voice assistants, real-time systems.

### Hybrid Is Normal

Systems commonly combine modes. A coding agent operates in middleware mode overall, but within a single response, uses graph-embedded mode for parallel output verification.

## The Signal Protocol

Rings communicate through a standard composability interface — seven signals:

- **PASS** — output accepted, move forward
- **REVISE(quality)** — Ring 1 says "not good enough, try again"
- **REVISE(context)** — Ring 2 says "the world changed, re-execute"
- **HALT** — something is fundamentally wrong, stop
- **GATE** — pause for human authorization
- **DELEGATE** — hand off to another agent with depth tracking
- **ERROR** — something broke; retry, degrade, or halt

This standard contract makes governance rings attachable to any pipeline.

## Starting Simple, Growing Governed

Organizations don't implement all four rings at once:

[Image: Composition Patterns — Progressive Build-Up from Minimum Viable Control to Full Governed System]

**Phase 1 — Minimum Viable Control:** Scope, identity, audit trail. Not even Ring 1 yet — just: the agent can't exceed its scope and actions are attributable.

**Phase 2 — Verification (Ring 0 + Ring 1):** Verified outputs. Quality assurance becomes structural, not manual.

**Phase 3 — Governance (+ Ring 2):** Policy evaluation, human gates, transaction control.

**Phase 4 — Security & Assurance:** Defense in depth, pre-deployment testing, trust calibration.

**Phase 5 — Learning (+ Ring 3):** Self-improvement, memory, environment optimization.

Each phase is independently valuable. Phase 1 alone is more governance than most organizations have today.

## Where This Came From

The Rings Model is not a novel invention. It is a composition of established patterns:

- **Separation of duties** → Ring 1 exists because the producer should not be the sole validator
- **Policy enforcement points** (NIST SP 800-207) → Ring 2 is the PDP, Security Fabric is the PEP
- **Continuous improvement loops** (Deming, SRE) → Ring 3 is the improvement engine
- **Defense in depth** → multiple independent layers, each adding different assurance
- **Proportional controls** → activation intensity matches stakes

The contribution is the composition: pulling them together into a vendor-neutral, composable, adaptable architecture for the agentic context.

**We named it. We didn't invent it.**


---
# Trust Ladders
> How agentic systems earn autonomy — a governance pattern for calibrated, evidence-based trust that starts expensive and gets cheaper.
URL: /docs/overview/trust-ladders

Most organizations deploying agentic systems face a false binary: trust everything and accept the risk, or review everything and accept the cost. Neither works at scale.

**Trust Ladders resolve this tension dynamically.** Agents start with maximum oversight and earn reduced verification through demonstrated performance. Trust builds slowly, degrades fast, and never bypasses mandatory controls.

This is AGF Primitive #11 — operating across Ring 2 (Governance) and Ring 3 (Learning).

## The Core Mechanic

### All agents start at low trust

A new agent — or an existing agent encountering a new task type — begins with full verification. Every output passes through Ring 1. All adaptive governance gates are active. Human reviewers see everything.

This is expensive. That's by design. You haven't earned cheap yet.

### Performance builds trust

As the agent demonstrates reliable performance, trust incrementally increases based on empirical signals:

| Signal | Effect on Trust |
|--------|----------------|
| Consistent Ring 1 verification pass rate | Gradual increase |
| High human gate approval rate | Gradual increase |
| Quality score improvement over time | Gradual increase |
| Stable performance across case types | Gradual increase |

### Higher trust means less overhead

| Trust Level | Verification Intensity | Human Review |
|-------------|----------------------|--------------|
| **Low** (new agent, new context) | Full Ring 1 on every output | All material outputs |
| **Medium** (demonstrated reliability) | Spot checks, sampling | Exceptions and anomalies |
| **High** (proven track record) | Anomaly-triggered only | By escalation only |

### Mandatory controls never relax

This is the critical invariant. Trust Ladders only affect **adaptive** controls — verification intensity, spot-check frequency, routine review gates.

Mandatory controls are trust-independent:

- Irreversible actions always require authorization
- Regulatory gates always fire
- Identity verification runs at every boundary
- Provenance logging never stops

An agent can earn the right to skip a routine quality spot-check. It can never earn the right to skip regulatory approval or execute an irreversible action without authorization.

### Trust degrades faster than it builds

Earning trust takes many successful executions. Losing it takes one significant anomaly.

| Signal | Effect on Trust |
|--------|----------------|
| Ring 1 verification failure | Decrease (proportional to severity) |
| Security Intelligence alert | Significant decrease |
| Behavioral anomaly (deviation from baseline) | Significant decrease |
| Configuration change (new model, new tools) | Reset to lower level until re-evaluated |
| Human override / rejection at gate | Decrease |

### Trust is contextual

A coding agent that has earned high trust for Python development starts at low trust when asked to write infrastructure-as-code for the first time. Trust does not transfer automatically across task types.

Within a trust domain (same organization, same platform), trust context propagates via identity. Across organizational boundaries, trust resets unless explicit federated trust agreements exist.

## Empirical Evidence

Trust Ladders are not a theoretical design pattern. They are empirically validated by real-world data.

**Anthropic agent autonomy research (March 2026):** Analysis of millions of API interactions shows that new users auto-approve 20% of agent sessions; by 750 sessions, auto-approval reaches 40%. Behavioral shift: experienced users move from pre-approval gating to active monitoring. The deployment gap — models can handle 5-hour autonomous tasks, but the 99.9th percentile session runs only 42 minutes — confirms that trust, not capability, is the bottleneck.

**DeepMind Delegation Framework (February 2026):** Tomašev et al. (arXiv 2602.11865) argue delegation must be adaptive — trust builds or degrades based on observed outcomes, not static configuration. Their six delegation components map directly to the Trust Ladder pattern.

**CSA Agentic Trust Framework (February 2026):** The Cloud Security Alliance defines an earned autonomy maturity model — Intern → Junior → Senior → Principal — with explicit promotion criteria and governance sign-off before autonomy escalation. Independent validation of the same pattern from the security community.

**Oversight scaling research (NeurIPS 2025):** Engels et al. demonstrate that oversight efficacy degrades as the capability gap between overseer and system widens. Success rates range from 9.4% to 51.7% depending on task type. This is the fundamental reason Trust Ladders matter: you cannot solve the governance problem with oversight alone.

## Integration with AGF

### The Governance Connection (Ring 2)

Trust levels determine which adaptive gates fire. Low trust: all adaptive gates active. High trust: most adaptive gates relaxed, only mandatory gates and anomalies pause execution. The two-class system — adaptive vs. mandatory — is how Trust Ladders and Governance Gates coexist without conflict.

### The Learning Connection (Ring 3)

Trust calibration operates at two speeds:

- **Slow path (Ring 3):** Systematic trust adjustment based on patterns across many executions. Periodic review cycles. This is how trust climbs — gradually, based on accumulated evidence.
- **Fast path (Sentinels):** Trip wires that fire in near-real-time when specific anomaly patterns occur. Three consecutive failures, sudden quality score drop, cost spike. This is how trust degrades — immediately, not at the next weekly review.

### The Security Connection

Trust manipulation is a recognized attack vector (OWASP ASI09 — Human-Agent Trust Exploitation). An adversarial agent could perform well on monitored tasks to climb the ladder, then exploit reduced oversight.

AGF's Security Intelligence layer monitors for this:
- Anomalous trust trajectory (climbing too fast)
- Novel behavior following trust promotion
- Approval patterns that deviate from baseline post-promotion

Trust anomaly detection monitors the trajectory, not just the current level.

### The Economic Connection

| Governance Model | Cost Over Time | Risk Over Time |
|-----------------|---------------|---------------|
| No governance | Low (constant) | High (constant, undetected) |
| Full governance (no trust) | High (constant) | Low (constant) |
| Trust Ladders | High → decreasing | Low → stable (mandatory controls maintain floor) |

Trust Ladders are the primary cost optimization mechanism for governed agentic systems. The system starts expensive and gets cheaper — the right economic trajectory.

## Implementation Guidance

### What to track

| Metric | Purpose | Cadence |
|--------|---------|---------|
| Ring 1 pass rate (per agent, per task type) | Primary trust signal | Every execution |
| Human gate approval rate | Confirmation signal | Every gate |
| Quality score distribution | Trend signal | Rolling window (7–30 days) |
| Anomaly rate (sentinel triggers) | Degradation signal | Real-time |
| Human override rate and direction | Calibration signal | Every override |

### Trust promotion criteria

Promotion requires convergence across multiple signals — not any single metric:

1. **Sustained performance:** Ring 1 pass rate above threshold for N *consecutive* executions (not just N total)
2. **Approval consistency:** Human approval rate above threshold for gated decisions
3. **No anomalies:** Zero sentinel triggers during the evaluation window
4. **Time-at-level:** Minimum time at current trust level before promotion (prevents gaming through burst performance)
5. **Governance sign-off:** Promotions above a threshold should be logged and auditable — and for critical systems, require explicit authorization

### Trust demotion triggers

Demotion is immediate (not periodic) and proportional to severity:

| Trigger | Demotion Severity |
|---------|------------------|
| Single Ring 1 failure (minor) | One level down, re-evaluation window |
| Multiple Ring 1 failures in window | Two levels down, full verification re-engaged |
| Security Intelligence alert | Reset to low trust, investigation required |
| Configuration change (model, tools) | Reset to previous level, re-earn through evaluation window |
| Behavioral anomaly (baseline deviation) | One–two levels down depending on deviation magnitude |

### What Trust Ladders do not replace

Trust Ladders reduce adaptive oversight. They do not eliminate:

- **Mandatory governance gates** — irreversible actions, regulatory requirements, high-stakes decisions
- **Identity verification** — every action carries authenticated identity regardless of trust
- **Boundary enforcement** — agents cannot exceed their declared scope regardless of trust
- **Provenance logging** — every action is recorded regardless of trust
- **Security monitoring** — Intelligence monitors all agents at all trust levels

## The Broader Principle

Trust Ladders embody a principle that extends beyond agentic AI: autonomy should be earned, not assumed.

This is not a new idea. Human organizations have practiced graduated autonomy for centuries. Junior employees have more oversight than senior ones. New contractors are reviewed more carefully than established partners.

What's new is applying this pattern structurally to autonomous AI systems — with explicit metrics, auditable promotion criteria, automatic demotion on anomaly, and governance controls that prevent gaming. The pattern is old. The application is new. The need is urgent.

---

*Trust Ladders are Primitive #11 in the AGF pattern catalog. For the complete framework including all 19 primitives and the Rings Model, see the [Reference Architecture](/docs/reference/architecture). For how governance gates interact with trust levels, see [Governance Gates](/docs/reference/primitives).*


---
# What is AGF?
> The Agentic Governance Framework — a synthesis of NIST, OWASP, CSA, EU AI Act, and academic research into a composable reference architecture.
URL: /docs/overview/what-is-agf

## The Problem

Agentic systems are proliferating faster than the architectural patterns to govern them.

Organizations are deploying autonomous agents — coding assistants, ops automation, customer-facing chatbots, decision-support systems, multi-agent workflows — at extraordinary pace. Most deployments today are brittle. They work in demos but fail under scrutiny because they lack the structural primitives that make automated action trustworthy, auditable, and improvable.

The governance landscape is fragmented. NIST provides risk management frameworks. OWASP provides threat taxonomies. CSA provides trust frameworks. ISO provides management systems. OpenTelemetry provides observability standards. The EU AI Act provides regulatory requirements.

**Every one of these institutions is doing critical work. These are the dots.** The puzzle pieces are on the table.

## What AGF Does

AGF connects those dots. We synthesize the best thinking from standards bodies, government frameworks, security organizations, academic researchers, and industry practitioners into a single coherent reference architecture.

We are not claiming to have invented new governance concepts. The patterns — separation of duties, least privilege, audit trails, zero trust, policy as code — are battle-tested across distributed systems, security engineering, compliance, and control theory. **The contribution is the composition.**

## Core Architecture

[Image: The Rings Model — Governed Agentic Systems]

### The Rings Model

Four concentric rings organize governance into independent, composable layers:

- **Ring 0 — Execution:** The agent does its work
- **Ring 1 — Verification:** A separate process validates the output
- **Ring 2 — Governance:** Policy evaluation, human gates, authorization
- **Ring 3 — Learning:** The system improves over time (proposes, never autonomously enacts)

Plus a **cross-cutting fabric** (events, identity, provenance, error handling) and an **environment substrate** (governed context, instructions, tools, workspace).

[Learn more about the Rings Model →](/docs/overview/rings-model)

### 19 Named Primitives

AGF defines 19 patterns for governed agentic systems. Not invented — named for the agentic context. They compose into progressively more governed architectures, from Minimum Viable Control to a Full Governed Agentic System.

[See the full primitive catalog →](/docs/profiles/ai-engineering)

### Three-Level Security Model

[Image: Three-Level Security Model]

Security is pervasive, not a single layer:
- **Level 1: Security Fabric** — Enforcement (wire-speed, always active)
- **Level 2: Security Governance** — Policy evaluation (Ring 2)
- **Level 3: Security Intelligence** — Detection (SIEM for agents, dual-speed)

[See the full security architecture →](/docs/profiles/security)

### Three Deployment Modes

[Image: Ring Deployment Modes]

The same logical rings, different physical manifestation:
- **Wrapper** — sequential, highest audit clarity (batch pipelines)
- **Middleware/Interrupt** — governance at decision points (coding agents, MCP)
- **Graph-Embedded** — concurrent, lowest latency (conversational agents)

[See deployment mode details →](/docs/profiles/platform)

## Standards Alignment

| Standard | AGF Coverage |
|----------|-------------|
| **EU AI Act** | Article-level mapping (Art. 6, 9-15, 50) with phased applicability |
| **NIST AI RMF** | AGF as an agentic AI RMF-style profile |
| **OWASP ASI Top 10** | All 10 threats mapped to three-level security model |
| **OWASP MCP Top 10** | All 10 MCP threats mapped to primitives |
| **CSA MAESTRO** | 7-layer threat model mapped to primitives |
| **MITRE ATLAS** | Security architecture aligned to adversarial technique taxonomy |
| **NIST 800-53 / ISO 27001** | Control crosswalks in [GRC Profile](/docs/profiles/grc) |

## Philosophy

- **Humility before authority.** We synthesize, we don't decree.
- **Rigor before opinion.** Every claim grounded in evidence or clearly marked as a proposal.
- **Community over credit.** If this framework helps one organization build a safer agentic system, it has served its purpose.

## Next Steps

- [The Rings Model](/docs/overview/rings-model) — understand the core architecture
- [Trust Ladders](/docs/overview/trust-ladders) — how agents earn autonomy
- [Pick your role](/docs) — find the profile for your professional context


---
# AI Engineering Profile
> Which primitives to implement first, and how they compose into governed agentic systems.
URL: /docs/profiles/ai-engineering

For AI engineers, ML engineers, prompt engineers, and agent developers building agentic systems that need to be governed, auditable, and improvable.

**The key question this profile answers:** *Which primitives do I implement first, and how do they compose into governed systems?*

## The Engineering Challenge

Building an agentic system that works in a demo is straightforward. Building one that is trustworthy, auditable, and improvable in production is a different problem entirely.

1. **Governance must be composable.** You can't implement all 19 primitives at once. You need to know which ones to start with and which to defer.
2. **The architecture must adapt to your system type.** A batch pipeline and a conversational agent have different governance needs. The primitives are the same; the composition is different.
3. **The system must improve without breaking governance.** Self-improvement that weakens verification or bypasses gates is worse than no improvement at all.

## Implementation Priority

[Image: Implementation Phases — Progressive Governance Roadmap]

### Phase 1: Minimum Viable Control (Start Here)

| Primitive | Why First | Effort |
|-----------|----------|--------|
| **#7 Bounded Agency** | Without boundaries, everything else is moot | Low |
| **#14 Identity & Attribution** | Without identity, you can't audit or attribute | Medium |
| **#6 Provenance Chains** | Without provenance, you can't answer "why did it do that?" | Low |
| **#10 Event-Driven Observability** | Without events, you're blind | Low |
| **#19 Agent Environment Governance** (minimal) | Scoped workspace + versioned instructions | Low |

**What this gives you:** Agents that can't exceed their scope, actions that are attributable, an audit trail, and visibility.

### Phase 2: Verification (Ring 0 + Ring 1)

| Primitive | Why Now | Effort |
|-----------|--------|--------|
| **#1 Separation of Producer/Verifier** | Verified outputs before release | Medium |
| **#2 Validation Loops** | Iterative improvement with convergence | Medium |
| **#5 Structured Output Persistence** | The data contract that makes rings composable | Low |
| **#13 Error Handling & Recovery** | Graceful failure when things go wrong | Medium |

**What this gives you:** Verified outputs. Quality assurance is structural, not manual.

### Phase 3: Governance (Ring 0 + Ring 1 + Ring 2)

| Primitive | Why Now | Effort |
|-----------|--------|--------|
| **#8 Governance Gates** | Human oversight on material decisions | Medium |
| **#9 Policy as Code** | Governance rules as versioned, testable artifacts | Medium |
| **#16 Transaction & Side-Effect Control** | Safe handling of irreversible actions | High |
| **#17 Data Governance** | PII, consent, classification at every data flow | High |

**What this gives you:** Policy-evaluated, human-gateable decisions with side-effect management.

### Phase 4: Security & Assurance

| Primitive | Why Now | Effort |
|-----------|--------|--------|
| **#15 Adversarial Robustness** | Defense in depth. Assume breach. | High |
| **#18 Evaluation & Assurance** | The deployment gate. Validates before production. | Medium |
| **#11 Trust Ladders** | Calibrated trust. System earns reduced oversight. | Medium |

### Phase 5: Learning (Full System)

| Primitive | Why Now | Effort |
|-----------|--------|--------|
| **#3 Self-Improving Cycles** | The learning engine | High |
| **#4 Adversarial Critique** | Dedicated challenger for high-stakes outputs | Medium |
| **#12 Memory-Augmented Reasoning** | Persistent knowledge across sessions | Medium |
| **#19 Agent Environment Governance** (full) | The optimization loop for the environment | High |

**Key principle:** Each phase is independently valuable. You don't need Phase 5 to get value from Phase 1.

## The 19 Primitives at a Glance

| # | Primitive | Ring | One-Line Description |
|---|-----------|------|---------------------|
| 1 | Separation of Producer & Verifier | 0+1 | The agent that creates must not be the sole agent that validates |
| 2 | Validation Loops | 1 | Iterative verification until quality met or budget exhausted |
| 3 | Self-Improving Cycles | 3 | System learns from execution history — without retraining |
| 4 | Adversarial Critique | 1 | Dedicated challenger: find flaws, never confirm |
| 5 | Structured Output Persistence | Fabric | Schema-conformant artifacts — the data contract |
| 6 | Provenance Chains | Fabric | Full decision history, immutable, tamper-evident |
| 7 | Bounded Agency | 2 | Explicit, enforced boundaries on scope and authority |
| 8 | Governance Gates | 2 | Execution pauses for authorization |
| 9 | Policy as Code | 2 | Governance rules as versioned, testable objects |
| 10 | Event-Driven Observability | Fabric | Every ring emits structured events |
| 11 | Trust Ladders | 2+3 | Trust earned through performance, not assumed |
| 12 | Memory-Augmented Reasoning | 0+3 | Persistent memory, not just immediate context |
| 13 | Error Handling & Recovery | Fabric | Checkpointing, graceful degradation, compensation |
| 14 | Identity & Attribution | Fabric | Authenticated, inspectable identity on every action |
| 15 | Adversarial Robustness | Security | Assume breach. Defense in depth. Verify explicitly. |
| 16 | Transaction & Side-Effect Control | 0+2 | Pre-commit/commit/post-commit for irreversible actions |
| 17 | Data Governance | 2+Fabric | Classification, consent, PII, lineage, retention |
| 18 | Evaluation & Assurance | Pre-deploy | The gate before the gate — validates before production |
| 19 | Agent Environment Governance | All rings | Governed context, instructions, tools, workspace, memory |

## Composition Patterns

[Image: Composition Patterns — Progressive Build-Up]

| Pattern | Primitives | What It Gives You |
|---------|-----------|------------------|
| **Minimum Viable Control** | #7, #14, #6, #10, #19 (minimal) | Scope, identity, audit trail — the floor |
| **Validation Pipeline** | MVC + #1, #2, #5, #13 | Verified outputs. Structural quality assurance. |
| **Governed Decision Flow** | Pipeline + #8, #9, #16, #17 | Policy-evaluated, human-gateable decisions |
| **Secure Governed System** | GDF + #15, #18, #11 | Defense in depth, pre-deployment validation |
| **Full Governed System** | All 19 primitives | Complete governance that improves over time |

### Application Examples

| System Type | Primary Composition | Deployment Mode |
|-------------|-------------------|----------------|
| Risk decision platform | Governed Decision Flow | Wrapper |
| Coding agent (Claude Code, Cursor) | Validation Pipeline + selective Ring 2 | Middleware/Interrupt |
| Conversational agent | MVC + graph-embedded verification | Graph-Embedded |
| Document processing pipeline | Validation Pipeline → GDF | Wrapper |
| Personal productivity agent | Ring 0 + Ring 3 | Middleware |

## Primitive Interaction Tensions

The primitives are not always harmonious. Seven named tensions with architectural invariants:

| Tension | Conflict | Invariant |
|---------|----------|-----------|
| Self-Improvement vs. Reproducibility | #3 changes behavior; #6 requires traceability | *Always reproducible at a specific version* |
| Trust Ladders vs. Governance Gates | #11 reduces oversight; #8 ensures accountability | *Can skip a spot-check, never regulatory approval* |
| Bounded Agency vs. Self-Improvement | #7 constrains; #3 improves — can it expand itself? | *The box can get smarter inside. It cannot grow itself.* |
| Validation vs. Latency/Cost | #2 improves quality; each pass costs time and money | *Quality bounded by economics, not just capability* |
| Memory vs. Signal-to-Noise | #12 accumulates knowledge; stale memories inject noise | *Growth without curation is hoarding, not learning* |
| Policy as Code vs. Self-Improvement | Can Ring 3 change Ring 2's policy rules? | *Can suggest governance changes, cannot enact them* |
| Environment vs. Governance Integrity | #19 optimizes the environment — but it IS the control surface | *The environment can get better. It cannot get less governed.* |

## Implementation Checklist

### Phase 1: Minimum Viable Control
- [ ] Agent scope defined (tool allowlists, data access boundaries, output authority)
- [ ] Agent identity established (ID, version, configuration hash)
- [ ] Provenance logging active (append-only, structured, includes identity context)
- [ ] Structured events emitted at action boundaries
- [ ] Workspace scoped and instructions versioned

### Phase 2: Verification
- [ ] Separate verification agent operational
- [ ] Validation loops with convergence criteria and iteration budget
- [ ] Structured output schema defined and enforced
- [ ] Error handling: checkpointing at ring boundaries, graceful degradation

### Phase 3: Governance
- [ ] Governance gates operational (adaptive + mandatory classes defined)
- [ ] Policy rules versioned and testable
- [ ] Transaction control for irreversible actions
- [ ] Data classification pipeline active

### Phase 4: Security & Assurance
- [ ] Security posture: defense in depth, supply chain trust policy
- [ ] Evaluation suites: pre-deployment, regression, adversarial testing
- [ ] Trust Ladders: initial levels set, promotion/demotion criteria defined

### Phase 5: Learning
- [ ] Ring 3 learning pipeline operational
- [ ] Memory infrastructure with relevance filtering and curation
- [ ] Full environment optimization loop with termination condition
- [ ] Adversarial Critique: challenger agent for high-stakes outputs


---
# GRC Profile
> EU AI Act mapping, NIST alignment, control crosswalks, maturity model, and evidence generation.
URL: /docs/profiles/grc

For compliance officers, risk managers, auditors, legal/privacy teams, Data Protection Officers (DPOs), and anyone responsible for demonstrating that agentic systems are governed in accordance with regulatory requirements.

**The key question this profile answers:** *How do I prove to a regulator or auditor that my agentic systems are governed?*

## The Compliance Challenge

Regulatory frameworks were designed for traditional AI — static models making predictions with human decision-makers in the loop. Agentic AI breaks these assumptions. Agents select tools, take actions, delegate to other agents, modify their own behavior, and operate at speeds that exceed human oversight capacity.

The compliance challenge for agentic systems has three dimensions:

1. **Accountability is distributed.** When an agent delegates to another agent, which made a tool call that produced a side effect — who is accountable? The deployer? The model provider? The tool provider? Regulatory frameworks demand clear accountability chains that agentic architectures often lack.

2. **Evidence must be structural, not anecdotal.** "We reviewed 50 outputs and they looked fine" is not compliance evidence. Regulators need: continuous logging, traceable decision provenance, testable policy rules, and reproducible governance behavior.

3. **The regulatory landscape is converging but not aligned.** The EU AI Act, NIST AI RMF, Singapore IMDA, CSA frameworks, and ISO standards all address agentic governance from different angles with different vocabularies. Organizations operating globally need a unified architecture that satisfies multiple regulatory frameworks simultaneously.

AGF addresses all three: clear accountability via Identity & Attribution (#14) and Provenance Chains (#6), structural evidence via Event-Driven Observability (#10) and auditable gates, and multi-framework alignment through explicit regulatory mappings.

## EU AI Act Alignment

The EU AI Act provides the most comprehensive regulatory framework for AI systems. AGF maps to its requirements at the article level.

**Applicability timing (as of March 2026):** Prohibitions and GPAI obligations have applied since 2 February and 2 August 2025 respectively. High-risk system obligations (Art. 6, 9–15) become applicable 2 August 2026. Organizations should begin preparation now.

### High-Risk System Requirements (Articles 6, 9–15)

| Article | Requirement | AGF Mapping | Evidence Produced |
|---------|------------|-------------|-------------------|
| **Art. 6 — Classification** | Rules for classifying AI systems as high-risk | Risk classification → ring activation intensity. High-risk = full ring stack activation. | Classification decision record, ring activation policy |
| **Art. 9 — Risk management** | Risk management system throughout lifecycle | Three-level security model + risk-based ring activation | Security architecture documentation, ring configuration records |
| **Art. 10 — Data governance** | Data collection, preparation, bias examination | Data Governance & Confidentiality (#17) — classification, lineage, consent, retention | Data classification records, consent logs, lineage traces |
| **Art. 11 — Technical documentation** | Complete documentation enabling conformity assessment | Provenance Chains (#6) + versioned control-plane state | Full provenance chain for any output, configuration version history |
| **Art. 12 — Record-keeping** | Automatic recording of events relevant to risk identification and monitoring | Event-Driven Observability (#10) + Provenance Chains (#6) | Structured event logs, ring boundary events, gate decision records |
| **Art. 13 — Transparency** | Sufficient transparency for deployers to interpret output and detect anomalies | Identity & Attribution (#14) — full identity context on every action. Provenance chains, confidence signals, gate decision explanations. | Identity context records, decision explanation artifacts |
| **Art. 14 — Human oversight** | Ability to understand capabilities/limitations, monitor operation, intervene/interrupt/halt | Governance Gates (#8) with human interface requirements — evidence presentation, counterfactual framing, rubber-stamping detection. | Gate decision logs, human intervention records, halt/containment records |
| **Art. 15 — Accuracy, robustness, cybersecurity** | Resilience against data poisoning, adversarial examples, model manipulation, supply chain exploitation | Adversarial Robustness (#15) + Security Architecture + Evaluation & Assurance (#18) | Security test results, red team reports, evaluation suite outcomes |
| **Art. 50 — Transparency obligations** | Users informed they are interacting with AI; disclosure for AI-generated content | Identity & Attribution (#14) — AI-system identification. Provenance Chains (#6) for content provenance. | AI identification disclosure records, content provenance records |

### General-Purpose AI Model Obligations (Articles 51–56)

Most agentic systems are built on general-purpose AI models (GPT, Claude, Gemini, etc.). GPAI obligations have applied since **2 August 2025**.

| Article | Requirement | AGF Relevance |
|---------|------------|--------------|
| **Art. 53 — GPAI provider obligations** | Documentation, adversarial testing, copyright compliance | AGF does not address GPAI provider obligations directly. Verify provider compliance and maintain evidence of provider documentation. |
| **Art. 55 — Systemic risk obligations** | Additional obligations for GPAI models with systemic risk (compute >10²⁵ FLOPs) | AGF's Evaluation & Assurance (#18) and Security Architecture support but do not fully satisfy these obligations. |

**Coverage boundary:** AGF governs how organizations deploy and operate agentic systems built on GPAI models. Organizations have a dual compliance obligation: GPAI model compliance (provider responsibility) AND high-risk system compliance (deployer responsibility) when the agent system qualifies as high-risk.

**What AGF does NOT cover:** Art. 43 (conformity assessment procedures), Art. 73 (serious incident reporting), Art. 72 (post-market monitoring), Art. 26 (log retention ≥6 months). These are organizational/regulatory processes. AGF provides the technical evidence substrate these processes require.

### Human Oversight: An Honest Constraint

Art. 14 requires effective human oversight. AGF's honest position: oversight is necessary but its efficacy degrades as the capability gap between overseer and system increases (Engels et al., NeurIPS 2025). AGF addresses this by investing in structural guarantees — rings, verification layers, automated policy enforcement — that function whether or not the human overseer catches every issue.

For compliance purposes: document both the human oversight mechanisms (gates, review interfaces, override capabilities) AND the structural safeguards (automated verification, containment, policy enforcement) that supplement human oversight.

## NIST AI RMF Alignment

AGF primitives constitute an **agentic AI RMF-style profile** — runtime mechanisms that partially address aspects of NIST AI RMF functions in the agentic context.

| NIST Function | Scope (NIST) | AGF Covers | AGF Does NOT Cover |
|---------------|-------------|-----------|-------------------|
| **GOVERN** | Establish and maintain organizational AI risk governance | Ring 2 runtime governance: policy evaluation, gate decisions, delegation authority, Policy as Code (#9) | Organizational risk culture, legal compliance processes, external stakeholder engagement, DEI governance |
| **MAP** | Context framing, risk identification, categorization | Risk classification + ring activation intensity. Risk tier decision tree. | Broader stakeholder analysis, societal impact assessment beyond runtime classification |
| **MEASURE** | Quantify, monitor, assess AI risks | Evaluation & Assurance (#18) for pre-deployment. Ring 1 verification + Event-Driven Observability (#10) for runtime. | Organizational risk quantification, bias measurement, fairness metrics beyond runtime |
| **MANAGE** | Allocate resources, plan responses, manage risks | Trust Ladders (#11) + Bounded Agency (#7) for runtime risk management. Error Handling (#13) for recovery. | Organizational response planning, stakeholder communication, appeal mechanisms, decommissioning |

### NIST IR 8596 (Cybersecurity AI Profile)

Maps AI agent security onto NIST CSF 2.0's six functions:

| IR 8596 Focus Area | AGF Mapping |
|-------------------|-------------|
| **Securing AI Systems** | Security Fabric + Identity & Attribution (#14) |
| **AI-Enabled Cyber Defense** | Security Intelligence + Security Response Bus with human oversight |
| **Thwarting AI-Enabled Attacks** | Adversarial Robustness (#15) |

Key alignment: IR 8596 treats AI agents as security-relevant entities requiring unique identity and agent-specific security controls — not just applications. This validates AGF's position that agent identity must be first-class.

## Singapore IMDA Alignment

The IMDA Model AI Governance Framework for Agentic AI (January 2026) — the world's first government-published governance framework specifically for agentic AI.

| IMDA Dimension | Description | AGF Mapping |
|---------------|-------------|-------------|
| **1. Risk Assessment & Bounding** | Restrict tool access, sandbox environments, fine-grained permissions | Bounded Agency (#7) + Security Fabric + Agent Environment Governance (#19) workspace scoping |
| **2. Accountability & Human Oversight** | Defined roles, HITL for high-stakes/irreversible actions, automation bias safeguards | Governance Gates (#8) + human interface requirements (evidence presentation, rubber-stamping detection) |
| **3. Technical Controls & Testing** | Output accuracy, tool usage validation, policy compliance, gradual rollout | Evaluation & Assurance (#18) + Ring 1 verification |
| **4. End-User Responsibility** | User training, transparency on agent permissions, active stewardship | Identity & Attribution (#14) transparency requirements |

IMDA explicitly includes "operational environments" as a governance dimension — directly validating Agent Environment Governance (#19).

## CSA MAESTRO Alignment

The MAESTRO 7-layer threat model mapped to AGF primitives:

| MAESTRO Layer | AGF Primary Primitives | Ring Mapping |
|---------------|----------------------|--------------|
| L1: Foundation Models | Adversarial Robustness (#15), Evaluation & Assurance (#18) | Ring 0 |
| L2: Data Operations | Data Governance (#17), Memory-Augmented Reasoning (#12) | Ring 0 + Fabric |
| L3: Agent Frameworks | Composability Interface, Bounded Agency (#7), Policy as Code (#9), Agent Environment Governance (#19) | Ring 1 + Ring 2 |
| L4: Deployment Infrastructure | Identity & Attribution (#14), Transaction Control (#16), Agent Environment Governance (#19) | Security Fabric |
| L5: Evaluation & Observability | Event-Driven Observability (#10), Validation Loops (#2), Evaluation & Assurance (#18) | Ring 1 + Ring 3 |
| L6: Security & Compliance | Governance Gates (#8), Policy as Code (#9), Trust Ladders (#11) | Ring 2 |
| L7: Agent Ecosystem | Multi-Agent Coordination, Cross-System Trust, DELEGATE signal | Ring 2 + Cross-cutting |

## Governance Evidence: What Each Primitive Produces

For auditors: every AGF primitive produces specific, auditable artifacts.

| Primitive | Evidence Artifact | Regulatory Mapping |
|-----------|------------------|-------------------|
| **#1 Separation of Producer/Verifier** | Verification decision records (pass/revise/fail per output) | Art. 15 (accuracy), NIST MEASURE |
| **#6 Provenance Chains** | Full decision history for any output — every agent, model, decision, input, context | Art. 11 (documentation), Art. 12 (record-keeping) |
| **#7 Bounded Agency** | Scope definition records, boundary enforcement logs, escalation records | Art. 9 (risk management), IMDA Dim. 1 |
| **#8 Governance Gates** | Gate trigger records, evidence packages, human decision records, override logs | Art. 14 (human oversight), IMDA Dim. 2 |
| **#9 Policy as Code** | Versioned policy rules, policy test results, policy change audit trail | Art. 9, NIST GOVERN |
| **#10 Event-Driven Observability** | Structured event logs from all rings, correlation records | Art. 12 (record-keeping), NIST MEASURE |
| **#11 Trust Ladders** | Trust level history, promotion/demotion records, calibration justifications | NIST MANAGE, CSA ATF |
| **#14 Identity & Attribution** | Agent identity records, delegation chains, authentication logs | Art. 13 (transparency), Art. 50 |
| **#17 Data Governance** | Data classification records, consent logs, PII handling logs, retention/deletion records | Art. 10 (data governance), GDPR |
| **#18 Evaluation & Assurance** | Pre-deployment test results, red team reports, regression suite outcomes | Art. 15 (accuracy/robustness), NIST MEASURE |
| **#19 Agent Environment Governance** | Environment composition records, instruction version history, tool provisioning logs | IMDA Dim. 1 (operational environments) |

## Governance Gates and Human Oversight

Governance Gates (#8) are the primary mechanism for human-in-the-loop oversight in AGF.

### How Gates Work

1. Execution reaches a defined decision point (Ring 2 determines a gate is required)
2. Execution **pauses** — the output, context, and evidence are frozen
3. A human reviewer sees: the output, the provenance chain, the policy evaluation, and the risk classification
4. The reviewer decides: **APPROVE**, **REJECT**, **MODIFY**, **DEFER**, or **ESCALATE**
5. The decision is recorded with full provenance (who decided, when, what evidence was presented, what they decided)

### Human Interface Requirements

AGF specifies requirements for how gates present information to human reviewers:

- **Evidence presentation** — the reviewer sees structured evidence, not raw data
- **Counterfactual framing** — "what would happen if you approve vs. reject"
- **Rubber-stamping detection** — if a reviewer approves too quickly or too uniformly, Intelligence flags it
- **Timeout behavior** — fail-closed by default (if no decision within the window, execution halts)
- **Cognitive load management** — batch approval rules for routine decisions, escalation for novel ones
- **Cooling-off periods** — rate limits on approval requests to prevent fatigue exploitation

## Policy as Code

Governance rules are code — versioned, tested, deployed, and auditable. This is the foundation of structural compliance.

**What Policy as Code gives you:**

- **Auditability:** Every policy rule is a versioned artifact. Regulators can inspect what rules governed a decision at any point in time.
- **Testability:** Policy rules have unit tests. You can verify "this rule would have blocked X" before deploying it.
- **Change audit trail:** Every policy change is a commit with author, timestamp, and justification.
- **Reproducibility:** Same policy + same input = same decision. No human judgment variation.

**What it does NOT give you:** Correctness of the policy itself. Well-formed Policy as Code can still encode incorrect, biased, or incomplete governance rules. Human review of policy content — not just policy mechanics — remains essential.

## Governance Maturity Model

| Level | Name | Characteristics |
|-------|------|-----------------|
| **1 — Ad Hoc** | No structured governance | Manual review, no logging, no policy enforcement |
| **2 — Reactive** | Basic controls | Bounded Agency (#7), Identity (#14), basic event logging |
| **3 — Managed** | Structured governance | Full Ring 1 verification, Policy as Code (#9), Governance Gates (#8), Provenance Chains (#6) |
| **4 — Measured** | Data-driven governance | Trust Ladders (#11) calibrated from empirical data, behavioral baselines, anomaly detection |
| **5 — Optimizing** | Self-improving governance | Self-Improving Cycles (#3), Environment Optimization Loop, Ring 3 driving policy updates |

**For EU AI Act high-risk compliance:** Level 3 is the minimum. Levels 4–5 represent best practice for high-stakes domains.

## Compliance Assessment Checklist

**Accountability:**
- [ ] Agent identity traceable to deployment configuration (Identity & Attribution #14)
- [ ] Delegation chains bounded and auditable
- [ ] Human decision records for all gate resolutions

**Evidence infrastructure:**
- [ ] Structured event log from all ring boundaries (#10)
- [ ] Provenance chain complete for every material output (#6)
- [ ] Policy rules versioned and in source control (#9)
- [ ] Pre-deployment evaluation suite documented (#18)

**EU AI Act (if high-risk):**
- [ ] Risk classification documented and mapped to ring activation policy (Art. 6)
- [ ] Data governance records — classification, consent, lineage (Art. 10)
- [ ] Human oversight mechanisms documented (Art. 14)
- [ ] Technical documentation sufficient for conformity assessment (Art. 11)

**NIST AI RMF:**
- [ ] Runtime governance coverage documented (GOVERN)
- [ ] Risk classification and ring activation policy (MAP)
- [ ] Evaluation suite with quantitative metrics (MEASURE)
- [ ] Trust Ladders and escalation procedures (MANAGE)

---

*Related: [Security Profile](/docs/profiles/security) — threat defense architecture. [Observability Profile](/docs/profiles/observability) — evidence collection and operational monitoring. [Platform Profile](/docs/profiles/platform) — deployment infrastructure underpinning the evidence substrate.*


---
# Observability Profile
> Event architecture, correlation engine, detection patterns, and operational playbooks for agentic systems.
URL: /docs/profiles/observability

For SREs, SOC analysts, detection engineers, and platform reliability engineers responsible for monitoring, detecting threats in, and responding to incidents involving autonomous AI agents in production.

**The key question this profile answers:** *How do I see what my agents are doing and respond when they misbehave?*

**Scope boundary:** This profile covers runtime operations — monitoring, detection, correlation, and response. Infrastructure deployment belongs to the [Platform Profile](/docs/profiles/platform). Threat modeling belongs to the [Security Profile](/docs/profiles/security). Regulatory evidence generation belongs to the [GRC Profile](/docs/profiles/grc).

## The Observability Challenge

Agent systems are not applications. Applications do what they're told. Agents reason, choose tools, take actions, delegate to other agents, and modify their own behavior over time. Every one of these capabilities introduces failure modes and attack vectors that infrastructure observability — latency, errors, throughput — cannot see.

The observability challenge for agentic systems has three dimensions:

1. **Agent events are not infrastructure events.** Infrastructure observability tells you if the system is running. Agent observability tells you if the system is *behaving within governance boundaries*. "Ring 0 executed in 3 seconds" is infrastructure. "Ring 1 verified the output, Ring 2 authorized the action, and the provenance chain is complete" is agent observability.

2. **Three detection domains share one event stream.** Quality failures, security incidents, and governance violations often share the same event evidence. A quality degradation pattern might be a security attack. A compliance anomaly might indicate a compromised agent. Separating these into different tools loses critical correlation signal.

3. **Correlation, not just collection.** Raw event collection is necessary but not sufficient. The value is in correlation: three agents all bypassing quality gates in the same week. A gradual trust escalation followed by an anomalous high-stakes output. Cost per execution trending up 40% over a month. The correlation engine transforms a log store into an intelligence system.

## The SIEM Pattern for Agents

Traditional SIEM (Security Information and Event Management) ingests security events from infrastructure and applies correlation rules, playbooks, and forensic investigation to detect and respond to threats.

Agentic Observability applies the same pattern, but with different event sources:

| Traditional SIEM | Agentic Observability |
|-----------------|----------------------|
| Firewall logs, endpoint events | Ring boundary events, tool calls, gate decisions |
| Network authentication | Agent identity verification, delegation chains |
| File integrity monitoring | Provenance chain integrity, evidence tampering |
| User behavior analytics | Agent behavioral baselines, trust trajectories |
| Incident response playbooks | Governance response playbooks (quarantine, trust degradation, containment) |

The threats are different too. Not unauthorized network access — but **ungoverned autonomous action, adversarial manipulation, quality degradation, policy violations, and trust manipulation.**

The architecture is the same: **structured event ingestion → correlation rules → detection → response playbooks → forensic investigation.**

## Three Detection Domains, One Event Stream

[Image: Event Flow and Observability — unified stream feeding three detection domains]

The unified event stream feeds three detection domains. Separating them into different tools loses critical correlation signal.

### Quality Detection (Ring 3 Intelligence)

**Monitors:**
- Verification pass/fail rates by agent, task type, document type
- Human override patterns (which fields, which directions, which agents)
- Convergence speed (validation loop iterations to pass)
- Quality score distributions and trends
- Cost and latency per ring, per agent, per task type

**Produces:**
- Trust ladder adjustments (empirical, data-driven)
- Prompt improvement recommendations (from override patterns)
- Threshold recalibration signals (from false positive analysis)
- Anomaly alerts (sentinel fast path for immediate trust degradation)

### Security Detection (Cross-cutting)

**Monitors:**
- Ring bypass attempts (outputs without expected verification events)
- Trust manipulation trajectories (building trust on low-stakes for high-stakes exploitation)
- Evidence integrity anomalies (source authentication failures, provenance tampering)
- Memory poisoning indicators (compromised data entering Ring 3)
- Prompt injection patterns (adversarial content altering behavior)
- Identity anomalies (delegation chain inconsistencies, unexpected model changes)
- Cross-pipeline poisoning (compromised Pipeline A output feeding Pipeline B)

**Produces:**
- Immediate trust degradation on anomaly detection (sentinel fast path)
- Quarantine of affected outputs pending investigation
- Forensic investigation packages (event timeline, provenance walkback, identity trace)
- Incident response playbook triggers
- Security posture dashboards

### Governance Detection (Compliance)

**Monitors:**
- Policy compliance rates across all Ring 2 evaluations
- Mandatory gate activation (was every required gate triggered?)
- Transaction lifecycle completeness (pre-commit → commit → confirm)
- Approval freshness (stale approvals relative to context changes)
- Provenance chain completeness (gaps in the evidence → decision trace)

**Produces:**
- Audit packages: complete governance evidence for a scope (time range, agent, case type)
- Regulatory evidence: documentation for EU AI Act, NIST AI RMF, ISO 42001
- Compliance dashboards: policy violation rates, gate compliance, provenance coverage

## Event Architecture

### The Event Envelope

Every material agent action emits an event with a common schema. The envelope is the atomic unit of agentic observability.

```
Event Envelope:
  event_id:           Unique event identifier
  timestamp:          When the event occurred

  # Identity context (#14 — travels with every event)
  actor_type:         agent | human | system
  actor_id:           Specific agent instance or human
  actor_version:      Agent configuration version / config hash
  model_id:           Which model, version, provider
  delegation_chain:   Who authorized this actor, under what authority
  tenant_id:          Whose data scope

  # Action context
  action_type:        What happened (from event taxonomy)
  target_type:        What was acted upon
  target_id:          Specific target
  previous_state:     State before the action
  new_state:          State after the action

  # Governance context
  ring:               Which ring (R0, R1, R2, R3)
  deployment_mode:    wrapper | middleware | graph_embedded
  policy_reference:   Which policy rule was evaluated
  gate_type:          mandatory | adaptive | none

  # Quality context
  confidence:         Confidence score (if applicable)
  provenance_link:    Link to the provenance chain node

  # Correlation context
  case_id:            Decision case / assessment / workflow
  run_id:             Specific execution run
  session_id:         Session context
  parent_event_id:    Causal link to triggering event
```

### Event Taxonomy

Events classified by ring, mapping to the three detection domains:

**Execution events (Ring 0):**
- `agent_started`, `agent_completed`, `agent_failed`
- `tool_called`, `tool_returned`, `tool_failed`
- `output_produced`, `output_validated_schema`

**Verification events (Ring 1):**
- `verification_started`, `verification_completed`
- `validation_loop_iteration`, `validation_loop_converged`, `validation_loop_exhausted`
- `adversarial_critique_started`, `adversarial_critique_completed`
- `finding_produced` (severity, field, finding_type)
- `revise_quality_issued`

**Governance events (Ring 2):**
- `policy_evaluated`, `policy_passed`, `policy_violated`
- `gate_triggered` (gate_type: mandatory | adaptive)
- `gate_resolved` (resolution: approve | reject | modify | defer | escalate)
- `provenance_recorded`
- `revise_context_issued`
- `transaction_pre_commit`, `transaction_committed`, `transaction_confirmed`
- `approval_granted`, `approval_expired`, `approval_invalidated`

**Learning events (Ring 3):**
- `trust_level_changed` (direction: increased | decreased | reset)
- `sentinel_triggered` (fast path anomaly detection)
- `improvement_recommended`, `improvement_applied`, `improvement_rolled_back`
- `memory_written`, `memory_queried`, `memory_pruned`

### OpenTelemetry Alignment

AGF event architecture aligns with the OpenTelemetry GenAI semantic conventions. Key mappings:

| OTel GenAI Attribute | AGF Event Field | Notes |
|---------------------|----------------|-------|
| `gen_ai.system` | `model_id.provider` | Model provider |
| `gen_ai.request.model` | `model_id.model` | Specific model |
| `gen_ai.usage.input_tokens` | Ring 0 execution event | Per-call token accounting |
| `gen_ai.operation.name` | `action_type` | What the agent did |

AGF extends OTel with governance-specific fields (ring, gate_type, policy_reference, delegation_chain) that the base GenAI conventions don't cover.

## Correlation Engine

Raw events are necessary but not sufficient. The correlation engine is where events become intelligence.

### Correlation Rule Examples

**Trust manipulation detection:**
```
DETECT: trust_escalation_then_anomaly
  PATTERN:
    - trust_level_changed(direction: increased) × N times over T days
    - followed by: high_stakes_action OR policy_violated
  THRESHOLD: N ≥ 3, T ≤ 14 days
  RESPONSE: immediate trust degradation, forensic investigation trigger
```

**Ring bypass detection:**
```
DETECT: verification_gap
  PATTERN:
    - output_produced in Ring 0
    - NO verification_completed for same run_id within T seconds
    - output released
  THRESHOLD: T = 30s
  RESPONSE: quarantine output, alert security, flag for audit
```

**Cross-pipeline poisoning:**
```
DETECT: cross_pipeline_contamination
  PATTERN:
    - agent_failed OR policy_violated in Pipeline A
    - output from Pipeline A used as input in Pipeline B within T hours
    - Pipeline B produces output without verification_completed
  RESPONSE: quarantine Pipeline B outputs, trigger forensic walkback
```

**Approval fatigue exploitation:**
```
DETECT: rubber_stamping
  PATTERN:
    - human reviewer: approval rate ≥ 95% over last N decisions
    - OR: median approval time < 10 seconds
    - AND: at least one high_stakes_action in approved set
  RESPONSE: flag reviewer, escalate to second reviewer, alert management
```

### Dual-Speed Architecture

The correlation engine runs at two speeds:

**Fast path (sentinels) — sub-second:**
- Known-pattern matching against pre-defined threat signatures
- Triggers Security Response Bus for pre-authorized containment actions
- Outputs: immediate trust degradation, quarantine signals, real-time alerts

**Slow path (analysis) — hours to days:**
- Cross-execution pattern analysis across full event history
- Behavioral drift modeling (how is this agent's behavior changing over time?)
- Memory evolution tracking (what has Ring 3 learned, and is it drifting?)
- Outputs: trend reports, Trust Ladder calibration signals, policy improvement recommendations

## Operational Playbooks

### Playbook: Behavioral Anomaly Detected

**Trigger:** Sentinel detects behavioral deviation exceeding threshold.

1. **Immediate (automated):** Trust level decremented. Outputs from current session quarantined pending review.
2. **Within minutes (SOC):** Review sentinel alert. Check provenance chain for anomalous action. Confirm quarantine scope is correct.
3. **Investigation:** Pull full event timeline for affected agent. Check for trust manipulation trajectory (slow path correlation). Identify entry point of anomaly.
4. **Containment decision:** If confirmed attack → isolate agent, preserve forensic state, trigger incident response. If false positive → restore trust level, update sentinel threshold, document false positive.

### Playbook: Provenance Chain Gap

**Trigger:** Governance detection flags output with incomplete provenance.

1. **Immediate (automated):** Output flagged, release blocked pending investigation.
2. **Investigation:** Identify which ring boundary produced the gap. Check for ring bypass pattern (verification_gap correlation rule).
3. **Root cause:** Config error → fix and re-process. Active bypass attempt → escalate to security, treat as ring bypass incident.
4. **Resolution:** Either complete provenance chain (if recoverable) or reject output and log the gap as a governance violation.

### Playbook: Cross-Pipeline Contamination Suspected

**Trigger:** Cross-pipeline poisoning correlation rule fires.

1. **Immediate:** Quarantine all downstream pipeline outputs that used upstream compromised output as input.
2. **Scope:** Use provenance chains to trace all derivations of the contaminated output. Identify full blast radius.
3. **Investigation:** Review upstream failure. Determine if contamination was adversarial or accidental.
4. **Remediation:** Reject contaminated outputs. Re-process from last known-good checkpoint. Review cross-pipeline data flow policy.

### Playbook: Human Oversight Fatigue

**Trigger:** Rubber-stamping detection fires for a reviewer.

1. **Immediate:** Route pending approvals to a second reviewer. Do not alert the fatigued reviewer — this prevents manipulation.
2. **Review:** Audit recent approvals by the flagged reviewer. Check if any high-stakes actions were waved through without adequate review.
3. **Intervention:** If approvals were inadequate → re-review high-stakes decisions. Notify management.
4. **Prevention:** Adjust approval queue rate limits. Implement mandatory cooling-off periods. Review cognitive load on this reviewer's queue.

## Zero Trust Monitoring

Observability itself must operate under zero trust assumptions. The monitoring infrastructure is a high-value target.

**Principles:**

- **Event integrity:** Events are signed at emission. Correlation engine verifies signatures before processing. Tampered events are flagged, not silently dropped.
- **Monitor the monitors:** Ring 1 verification applies to the Intelligence layer itself. Behavioral anomalies in the monitoring system trigger escalation.
- **Separation of evidence:** Forensic evidence stores are append-only, write-once. The correlation engine reads but cannot modify.
- **Dead-man's switches:** If the correlation engine stops producing output for T minutes, automatic alerts fire — silence is itself a signal.

## Observability Maturity Model

| Level | Name | Capabilities |
|-------|------|-------------|
| **1 — Blind** | No structured observability | Log files only, no structured events, no correlation |
| **2 — Visible** | Basic event collection | Structured events at ring boundaries, basic dashboards, manual incident response |
| **3 — Monitored** | Active detection | Behavioral baselines, sentinel fast path, governance compliance dashboards, documented playbooks |
| **4 — Intelligent** | Correlated intelligence | Dual-speed correlation engine, cross-pipeline detection, Trust Ladder auto-calibration from observability data |
| **5 — Autonomous** | Self-improving observability | Ring 3 drives threshold recalibration, correlation rules evolve from observed patterns, playbooks update from post-incident analysis |

**For EU AI Act high-risk systems:** Level 3 is the minimum for Art. 12 compliance. Level 4 is recommended for high-throughput or high-stakes systems where manual correlation is insufficient.

## What This Is NOT

Agentic observability as described here is an architecture pattern, not a product. As of March 2026:

- **No single platform implements the full stack.** Commercial platforms (LangSmith, Arize, Braintrust, Helicone) cover quality monitoring. Security SIEMs (Splunk, Sentinel) cover security events. GRC tools cover compliance. The unified approach described here requires integration or custom implementation.
- **Behavioral baselines require data.** You cannot detect deviation until you have established what "normal" looks like. New agents have no baseline.
- **Correlation rules require tuning.** Generic rules produce false positives. Effective correlation requires domain-specific calibration.
- **The EDR pattern for agents is early.** Memory introspection and state inspection tooling for agentic systems is nascent. The pattern is clear; the tooling is immature.

## Operations Checklist

**Event collection:**
- [ ] Structured event emission from all ring boundaries
- [ ] Common event envelope schema deployed
- [ ] Event signing at emission (integrity verification)
- [ ] Append-only forensic evidence store

**Detection:**
- [ ] Behavioral baseline established per agent (requires ≥2 weeks of data)
- [ ] Sentinel fast path configured with pre-authorized response classes
- [ ] Cross-pipeline correlation rules active
- [ ] Rubber-stamping detection configured for all human reviewers

**Playbooks:**
- [ ] Behavioral anomaly playbook documented and tested
- [ ] Provenance chain gap playbook documented and tested
- [ ] Incident severity classification defined
- [ ] Escalation paths to security and management documented

**Governance evidence:**
- [ ] Audit package generation tested (time range, agent, case type)
- [ ] Regulatory evidence export configured (EU AI Act, NIST)
- [ ] Compliance dashboard covering gate compliance, policy violation rates, provenance coverage

**Zero trust monitoring:**
- [ ] Dead-man's switches active on correlation engine
- [ ] Monitoring infrastructure itself subject to Ring 1 verification
- [ ] Evidence tamper detection configured

---

*Related: [Security Profile](/docs/profiles/security) — the three-level security model and Security Response Bus that observability feeds. [Platform Profile](/docs/profiles/platform) — deployment infrastructure and event emission points. [GRC Profile](/docs/profiles/grc) — how observability evidence maps to regulatory requirements.*


---
# Platform Profile
> Deployment modes, environment architecture, MCP integration, and cost of governance.
URL: /docs/profiles/platform

For platform engineers, infrastructure architects, and DevOps/MLOps teams responsible for building, deploying, and scaling the infrastructure that autonomous AI agents run on.

**The key question this profile answers:** *How do I build and deploy governed agent infrastructure?*

**Scope boundary:** This profile covers build-time and deployment-time infrastructure. Runtime operations (monitoring, incident response, observability) belong to the [Observability Profile](/docs/profiles/observability). The split mirrors Platform Engineering vs. SRE.

## The Platform Challenge

Building infrastructure for governed agentic systems is fundamentally different from building infrastructure for traditional applications. Traditional infrastructure serves deterministic software — the application does what it's told, every time. Agentic infrastructure serves non-deterministic, autonomous systems that select tools, modify their own behavior, and take actions their developers never explicitly programmed.

The platform challenge has three dimensions:

1. **Governance must be structural, not bolted on.** You can't add governance to an agentic system after the fact — it must be built into the infrastructure from the start. The rings, the verification layers, the gates, the containment mechanisms — these are infrastructure, not application features.

2. **The topology must match the system type.** A document processing pipeline and a conversational agent have completely different latency requirements, governance patterns, and failure modes. The infrastructure must adapt — the same logical governance deployed in different physical topologies.

3. **The agent's operating environment is infrastructure.** Context composition, instruction management, tool provisioning, workspace scoping, session state — these are infrastructure concerns that determine agent performance as much as compute and networking.

## Ring Deployment Modes

The Rings Model is a logical architecture. How the rings manifest physically depends on the system type, latency budget, and governance requirements. Three modes, each with different tradeoffs:

[Image: Ring Deployment Modes — Wrapper, Middleware/Interrupt, Graph-Embedded]

### Wrapper Mode

The rings literally wrap execution. Sequential, concentric — Ring 0 produces, Ring 1 verifies, Ring 2 governs, output releases.

```
Ring 0: Produce output
──── checkpoint ────
Ring 1: Verify (loop until converge)
──── checkpoint ────
Ring 2: Evaluate policy, gate if required
──── checkpoint ────
Output released
Ring 3: Learn (async)
```

| Property | Assessment |
|----------|-----------|
| **Best for** | Batch pipelines, document processing, assessment workflows, regulatory filings |
| **Real-world examples** | AI risk assessment pipelines, automated report generation, code review pipelines |
| **Latency** | Seconds to hours — the full sequential pass adds wall-clock time proportional to verification complexity |
| **Audit clarity** | Highest — each stage boundary is a clean cut in the provenance chain |
| **Human oversight** | Easiest — gates pause cleanly, reviewers see complete context |
| **Reproducibility** | Highest — same inputs + configuration = same trace |
| **Tradeoff** | Latency. For user-facing agents, the sequential pass may be unacceptable. |

### Middleware / Interrupt Mode

Ring logic fires at specific decision points within an execution graph — tool calls, data access, state mutations. The agent executes continuously; the rings intercept at defined boundaries.

```
step 1 → step 2 → [R1: verify tool] → step 3
                                          │
                    [R2: gate — destructive] ←┘
                              │
                       (human approves)
                              │
                          step 4 → step 5 → [R1: verify output]
                                                    │
                                                step 6 → done

Ring 3: learns from full trace (async)
Security fabric: active at every interrupt boundary
```

| Property | Assessment |
|----------|-----------|
| **Best for** | Coding agents, ops automation, multi-step task agents, infrastructure management |
| **Real-world examples** | Claude Code, Cursor, Devin, GitHub Copilot Workspace, CI/CD agents |
| **Latency** | Sub-second to seconds per action |
| **Audit clarity** | Good — provenance shows which control points triggered and what was decided |
| **Human oversight** | Good with constraints — richer context, more domain expertise required |
| **Checkpointing** | Checkpoint at each interrupt boundary. Agent must be resumable — pausing mid-execution for a gate requires frozen, persisted, resumable state. |
| **Tradeoff** | Interrupt policy design is hard. Too many = constant pausing. Too few = missed consequential actions. |

**MCP as canonical implementation:** The Model Context Protocol materializes middleware/interrupt mode directly — the protocol defines the boundary between agent reasoning and tool execution, making each tool call a natural interrupt point.

### Graph-Embedded Mode

Verification, governance, and security run concurrently with execution as peer nodes in the orchestration graph.

| Property | Assessment |
|----------|-----------|
| **Best for** | Conversational agents, voice assistants, real-time systems, agent swarms |
| **Real-world examples** | ChatGPT-style agents, voice assistants, real-time recommendation engines, trading agents |
| **Latency** | Milliseconds (user-perceived) |
| **Audit clarity** | Lowest — concurrent execution produces a partial order, not a total order |
| **Human oversight** | Hardest — speculative execution means the agent has "moved on" by the time a gate fires |
| **Reproducibility** | Lowest — concurrency introduces timing-dependent behavior |
| **Tradeoff** | Latency for governance clarity. Systems subject to regulatory audit should strongly consider wrapper or middleware. |

**Speculative execution bounds** *(Informed proposal):*
- **Depth limit:** 3–4 levels of speculative chaining. Governance overhead grows super-linearly beyond depth 4.
- **Entropy constraint:** If historical rejection rate for an action class exceeds ~20%, exclude from speculation and process sequentially.
- **Side-effect fence:** Speculative steps that produce irreversible side effects are held in a commit buffer until the governance release gate clears.

### Hybrid Deployment

Systems are not required to use a single mode. The common pattern: **middleware mode overall with graph-embedded subsections.** The coding agent operates in middleware mode (interrupt-driven), but within a single user-facing response, the generation pipeline uses graph-embedded mode (parallel verification of streamed output).

## Mode Selection Matrix

Choose the deployment mode based on system characteristics. When multiple modes could work, prefer the one with stronger governance properties unless latency requirements force otherwise.

| System Characteristic | Wrapper | Middleware | Graph-Embedded |
|----------------------|---------|-----------|----------------|
| **Output type** | Discrete artifact (document, report, assessment) | Sequence of actions (tool calls, mutations, operations) | Continuous stream (conversation, real-time feed) |
| **Latency tolerance** | Seconds to hours | Sub-second to seconds per action | Milliseconds (user-perceived) |
| **Governance intensity** | High — every output fully reviewed | Selective — consequential actions trigger rings | Minimal blocking — most output auto-passes |
| **Human gate frequency** | High — frequent pause-and-review acceptable | Moderate — gates at high-stakes actions only | Low — rare, and disruptive when they fire |
| **Regulatory/audit** | Strong — clear evidence trail required | Moderate — action-level audit sufficient | Light — behavioral monitoring sufficient |
| **Side-effect profile** | Contained — output is an artifact | Mixed — many actions, some irreversible | Continuous — streaming output, real-time effects |
| **Regulatory jurisdiction** | EU AI Act high-risk (Art. 9–15) | Most jurisdictions | Permissive or low-risk classification |
| **Rollback/compensation** | Simple — discard the artifact | Per-action compensation via Transaction Control (#16) | Complex — speculative execution may have committed partial state |

**Decision heuristic:** If you're unsure, start with middleware mode. It handles the widest range of use cases and has the strongest protocol ecosystem (MCP).

**Ecosystem reality (March 2026):** No single deployment mode dominates. LangGraph uses graph-embedded governance with state machines; CrewAI uses workflow checkpoint governance; OpenAI Agents SDK uses interceptor/middleware guardrails; Amazon Bedrock AgentCore uses external policy enforcement at the gateway layer. MCP is a **connectivity protocol**, not a governance mechanism — governance layers are built on top of or alongside MCP.

## The Agent Environment Stack

Every agent operates within a 5-layer environment. Each layer has its own composition policy, governance intensity, and lifecycle:

```
┌──────────────────────────────────────────────────┐
│ L5: Session State                     20-30%     │
│ conversation history, tool results, working      │
│ memory, handoff context                          │
│ Ephemeral, session-scoped                        │
├──────────────────────────────────────────────────┤
│ L4: Retrieved Context                 30-40%     │
│ task-specific knowledge, documents, search       │
│ Dynamic, loaded JIT per task                     │
├──────────────────────────────────────────────────┤
│ L3: Capability Set                    10-15%     │
│ active tools, skills, MCP servers, API access    │
│ Provisioned per role, subject to trust level     │
├─ ─ ─ ─ ─ ─ TRUST BOUNDARY ─ ─ ─ ─ ─ ─ ─ ─ ─ ─┤
│ L2: Instruction Architecture          10-20%     │
│ system prompts, rules, personas, constraints     │
│ Versioned, tested, slow-changing                 │
├──────────────────────────────────────────────────┤
│ L1: Identity & Policy Substrate       5-10%      │
│ agent identity, ring assignment, governance      │
│ policy, trust level, workspace boundaries        │
│ Foundational                                     │
└──────────────────────────────────────────────────┘
         ▲ Composition flow: bottom-up
```

**Trust boundary:** Below L3 (L1–L2) is human-authored, version-controlled, and trusted. Above the boundary (L3–L5) is dynamic, runtime-composed, and treated as untrusted input by the Security Fabric.

**Percentages** are context budget allocation starting points. The Environment Optimization Loop adjusts based on measured effectiveness.

## The Composability Interface

AGF defines a standard contract for how agents expose themselves to the ring stack. Every governed agent implements this interface:

[Image: Ring Interface and Composability — standard contract between rings]

**Signal set — what rings return to each other:**

| Signal | Meaning | Who Receives |
|--------|---------|-------------|
| `PASS` | Output meets criteria | Ring 2 / Release |
| `REVISE` | Output needs change — structured finding attached | Ring 0 (retry) |
| `HALT` | Output cannot be fixed — stop execution | Governance |
| `GATE` | Output meets quality criteria but requires human authorization | Human reviewer |
| `ERROR` | Verification process itself failed | Orchestrator |

**Execution budgets:** Every ring boundary carries a budget — maximum iterations, time, compute, API calls. Budget exhaustion triggers graceful halt. Without budgets, validation loops can spin indefinitely.

**Delegation signals:** The `DELEGATE` signal passes authority to a sub-agent with a bounded scope — the delegating agent's authority cannot be exceeded, only narrowed. Delegation chains are cryptographically bound and auditable.

## MCP Integration Patterns

The Model Context Protocol (MCP) is the current dominant protocol for tool integration. AGF's governance layer sits on top of MCP, not inside it.

**MCP as the interrupt boundary:** Each MCP tool call is a natural interrupt point. The governance layer:
1. Intercepts the tool call intent before execution
2. Evaluates against policy (is this tool permitted? with these parameters? at this trust level?)
3. Either passes, modifies, or blocks
4. Records the decision in the event stream

**MCP server trust tiers:**

| Tier | Source | Trust Level | Governance |
|------|--------|-------------|------------|
| **Tier 1 — Organizational** | Internal, first-party | High | Streamlined approval |
| **Tier 2 — Verified** | Known vendor, audited schema | Medium | Policy evaluation per call |
| **Tier 3 — Community** | Public registry, unverified | Low | Sandboxed, mandatory gate on first use |
| **Tier 4 — Dynamic** | Runtime discovery | Untrusted | Blocked by default, explicit allowlisting required |

**Supply chain posture:** 53% of community MCP servers use insecure static API keys (Astrix Security, 2025). Default stance: Tier 3 and Tier 4 servers require explicit organizational approval before use.

## Cost of Governance

Governance is not free. Every ring boundary adds latency, compute, and complexity. Understanding the cost model helps make informed tradeoffs.

[Image: Governance Latency Tradeoff — overhead by ring and deployment mode]

**Latency overhead by deployment mode:**

| Mode | Ring 1 overhead | Ring 2 overhead | Gate overhead |
|------|----------------|----------------|--------------|
| **Wrapper** | +20–50% per output | +10–30% per output | Minutes (human review) |
| **Middleware** | +50ms–500ms per tool call | +50ms–200ms per gate evaluation | Minutes (human review) |
| **Graph-Embedded** | Near-zero (concurrent) | Near-zero (concurrent) | Disruptive (blocks stream) |

**Cost reduction strategies:**
- **Trust Ladders (#11):** Higher-trust agents pass verification faster (fewer iterations, lighter checks).
- **Risk-based ring activation:** Not every execution triggers all rings. Risk classification determines which rings activate at what intensity.
- **Async Ring 3:** Learning and analysis run asynchronously — no latency impact on the critical path.
- **Adaptive gates:** Mandatory only for classified irreversible actions. Routine operations auto-pass.

**The governance dividend:** Governance costs are offset by reduced failure costs — avoided regulatory penalties, reduced remediation, lower breach costs, and trust that enables higher-stakes automation.

## Infrastructure Checklist

**Deployment mode selection:**
- [ ] System type mapped to deployment mode (wrapper / middleware / graph-embedded)
- [ ] Latency budget documented and mode selection justified
- [ ] Regulatory jurisdiction requirements checked against mode properties

**Agent environment:**
- [ ] 5-layer stack composed (L1–L5) with trust boundary respected
- [ ] Versioned system prompts and instructions in source control
- [ ] Tool provisioning scoped per role and trust level
- [ ] Workspace boundaries enforced (tenant isolation)

**MCP integration:**
- [ ] MCP server inventory documented with trust tier assignments
- [ ] Static API keys eliminated from Tier 2–4 servers
- [ ] Dynamic discovery blocked by default

**Composability interface:**
- [ ] Signal set implemented (PASS/REVISE/HALT/GATE/ERROR)
- [ ] Execution budgets defined per ring boundary
- [ ] Delegation chain bounds enforced

**Cost of governance:**
- [ ] Latency overhead measured per ring per deployment mode
- [ ] Trust Ladders configured for high-volume, proven agents
- [ ] Async Ring 3 confirmed off critical path

---

*Related: [Security Profile](/docs/profiles/security) — security architecture and threat defense. [Observability Profile](/docs/profiles/observability) — runtime monitoring and incident response. [AI Engineering Profile](/docs/profiles/ai-engineering) — which primitives to implement first.*


---
# Security Profile
> Threat modeling, OWASP mappings, three-level security model, and incident response for governed agentic systems.
URL: /docs/profiles/security

For CISOs, security architects, application security teams, red teams, and SOC analysts responsible for the security posture of systems that include autonomous AI agents.

**The key question this profile answers:** *What are the threats to my agentic systems, and how does AGF's architecture defend against each one?*

**Prerequisites:** Familiarity with the [Rings Model](/docs/overview/rings-model) and core concepts. This profile does not re-explain the ring architecture — it shows how security operates within it.

## The Security Challenge

Agentic systems introduce a fundamentally different threat surface from traditional software. An autonomous agent doesn't just process data — it reasons, selects tools, executes actions, communicates with other agents, and modifies its own behavior over time. Every one of these capabilities is an attack vector.

The traditional security stack — firewalls, WAFs, SAST/DAST, IAM — was built for deterministic software that does what it's told. Agentic systems are non-deterministic, autonomous, and capable of taking actions their developers never explicitly programmed. A compromised agent doesn't just leak data — it can manipulate decisions, escalate its own privileges, coordinate with other compromised agents, and gradually poison the systems that govern it.

**Why a unified security architecture matters:** The landscape fragments agentic security into separate silos — quality monitoring, security monitoring (SIEM), and compliance monitoring (GRC tools). AGF argues this fragmentation is itself a vulnerability. A quality degradation pattern might be a security attack. A compliance anomaly might indicate behavioral drift. A performance issue might mask a privilege escalation. The three-level security model unifies these domains because agentic threats don't respect domain boundaries.

## The Three-Level Security Model

Security in AGF is not a single ring, layer, or feature. It is a pervasive architectural concern operating at three distinct levels — each with different temporal characteristics, enforcement mechanisms, and failure modes.

[Image: Three-Level Security Model — Fabric, Governance, Intelligence]

### Level 1: Security Fabric — Enforcement

**What it is:** The embedded security substrate active at every ring boundary. Always on, synchronous, wire-speed.

| Capability | Description | Temporal |
|-----------|-------------|----------|
| **Input sanitization** | Every input to any ring is treated as potentially adversarial. Prompt injection detection, context boundary enforcement, payload validation. | Per-interaction (μs–ms) |
| **Output scanning** | Every output inspected before crossing a ring boundary. Known pattern detection, classification markers, integrity assertions. | Per-interaction (μs–ms) |
| **Runtime containment** | Sandboxing, resource limits, execution isolation. Compromised agents have bounded blast radius. | Always active |
| **Ring integrity verification** | Each ring verifies its configuration matches its authorized state (signed manifest). | Per-interaction (μs–ms) |
| **Identity enforcement** | Per-interaction cryptographic identity verification at every boundary. No ring trusts another's output by origin alone. | Per-interaction (μs–ms) |
| **Configuration attestation** | Control-plane configuration verified against signed deployment manifest. Divergence triggers containment. | Per-interaction (μs–ms) |

**What it is NOT:** The fabric does not make semantic judgments. A carefully worded adversarial prompt that is syntactically clean passes the fabric. Semantic threats require Level 2 evaluation.

### Level 2: Security Governance — Policy Evaluation

**What it is:** Security policy evaluation. Lives in Ring 2, evaluated by Policy as Code (#9), enforced through Governance Gates (#8). Makes the decisions that the fabric enforces.

| Capability | Description | Temporal |
|-----------|-------------|----------|
| **Access control policy** | Who can do what under what conditions. Agents, models, humans × tools, data, actions × trust level, risk classification, context. | Per-decision (ms–min) |
| **Data classification** | PII rules, consent scope, data residency, retention, redaction. | Per-decision |
| **Irreversible-action authorization** | Any action classified as irreversible must pass a mandatory gate regardless of trust level. | Per-decision (may pause for human review) |
| **Supply chain trust policy** | Approved sources, version pins, trust tiers. For MCP: server identity verification, tool schema integrity, authorized registries. | Per-decision |
| **Semantic security evaluation** | When the fabric flags syntactically-clean-but-potentially-adversarial content, Governance evaluates against security policy. | Per-decision (ms–min) |

### Level 3: Security Intelligence — Detection & Response

**What it is:** The SIEM pattern applied to agentic systems. Consumes the event stream from all rings, runs security-specific correlation rules, triggers response playbooks.

| Capability | Description | Temporal |
|-----------|-------------|----------|
| **Behavioral anomaly detection** | Baseline agent behavior, detect divergence. Trust manipulation patterns. Behavioral drift over time. | Dual-speed |
| **Cross-pipeline correlation** | Detect attacks spanning multiple agents. Lateral movement, coordinated behavior changes, cascading failures. | Slow path (hours–days) |
| **Memory & state introspection** | Read access to agent internal state — memory stores, context windows, embedding stores, tool registries, loaded manifests. The EDR pattern for agents. | Slow path |
| **Human-agent interaction analysis** | Approval cadence, framing analysis, fatigue indicators. Detect agents exploiting human cognitive biases. | Dual-speed |
| **Response playbooks** | Quarantine, trust degradation, blast radius containment, human escalation, forensic preservation. | On trigger |

**Dual-speed operation:**
- **Fast path (sentinels):** Sub-second. Known-pattern anomaly-triggered responses.
- **Slow path (analysis):** Hours to days. Cross-execution pattern analysis, behavioral drift, memory evolution tracking.

**Implementation references:** SentinelAgent graph analysis (92% accuracy, OTel-based), AgentGuard MDP-based probabilistic verification, Pro2Guard proactive enforcement via Markov chains.

## The Security Response Bus

**The problem:** A multi-agent lateral movement attack cascades across three agents in under 3 seconds. Full governance deliberation takes minutes. By the time Intelligence detects, Governance authorizes, and Fabric contains — the attack may already be complete.

**The solution:** Pre-authorized fast-path from Intelligence directly to Fabric, bypassing normal Governance deliberation for defined threat classes.

[Image: Security Response Bus — Pre-authorized fast-path containment]

```
Normal path (seconds–minutes):
  Intelligence detects → Governance evaluates → Fabric contains

Response Bus path (sub-second):
  Intelligence detects → [pre-authorized match] → Fabric contains
                                                    ↓
                                           Governance notified post-facto
```

**How it works:**

1. Governance pre-authorizes response classes — "If Intelligence detects lateral movement pattern X, Fabric may immediately isolate affected agents." Pre-authorizations are versioned policy, recorded in the provenance chain, auditable.
2. Intelligence triggers pre-authorized responses when a detection matches a pre-authorized class.
3. Fabric executes containment — circuit breakers fire, agents isolated, blast radius bounded.
4. Governance is notified post-facto. Response recorded, evidence preserved, Governance validates or escalates.

**What this is NOT:** A governance bypass. Governance defines and pre-authorizes the response classes. Intelligence cannot trigger containment for patterns Governance hasn't pre-authorized.

**Known limitation:** A compromised Intelligence layer with Response Bus access can trigger false containment — denial-of-service by halting legitimate operations. Mitigations: cryptographic proof required for activation, pre-authorized classes limit blast radius, Governance dead-man's-switch overrides excessive containment rates.

## Zero Trust for Agentic Systems

Zero trust is not a feature — it is the architectural assumption that runs through everything. No ring trusts another ring's output by default. Trust is earned through demonstrated performance (Trust Ladders #11), not assumed.

[Image: Zero Trust Identity Flow — per-interaction verification across rings]

| Zero Trust Principle | Agentic Application |
|---------------------|-------------------|
| **Never trust, always verify** | Ring 1 independently verifies Ring 0. Ring 2 independently evaluates policy. No implicit trust between rings. |
| **Least privilege** | Bounded Agency (#7). Agents have only the tools, data access, and authority they need. |
| **Assume breach** | Adversarial Robustness (#15). Limit damage when — not if — a component is compromised. |
| **Verify explicitly** | Identity & Attribution (#14). Every action carries authenticated identity. |
| **Microsegmentation** | Ring isolation. Tenant scoping. Cross-pipeline interactions require mutual authentication. |

### Identity as the Control Plane

In agentic zero trust, identity is richer than traditional identity:

- **Agent identity:** agent_id, version, configuration hash
- **Model identity:** model, version, provider, fine-tune
- **Delegation chain:** who authorized this agent, under what authority, with what scope
- **Execution identity:** run ID, context, inputs, checkpoint
- **Data identity:** whose data, classification level, consent scope
- **Human identity:** who is in the governance loop, what authority do they hold

These bind into an **identity context** that travels with every action through every ring. Candidate implementation protocols (NIST NCCoE concept paper, Feb 2026): SPIFFE/SPIRE for cryptographic workload identity, OAuth 2.1 for user-delegated agent authority, OIDC for federated identity, NGAC for attribute-based access control.

## Threat Analysis: OWASP Top 10 for Agentic Applications

[Image: OWASP Threat Mapping — AGF defense coverage per ASI threat]

Each of the 10 OWASP ASI threats maps to specific AGF defense mechanisms.

### ASI01 — Agent Goal Hijack

Hidden prompts or instructions that redirect an agent's goals via external content, context manipulation, or environment drift.

- **Owner:** Security Fabric / Adversarial Robustness (#15)
- **Primary:** Configuration integrity attestation — Fabric verifies control-plane configuration against a signed manifest at every ring boundary. Divergence triggers containment.
- **Supporting:** Intelligence detects behavioral divergence from authorized objectives over time. Agent Environment Governance (#19) verifies instruction integrity.
- **Gap:** Full semantic goal-state attestation remains a research frontier. Text-level safety behavior does not reliably transfer to tool-call behavior.

### ASI02 — Tool Misuse & Exploitation

Steering agents into unsafe use of legitimate capabilities — using permitted tools in unintended ways.

- **Owner:** Governance / Bounded Agency (#7)
- **Primary:** Governance defines permitted tool parameters and action scopes via policy. Bounded Agency enforces the operating envelope.
- **Supporting:** Fabric enforces containment at runtime. Intelligence detects anomalous tool-use patterns.

### ASI03 — Identity & Privilege Abuse

Agents receiving, holding, or delegating privilege improperly. Stale or inherited credentials expanding blast radius.

- **Owner:** Security Fabric / Identity & Attribution (#14)
- **Primary:** Cryptographic identity verification at every ring boundary. SPIFFE/SPIRE SVIDs — short-lived, automatically rotated. No static credentials.
- **Supporting:** Governance evaluates authorization. Intelligence detects lateral movement and privilege escalation.

### ASI04 — Supply Chain Vulnerabilities

Poisoned tools, plugins, models, or connectors in dynamic MCP/A2A ecosystems.

- **Owner:** Governance / Adversarial Robustness (#15)
- **Primary:** Governance defines approved sources, version pins, trust tiers. MCP: server identity verification, tool schema integrity checks, authorized registries.
- **Key data point:** 53% of community MCP servers use insecure static API keys (Astrix Security, 2025). Supply chain policy must enforce short-lived, scoped credentials.

### ASI05 — Unexpected Code Execution

Agents constructing and executing code from untrusted input without adequate sandboxing.

- **Owner:** Security Fabric / Adversarial Robustness (#15)
- **Primary:** Runtime containment — sandboxed execution environments with resource limits. Code generated from external input treated as untrusted.

### ASI06 — Data Exfiltration & Privacy Violation

Agents leaking sensitive data through tool outputs, logs, memory stores, or model context.

- **Owner:** Governance / Data Governance & Confidentiality (#17)
- **Primary:** Data classification at every data flow. PII rules, consent scope, redaction before ring boundary crossing.

### ASI07 — Cascading & Compounding Failures

Multi-agent failures where one compromised agent contaminates downstream agents.

- **Owner:** Security Intelligence (cross-pipeline correlation)
- **Primary:** Cross-pipeline correlation detects cascading patterns. Security Response Bus provides fast-path containment before cascade completes.

### ASI08 — Resource & Service Abuse

Agents consuming excessive compute, API quotas, or financial resources — intentionally or through manipulation.

- **Owner:** Bounded Agency (#7) + Security Fabric
- **Primary:** Execution budgets (compute, tokens, API calls, wall-clock time) enforced at the ring boundary. Budget exhaustion triggers graceful halt, not crash.

### ASI09 — Human Manipulation & Oversight Evasion

Agents exploiting human cognitive biases to manipulate oversight decisions — framing, anchoring, approval fatigue.

- **Owner:** Security Intelligence / Governance Gates (#8)
- **Primary:** Rubber-stamping detection — Intelligence flags reviewers who approve too quickly or too uniformly. Approval rate limits. Cooling-off periods prevent fatigue exploitation.
- **Note:** Oversight efficacy degrades as the capability gap between overseer and system increases (Engels et al., NeurIPS 2025). Structural safeguards supplement human oversight.

### ASI10 — Irreversible & High-Stakes Actions

Agents taking consequential actions that cannot be undone — financial transactions, data deletion, external communications.

- **Owner:** Governance Gates (#8) + Transaction & Side-Effect Control (#16)
- **Primary:** Mandatory gate on any action classified irreversible. Three-phase commit: pre-commit → commit → confirm. Compensation logic for rollback where possible.

## CSA Agentic Trust Framework Alignment

| CSA ATF Domain | AGF Mapping |
|---------------|-------------|
| **Segmentation** | Ring isolation, tenant scoping, cross-pipeline authentication requirements |
| **Data Governance** | Data Governance & Confidentiality (#17) — classification, lineage, consent, retention |
| **Identity & Access** | Identity & Attribution (#14) + Zero Trust identity context |
| **Behavioral Monitoring** | Security Intelligence — behavioral baselines, trust trajectories |
| **Supply Chain** | Adversarial Robustness (#15) supply chain trust policy |

## Security Assessment Checklist

**Security Fabric:**
- [ ] Input sanitization active at all ring boundaries
- [ ] Output scanning before every ring boundary crossing
- [ ] Runtime sandboxing with resource limits per agent
- [ ] Signed deployment manifests for ring configuration integrity
- [ ] Cryptographic identity verification per interaction (no static credentials)

**Security Governance:**
- [ ] Access control policy covers agent × tool × data × trust level
- [ ] Irreversible actions classified and mandatory gate configured
- [ ] Supply chain trust policy: approved sources, version pins, trust tiers
- [ ] MCP server identity verification and tool schema integrity

**Security Intelligence:**
- [ ] Behavioral baseline established for each agent
- [ ] Cross-pipeline correlation rules active
- [ ] Security Response Bus pre-authorization policy defined and versioned
- [ ] Incident response playbooks tested

**Zero Trust:**
- [ ] No static credentials anywhere in the agent stack
- [ ] Delegation chains bounded and auditable
- [ ] Trust Ladders calibrated from empirical performance data

---

*Related: [Platform Profile](/docs/profiles/platform) — deployment infrastructure and containment architecture. [Observability Profile](/docs/profiles/observability) — detection, correlation, and response operations. [GRC Profile](/docs/profiles/grc) — regulatory compliance and evidence generation.*


---
# Decision Intelligence
> Governed decision-making systems with structured persistence, belief revision, and multi-agent governance pipelines.
URL: /docs/reference/decision-intelligence

Decision Intelligence is a governed system that captures **how decisions are made and why** — not just what was decided. Every decision produces a structured, auditable, replayable artifact that traces from evidence through reasoning to outcome.

In AGF terms, Decision Intelligence is a **Governed Decision Flow** — Ring 0 (execution) + Ring 1 (verification) + Ring 2 (governance) applied to risk-bearing decisions, with Ring 3 (learning) enabling cross-case intelligence over time.

## The Problem

Current governance and risk tools are built for recordkeeping, not decision making. Organizations have control libraries, questionnaires, document storage, and static reports. But the critical decisions — security reviews, AI governance approvals, vendor assessments, policy exceptions — are still made manually by committees. These processes are slow, inconsistent, poorly documented, and dependent on scarce expert labor.

## First Principles

1. **Decisions are first-class artifacts.** Every decision is structured, versioned, and queryable.
2. **The reasoning matters more than the conclusion.** Record what was considered, not just what was decided.
3. **Beliefs can change.** When new evidence arrives, decisions that depended on outdated beliefs should be flagged for review.
4. **Governance is proportional.** Low-stakes decisions flow fast. High-stakes decisions get full Ring 2 scrutiny.
5. **The system learns from its own decisions.** Patterns across decisions reveal organizational knowledge.

## Key Patterns

### Risk Decision Graph (RDG)

A graph of interconnected decisions where each node carries its full evidence chain, reasoning, and outcome. When upstream evidence changes, the graph identifies which downstream decisions may need revision.

### The Belief Layer

[Image: Belief Revision Cascade]

The governed epistemic state of the system. Beliefs are propositions with confidence levels, evidence chains, and revision rules. When evidence changes, beliefs revise, and decisions that depended on those beliefs are flagged.

No framework in the landscape has anything like the Belief Layer — it governs agent **epistemic state**, not just agent actions.

### Multi-Agent Decision Pipeline

[Image: Multi-Agent Decision Pipeline]

For high-stakes decisions: multiple specialist agents produce independent assessments, a synthesis agent integrates them, and governance gates determine when human review is required.

## Mapping to the Rings

| Ring | Role in Decision Intelligence |
|------|-------------------------------|
| **Ring 0** | Domain agents produce decision artifacts — evidence gathering, analysis, recommendation |
| **Ring 1** | Challenger agent critiques the recommendation, checks for logical gaps and missing evidence |
| **Ring 2** | Policy evaluation — does this decision comply with governance rules? Does it require human authorization? |
| **Ring 3** | Cross-case learning — patterns across decisions, trust calibration for decision domains |

## Open Questions

- How should belief revision cascade through multi-system decision graphs?
- What is the right balance between decision speed and decision quality for different risk tiers?
- How do you prevent Ring 3 learning from amplifying systematic biases in historical decisions?

For the complete Decision Intelligence specification, see the [canonical source](https://github.com/jessepike/agf/blob/main/docs/decision-intelligence.md).


---
# Governance Framework
> The top-level operating model — governance functions, agent lifecycle, risk classification, and enterprise integration.
URL: /docs/reference/governance-framework

The Agentic Governance Framework is the top-level operating model that everything else sits under. It defines five governance functions, an agent lifecycle, risk classification, and enterprise integration points.

## Five Governance Functions

Adapted from NIST AI RMF for the agentic context:

| Function | Purpose | AGF Mapping |
|----------|---------|-------------|
| **Discover** | Identify agentic systems, their capabilities, and their risk profile | Risk classification, agent inventory |
| **Assess** | Evaluate risks, threats, and governance requirements | Threat modeling, standards mapping |
| **Govern** | Establish policies, controls, and oversight mechanisms | Ring 2 (Governance), Policy as Code (#9) |
| **Monitor** | Observe system behavior, detect anomalies, measure compliance | Ring 3 + Observability, Event-Driven (#10) |
| **Evolve** | Improve governance based on operational experience | Self-Improving Cycles (#3), Trust Ladders (#11) |

## Agent Lifecycle

From deployment to retirement, with governance at every stage:

1. **Design & Development** — threat modeling, ring activation decisions, primitive selection
2. **Evaluation & Assurance (#18)** — pre-deployment testing, regression suites, adversarial evaluation
3. **Deployment** — initial trust level, governance configuration, monitoring baseline
4. **Operation** — runtime governance (Rings 0-2), continuous monitoring (Ring 3)
5. **Evolution** — trust calibration, configuration updates, capability expansion
6. **Retirement** — graceful decommission, evidence preservation, trust revocation

## Risk Classification

Determines which rings activate and how intensely:

| Risk Level | Ring Activation | Governance Intensity |
|------------|----------------|---------------------|
| **Low** | Ring 0 + minimal Ring 1 | Near-zero overhead |
| **Medium** | Ring 0 + Ring 1 + adaptive Ring 2 | 1.5–3x Ring 0 alone |
| **High** | All four rings, mandatory gates | 3–5x Ring 0 alone |
| **Critical** | All rings + enhanced Security Intelligence | 5x+ Ring 0 alone |

## Enterprise Integration

AGF is designed to complement, not replace, existing enterprise systems:

- **IAM** — agent identity integrates with organizational identity (SPIFFE, OAuth, OIDC)
- **SIEM/SOAR** — agentic events flow to existing security monitoring
- **GRC platforms** — governance evidence maps to control frameworks
- **CI/CD** — Evaluation & Assurance (#18) integrates with deployment pipelines
- **Observability** — OpenTelemetry compatibility ensures standard tooling

## Maturity Model

Organizations grow governance capability over time:

1. **Ad Hoc** — no formal agentic governance
2. **Aware** — risk identified, initial controls
3. **Managed** — systematic governance, Ring 0 + Ring 1 operational
4. **Governed** — full ring activation, policy as code, continuous monitoring
5. **Optimizing** — Ring 3 active, trust calibration, self-improvement

For the complete governance framework specification, see the [canonical source](https://github.com/jessepike/agf/blob/main/docs/agentic-governance-framework.md).


---
# Agentic Observability
> The unified monitoring, detection, and response layer — a SIEM pattern for agentic systems.
URL: /docs/reference/observability-concept

Agentic Observability is the unified monitoring, detection, and response layer for governed agentic systems. It serves three roles simultaneously: quality monitoring (Ring 3 intelligence), security detection and response, and governance compliance verification.

## Why Unified?

The landscape separates security monitoring (SIEM), quality monitoring (LLM observability tools), and compliance monitoring (GRC platforms) into different tools with different event streams. But agentic threats traverse all three domains — a prompt injection is a security event that causes a quality degradation that creates a compliance violation.

**AGF unifies them.** One event stream, one correlation engine, three detection perspectives.

## The SIEM Pattern for Agents

[Image: Event Flow — Agentic Observability Architecture]

### Event Architecture

Every ring emits structured events through [Event-Driven Observability (#10)](/docs/reference/primitives). The canonical event envelope includes:

- **Identity context** — who (agent ID, version, configuration hash)
- **Ring context** — which ring, which stage in the pipeline
- **Temporal context** — timestamps, duration, sequence
- **Semantic context** — what happened, structured payload
- **Governance context** — policy evaluated, gate outcome, trust level

Built on OpenTelemetry GenAI Semantic Conventions with governance-specific extensions.

### Correlation Engine

Three detection perspectives operate on the same event stream:

| Perspective | What It Detects | Time Horizon |
|-------------|----------------|--------------|
| **Quality** | Degraded output quality, validation failures, convergence issues | Real-time + trending |
| **Security** | Prompt injection, data exfiltration, privilege escalation, behavioral anomalies | Sub-second (sentinels) + hours (analysis) |
| **Governance** | Policy violations, unauthorized actions, missing approvals, trust level drift | Per-workflow + periodic audit |

### Dual-Speed Detection

- **Fast-path sentinels** — sub-second pattern matching for known attack signatures. Triggers the [Security Response Bus](/docs/profiles/security) for immediate containment.
- **Slow-path analysis** — hours to days of behavioral pattern analysis. Detects drift, emerging threats, and systemic quality trends.

## Operational Playbooks

The Observability Profile defines structured response procedures for:

- **Quality incidents** — output degradation, verification failures, convergence issues
- **Security incidents** — detected attacks, containment, forensic investigation
- **Governance incidents** — policy violations, unauthorized actions, evidence preservation

Each playbook maps to specific ring signals and event patterns.

## Related

- [Observability Profile](/docs/profiles/observability) — operational detail for SREs and detection engineers
- [Security Profile](/docs/profiles/security) — the Security Response Bus and threat detection patterns
- [Event-Driven Observability (#10)](/docs/reference/primitives) — the primitive that powers this layer

For the complete observability specification, see the [canonical source](https://github.com/jessepike/agf/blob/main/docs/agentic-observability.md).


---
# The 19 Primitives
> Named patterns for governed agentic systems — runtime, lifecycle, and substrate primitives organized into the Rings Model.
URL: /docs/reference/primitives

The 19 primitives are the building blocks of AGF. They are not new inventions — they are named patterns drawn from established practice across distributed systems, security engineering, compliance, and control theory. The contribution is pulling them together into a composable architecture for the agentic context.

## Runtime Primitives (#1–#17)

These operate within or across the ring pipeline during agent execution.

| # | Primitive | Ring | One-Line Description |
|---|-----------|------|---------------------|
| 1 | Separation of Producer & Verifier | 0+1 | The agent that creates output must not be the sole agent that validates it |
| 2 | Validation Loops with Convergence Gates | 1 | Iterative verification until quality thresholds are met or budget is exhausted |
| 3 | Self-Improving Cycles | 3 | The system gets better by learning from its own execution |
| 4 | Adversarial Critique | 1 | Dedicated challenger that actively tries to find flaws |
| 5 | Structured Output Persistence | Fabric | Every ring produces and consumes structured artifacts — the data contract |
| 6 | Provenance Chains | Fabric | Every output carries its full decision history |
| 7 | Bounded Agency | 2 | Agents operate within explicit, enforced boundaries |
| 8 | Governance Gates | 2 | Explicit decision points where execution pauses for authorization |
| 9 | Policy as Code | 2 | Governance rules as versioned, executable, testable objects |
| 10 | Event-Driven Observability | Fabric | Every ring emits structured events — the shared nervous system |
| 11 | Trust Ladders | 2+3 | Trust is earned through demonstrated performance, not granted by default |
| 12 | Memory-Augmented Reasoning | 0+3 | Agents reason with persistent memory, not just immediate context |
| 13 | Error Handling & Recovery | Fabric | Graceful degradation, checkpointing, compensation |
| 14 | Identity & Attribution | Fabric | Every agent has authenticated, inspectable identity |
| 15 | Adversarial Robustness | Security | Assume breach. Defense in depth. Verify explicitly. |
| 16 | Transaction & Side-Effect Control | 0+2 | Pre-commit/commit/post-commit for irreversible actions |
| 17 | Data Governance & Confidentiality | 2+Fabric | Classification, consent, PII, lineage, retention at every data flow |

## Lifecycle Primitive (#18)

| # | Primitive | Scope | One-Line Description |
|---|-----------|-------|---------------------|
| 18 | Evaluation & Assurance | Pre-deployment | The gate before the gate — validates configurations before they reach production |

## Substrate Primitive (#19)

| # | Primitive | Scope | One-Line Description |
|---|-----------|-------|---------------------|
| 19 | Agent Environment Governance | All rings | Governed composition of context, instructions, tools, workspace, and memory |

## How They Map to the Rings

[Image: The Rings Model showing primitive placement]

- **Ring 0 (Execution):** #1, #5, #12, #14, #16 — the agent works, produces structured output, with identity
- **Ring 1 (Verification):** #1, #2, #4 — separate verifier, iterative loops, adversarial critique
- **Ring 2 (Governance):** #7, #8, #9, #11, #16, #17 — boundaries, gates, policy, trust, transactions, data governance
- **Ring 3 (Learning):** #3, #11, #12 — self-improvement, trust calibration, memory
- **Fabric:** #5, #6, #10, #13, #14, #17 — structured output, provenance, events, errors, identity, data governance
- **Security:** #15 — adversarial robustness as a pervasive concern

## Primitive Interaction Tensions

The primitives are not always harmonious. AGF names seven tensions with architectural invariants that resolve them:

| Tension | Conflict | Invariant |
|---------|----------|-----------|
| Self-Improvement vs. Reproducibility | #3 changes behavior; #6 requires traceability | *Always reproducible at a specific version* |
| Trust Ladders vs. Governance Gates | #11 reduces oversight; #8 ensures accountability | *Can skip a spot-check, never regulatory approval* |
| Bounded Agency vs. Self-Improvement | #7 constrains; #3 improves — can it expand itself? | *The box can get smarter inside. It cannot grow itself.* |
| Validation vs. Latency/Cost | #2 improves quality; each pass costs time and money | *Quality bounded by economics, not just capability* |
| Memory vs. Signal-to-Noise | #12 accumulates knowledge; stale memories inject noise | *Growth without curation is hoarding, not learning* |
| Policy as Code vs. Self-Improvement | Can Ring 3 change Ring 2's policy rules? | *Can suggest governance changes, cannot enact them* |
| Environment vs. Governance Integrity | #19 optimizes the environment — but it IS the control surface | *The environment can get better. It cannot get less governed.* |

## Implementation Priority

For a practical implementation roadmap organized by phase, see the [AI Engineering Profile](/docs/profiles/ai-engineering).

For the complete primitive catalog with full patterns, deployment modes, security architecture, and existing work mapping, see the [canonical source](https://github.com/jessepike/agf/blob/main/docs/agentic-primitives.md).


---
# Architecture Diagrams
> Visual reference models for the AGF framework — rings, security, deployment, observability, and more.
URL: /docs/resources/diagrams

AGF includes 21 architecture diagrams. Key diagrams are shown below. All diagrams are available in the [diagrams/ directory](https://github.com/jessepike/agf/tree/main/diagrams).

## The Rings Model

[Image: The Rings Model — Governed Agentic Systems]

Four concentric rings organizing governance into composable layers, with cross-cutting fabric and environment substrate. [Learn more](/docs/overview/rings-model)

## Ring Deployment Modes

[Image: Ring Deployment Modes — Wrapper, Middleware/Interrupt, and Graph-Embedded]

The same logical rings manifest differently depending on system type. [Learn more](/docs/overview/rings-model#the-rings-are-logical-not-physical)

## Three-Level Security Model

[Image: Three-Level Security Model]

Security as a pervasive concern: Fabric (enforcement), Governance (policy), Intelligence (detection). [Learn more](/docs/profiles/security)

## Composition Patterns

[Image: Composition Patterns — Progressive Build-Up]

From Minimum Viable Control to Full Governed System. [Learn more](/docs/overview/composition-patterns)

## Security Response Bus

[Image: Security Response Bus]

Pre-authorized fast-path from Security Intelligence to Security Fabric, bypassing governance deliberation for defined threat classes.

## Event Flow — Observability

[Image: Event Flow — Agentic Observability Architecture]

How events flow from ring execution through the correlation engine to the three detection perspectives.

## Agent Environment Stack

[Image: Agent Environment Stack]

The five layers of the agent operating environment governed by Primitive #19.

## Zero Trust Identity Flow

[Image: Zero Trust Identity Flow]

Identity verification at every ring boundary — no implicit trust.


---
# How the Documents Relate
> The hub-and-spoke architecture of AGF documents and how the concept areas connect.
URL: /docs/resources/relationship-model

AGF is structured as a hub-and-spoke document architecture. One entry point (the hub) routes to domain-specific profiles (the spokes) and deep-dive reference material.

## Document Architecture

```
AGF Reference Architecture (entry point)
│
├── Domain Profiles (the spokes)
│   ├── Security Profile ─────── For CISOs, security architects
│   ├── Platform Profile ─────── For platform engineers
│   ├── GRC Profile ──────────── For compliance officers, auditors
│   ├── AI Engineering Profile ── For AI engineers, agent developers
│   └── Observability Profile ── For SREs, detection engineers
│
├── Deep Reference (the foundations)
│   ├── 19 Primitives ─────────── The shared vocabulary
│   ├── Agentic Observability ── SIEM for agents
│   ├── Decision Intelligence ── Governed decision flows
│   └── Governance Framework ─── Top-level operating model
│
├── White Papers (focused deep-dives)
│   ├── Trust Ladders ────────── How agents earn autonomy
│   └── The Rings Model ─────── Concentric governance architecture
│
└── Resources
    ├── Shared Vocabulary ────── Canonical terminology
    ├── Standards Alignment ──── Regulatory and standards mappings
    └── Architecture Diagrams ── 21 visual reference models
```

## How Concept Areas Connect

The three concept areas share a common foundation:

**Agentic Primitives** is the vocabulary. It defines the 19 patterns, the Rings Model, the security architecture, and the deployment modes. Everything else references it.

**Decision Intelligence** is a specific application of the Governed Decision Flow (Ring 0 + Ring 1 + Ring 2) to risk-bearing decisions. It adds the Belief Layer and Risk Decision Graph.

**Agentic Observability** is the monitoring layer that watches all three. It correlates quality, security, and governance events across every ring.

```
Primitives (#1-#19) ← shared foundation
    │
    ├── Decision Intelligence uses → #1, #2, #4, #5, #6, #8, #9, #11, #12
    │
    └── Observability monitors → #10 (events), #14 (identity), #6 (provenance)
```

## Precedence

When documents conflict, this is the priority:

1. `intent.md` — the North Star
2. `agentic-primitives.md` — the shared vocabulary
3. `agentic-governance-framework.md` — the operating model
4. Capability layer docs (observability, decision intelligence)
5. Domain profiles

For the complete relationship model, see the [canonical source](https://github.com/jessepike/agf/blob/main/docs/cross-concept-relationship.md).


---
# Standards Alignment
> How AGF maps to NIST, OWASP, CSA, EU AI Act, ISO, OpenTelemetry, Singapore IMDA, and MITRE ATLAS.
URL: /docs/resources/standards-alignment

AGF is a synthesis framework — it integrates, not replaces, established standards. This page summarizes how AGF maps to each.

## Regulatory Frameworks

### EU AI Act

| Article | AGF Mapping |
|---------|-------------|
| Art. 6 (Risk classification) | Risk classification → ring activation level |
| Art. 9 (Risk management) | Three-level security model |
| Art. 12 (Record-keeping) | Event-Driven Observability (#10) |
| Art. 14 (Human oversight) | Governance Gates (#8), mandatory gates |
| Art. 15 (Robustness) | Adversarial Robustness (#15) |
| Art. 50 (Transparency) | Identity & Attribution (#14) |

### NIST AI RMF

| NIST Function | AGF Mapping |
|---------------|-------------|
| GOVERN | Ring 2 governance functions |
| MAP | Risk classification + ring activation |
| MEASURE | Evaluation & Assurance (#18) + Ring 1 verification |
| MANAGE | Trust Ladders (#11) + Bounded Agency (#7) |

AGF primitives are "agentic specializations of" NIST functions — runtime mechanisms within broader organizational functions.

### Singapore IMDA

| IMDA Dimension | AGF Mapping |
|----------------|-------------|
| Risk Bounding | Bounded Agency (#7) |
| Accountability | Governance Gates (#8) |
| Technical Controls | Evaluation & Assurance (#18) |
| End-User Responsibility | Identity & Attribution (#14) |

IMDA explicitly includes operational environments as a governance dimension, validating Agent Environment Governance (#19).

## Security Frameworks

### OWASP Top 10 for Agentic Applications

All 10 ASI threats are mapped to the three-level security model with single-owner responsibility per threat. See the [Security Profile](/docs/profiles/security) for the complete threat-by-threat analysis.

### OWASP MCP Top 10

All 10 MCP threats are mapped to specific primitives and security architecture components.

### CSA MAESTRO

7-layer threat model mapped to AGF primitives layer by layer.

### CSA Agentic Trust Framework

Trust Ladders (#11) aligns with ATF's earned autonomy maturity model.

### MITRE ATLAS

Security architecture aligned to the adversarial technique taxonomy.

### NIST SP 800-207 (Zero Trust)

| NIST Zero Trust | AGF Mapping |
|-----------------|-------------|
| Policy Enforcement Point (PEP) | Security Fabric |
| Policy Decision Point (PDP) | Security Governance |
| Continuous Diagnostics | Security Intelligence |

## Industry Standards

| Standard | AGF Mapping |
|----------|-------------|
| **ISO/IEC 42001** | Policy as Code (#9) maps to operational planning; AGF provides runtime mechanisms |
| **IEEE P2863** | Organizational governance that AGF's runtime architecture implements |
| **OpenTelemetry GenAI** | Event architecture builds on OTel conventions with governance extensions |
| **NIST 800-53 / ISO 27001** | Control crosswalks available in the [GRC Profile](/docs/profiles/grc) |

For detailed article-level regulatory mappings and control crosswalks, see the [GRC Profile](/docs/profiles/grc).


---
# Shared Vocabulary
> Canonical terminology used across all AGF documents.
URL: /docs/resources/vocabulary

AGF uses precise terminology throughout. When a term is used in a concept document, profile, or white paper, it carries the meaning defined here.

## System Properties

| Term | Meaning |
|------|---------|
| **Safe** | The system does not cause unintended harm |
| **Secure** | The system resists adversarial attack |
| **Durable** | The system survives failures, maintains state, and preserves governance guarantees over time |
| **Auditable** | The system produces evidence trails sufficient for compliance and forensic review |
| **Observable** | The system emits structured events that enable monitoring, detection, and response |

## Architecture Terms

| Term | Meaning |
|------|---------|
| **Ring** | A logical governance layer in the Rings Model (0=Execution, 1=Verification, 2=Governance, 3=Learning) |
| **Fabric** | Cross-cutting infrastructure: events, identity, provenance, structured output, error handling |
| **Substrate** | The agent operating environment: context, instructions, tools, workspace, memory |
| **Primitive** | A named pattern for governed agentic systems (#1–#19) |
| **Gate** | An explicit decision point where execution pauses for authorization |
| **Adaptive gate** | A gate that relaxes as the system proves reliability through Trust Ladders |
| **Mandatory gate** | A gate that never relaxes (irreversible actions, regulatory requirements) |

## Signal Protocol

| Signal | Meaning |
|--------|---------|
| **PASS** | Output accepted, move to next ring |
| **REVISE(quality)** | Ring 1 says "not good enough, try again" |
| **REVISE(context)** | Ring 2 says "the world changed, re-execute" |
| **HALT** | Something is fundamentally wrong, stop execution |
| **GATE** | Pause for human authorization |
| **DELEGATE** | Hand off to another agent with depth tracking |
| **ERROR** | Something broke; retry, degrade, or halt |

## Confidence Levels

Used throughout the framework to mark certainty:

| Level | Meaning |
|-------|---------|
| **Established pattern** | Proven across multiple domains. Strong evidence. |
| **Informed proposal** | Based on our synthesis, not yet battle-tested at scale in agentic systems. |
| **Open question** | We don't have great answers yet and say so. |

## Deployment Modes

| Mode | Description |
|------|-------------|
| **Wrapper** | Rings literally wrap execution. Sequential. |
| **Middleware/Interrupt** | Rings fire at decision points (tool calls, data access). |
| **Graph-Embedded** | Rings run concurrently with execution. |

For the complete vocabulary, see the [canonical source](https://github.com/jessepike/agf/blob/main/docs/shared-vocabulary.md).