When AWS published the Agentic AI Security Scoping Matrix in November 2025, it put language around something we'd been building toward with Rynko Flow for a few months. The framework categorizes agentic AI systems into four scopes based on two axes — agency (what the agent can do) and autonomy (how independently it acts) — and maps six security dimensions across each scope. It's been referenced by OWASP, CoSAI, and multiple systems integrators since publication.
I read through it and realized we'd already implemented a significant portion of what it recommends, particularly at Scopes 2 through 4. But I also found gaps worth being honest about. This post walks through each scope, maps it to Flow's current capabilities, and flags where we're still building.
A Quick Primer on What Flow Does
For context if you haven't seen Flow before: Rynko Flow is a validation gateway that sits between AI agents and downstream systems. You define a gate with a JSON schema and business rules, your agent submits payloads to it, and Flow validates the data before it proceeds. Failed validations return structured errors the agent can use to self-correct. Successful validations return a tamper-proof validation_id. Optionally, you can add human approval steps and webhook delivery.
The pipeline:
Gates are exposed as MCP tools, so agents discover and use them without per-gate integration code. We also support REST API submission for non-MCP agents.
One distinction that matters throughout this post: Flow is a validation checkpoint, not a centralized orchestrator. It doesn't manage agent workflows or decide what runs next. The agent (or whatever framework orchestrates it — LangGraph, CrewAI, your own code) decides when to call a gate and what to do with the result. Flow's job is narrower: validate the data, return a verdict, and track what happened.
That said, Flow's webhook delivery does enable a form of event-driven orchestration — when a payload passes validation, the webhook can trigger the next agent or service in a pipeline, creating loosely-coupled handoffs without a central coordinator. This means Flow covers some of the AWS framework's security dimensions deeply (audit, agent controls, agency perimeters) and has a partial but real story for orchestration through webhooks.
With that context, here's how Flow maps to each scope in the AWS framework.
Scope 1: No Agency
What AWS describes: Systems with human-initiated processes and no autonomous change capabilities. The agent follows predefined paths, processes data within workflow nodes, but can't modify anything. Read-only operations. Fixed execution paths.
Security focus: Process integrity, boundary enforcement, preventing agents from exceeding their boundaries.
How Flow maps here: Flow isn't really designed for Scope 1. If your agent is purely read-only and follows a fixed workflow with no ability to produce output that reaches external systems, you don't need a validation gateway — there's nothing to validate.
That said, Flow's schema validation does share DNA with one of Scope 1's key requirements: "input validation at each workflow step boundary." If you're building a pipeline where each stage processes data and hands it to the next, you could place a Flow gate between stages to validate that each node's output conforms to the expected shape. But that's using Flow as plumbing, not as an agent governance layer.
Flow coverage: Minimal — and that's fine. Scope 1 agents don't produce autonomous outputs.
Scope 2: Prescribed Agency
What AWS describes: Human-initiated, human-approved agentic actions. Agents can gather information, analyze data, and prepare recommendations, but all actions of consequence require explicit human approval. This is the "human in the loop" (HITL) scope.
Key characteristics:
Agents can execute change with human review and approval
Real-time human oversight with approval workflows
Bidirectional interaction — agents can ask humans for context
Audit trails of all human approval decisions
Security focus: Securing approval workflows, preventing agents from bypassing human authorization, and maintaining oversight effectiveness.
How Flow maps here: This is where Flow starts to fit well. The approval workflow was one of the first features we built into Flow, and it maps directly to what the AWS framework calls "approval gateway enforcement."
Here's how each Scope 2 security dimension looks in Flow:
| Security Dimension |
Scope 2 Requirement |
Flow Implementation |
| Identity context |
User auth, service auth, human identity verification for approvals |
JWT auth for dashboard users, API key auth for agents (scoped to team/workspace), magic-link reviewer identity via HMAC-SHA256 signed tokens |
| Data, memory, & state protection |
Role-based access control, human approval workflows, read-mostly permissions for agents |
Workspace-scoped gates, team-based RBAC, agents can only submit — they can't modify gate schemas or approve their own runs |
| Audit & logging |
Human decision audit trails, agent recommendation logging, approval process tracking |
Every run logged with full payload, per-rule validation verdicts, approval decisions (approve/reject) with reviewer identity and timestamp |
| Agent & FM controls |
Approval gateway enforcement, extended session monitoring |
Gate validation = approval gateway. MCP session tracking with mcpSessionId ties agent submissions to a specific session. Circuit breaker monitors session health |
| Agency perimeters & policies |
Human-validated constraint changes, time-bound elevated access, multi-step validation |
Gate schema versioning (draft → publish cycle means a human approves schema changes). Magic links expire in 72 hours. Schema validation + business rules = multi-step validation |
| Orchestration |
Multi-step workflow orchestration, approval-gated tool access, human-validated tool chains |
Flow doesn't centrally orchestrate — the agent or framework (LangGraph, CrewAI, etc.) decides what to call and when. However, Flow's webhook delivery provides an event-driven handoff mechanism: when a submission passes validation (and approval, if configured), the validated payload is pushed to a webhook endpoint that can trigger the next agent, tool, or service. This enables loosely-coupled pipeline orchestration without a central orchestrator — each gate validates one stage and hands off to the next via webhook |
The Scope 2 implementation consideration that stood out to me was "time-bounded approval tokens with automatic expiration." We built this: magic links for external reviewers are HMAC-SHA256 signed, expire in 72 hours, and are single-use for approval actions. The reviewer doesn't need a Rynko account — they click the link, see the payload rendered with safe content (sanitized HTML/Markdown), and approve or reject.
One gap: the paper mentions "cryptographically signed approval decisions." Our approval decisions are stored in the database with reviewer identity and timestamp, but we don't produce a standalone cryptographic proof of the decision. It's an area where we could do more.
Flow coverage: Strong. Approval workflows, audit trails, scoped identity, and time-bounded reviewer access align closely with Scope 2 requirements.
Scope 3: Supervised Agency
What AWS describes: Human-initiated, but the agent executes autonomously. The agent makes decisions and takes actions without further approval. Humans define objectives and trigger execution, but agents operate independently through dynamic planning and tool usage. Optional human intervention points exist, but the agent can proceed without them.
Key characteristics:
Agents can execute change with no (or optional) human review
Dynamic planning and decision-making during execution
Direct access to external APIs and systems
Persistent memory across extended sessions
Autonomous tool selection and orchestration within defined boundaries
Security focus: Maintaining control during autonomous execution, scope management, and behavioral monitoring.
How Flow maps here: This is Flow's primary operating mode. Most teams using Flow today have agents that submit data autonomously — no human in the loop — and rely entirely on the gate's schema and business rules to catch problems. The agent self-corrects from structured errors, and Flow's circuit breaker intervenes if the agent enters a failure loop.
| Security Dimension |
Scope 3 Requirement |
Flow Implementation |
| Identity context |
Agent authentication, identity delegation for autonomous actions |
API keys authenticate agents at team/workspace scope. MCP sessions bind agent identity to a persistent session with its own state |
| Data, memory, & state protection |
Context-aware authorization, just-in-time privilege elevation, dynamic permission boundaries |
Schema + business rules provide context-aware authorization — the gate evaluates each submission based on the data content, not just the caller's identity. Gate versioning allows operators to update what's accepted without downtime (publish a new version to tighten or relax rules). Flow doesn't provide privilege elevation — agents have the same permissions throughout a session |
| Audit & logging |
Comprehensive action logging, reasoning chain capture, extended session tracking |
Full run audit trail (payload, validation verdicts, processing time). Self-correction chain tracking links retries — you can see the full sequence of submit → fail → correct → resubmit as a single chain with a shared correlationId. MCP session IDs track activity across an agent's full conversation |
| Agent & FM controls |
Container isolation, long-running process management, tool invocation sandboxing |
Gate validation acts as a sandbox for agent outputs — the agent can call validate_* tools, but every payload must pass through deterministic rules before it's accepted. Circuit breaker prevents runaway retry loops by pausing the gate after consecutive failures. Flow doesn't provide container isolation or manage the agent's process lifecycle — it only controls the validation boundary |
| Agency perimeters & policies |
Runtime constraint evaluation, resource scaling limits, automated safety checks |
Business rules are evaluated at runtime against each submission — constraints are enforced per-payload, not just at setup time. Monthly run quotas cap total throughput per team. Circuit breaker acts as an automated safety check, tripping after N consecutive failures. These are static limits though — they don't adjust dynamically based on agent behavior |
| Orchestration |
Dynamic tool orchestration, parallel execution paths, cross-system integration |
Flow isn't a centralized orchestrator — it doesn't decide what runs next. But it supports two forms of integration: (1) MCP tool discovery, where agents find gates dynamically, and (2) webhook delivery, where validated payloads are pushed to downstream endpoints that can trigger the next step in a pipeline. This enables event-driven, loosely-coupled orchestration — gate A validates and webhooks to service B, which processes and submits to gate C. The sequencing emerges from the webhook chain, not from a central coordinator |
The self-correction chain tracking deserves specific mention here. The AWS paper talks about "reasoning chain capture" — being able to see why an agent made the decisions it did. Flow's chain tracking gives you a concrete version of this for validation: when an agent submits to a gate, fails, reads the errors, and resubmits, the entire sequence is linked by a correlationId. You can see exactly what the agent submitted each time, which rules it violated, what it fixed, and whether it eventually succeeded. In the webapp, chains are displayed as collapsible groups — the latest attempt shows as the primary row with a badge showing "3 attempts," and expanding reveals the full correction timeline.
The circuit breaker is Flow's implementation of the "automated safety checks" requirement. When an agent keeps failing the same gate — tracked per session for MCP agents, per payload hash for REST agents — the circuit breaker trips after a configurable number of consecutive failures. The gate transitions to a paused state, the system sends in-app and email notifications to the gate creator, and all further submissions are blocked until the cooldown expires or a new gate version is published.
Here's what makes the circuit breaker interesting from the AWS framework perspective: it's an example of graceful degradation, which the paper calls out as a key architectural pattern. The paper says: "Design systems to automatically reduce autonomy levels when security events are detected." The circuit breaker does exactly this — when the agent can't produce valid output, Flow reduces the agent's effective autonomy by blocking further submissions and notifying the human operator.
Flow coverage: Strong to comprehensive. Self-correction chains, circuit breaker, runtime validation, MCP session tracking, and structured audit trails address most Scope 3 requirements.
Scope 4: Full Agency
What AWS describes: Fully autonomous AI that initiates its own activities based on environmental monitoring, learned patterns, or predefined conditions. No human triggers the agent — it operates continuously, makes independent decisions about when and how to act. The highest level of agency and risk.
Key characteristics:
Self-directed activity initiation based on environmental triggers
Continuous operation with minimal human oversight
High to full degrees of autonomy in goal setting, planning, and execution
Dynamic interaction with multiple external systems and agents
Capability for recursive self-improvement
Security focus: Continuous behavioral validation, enforcing agency boundaries, preventing capability drift, and maintaining organizational alignment.
How Flow maps here: Flow isn't a Scope 4 system itself — it doesn't initiate actions or make autonomous decisions. But it serves as a governance layer that Scope 4 agents submit to. The distinction matters: Flow doesn't control what the agent does; it controls what outputs the agent can successfully land in downstream systems. In the AWS framework's terms, Flow provides the "Advanced Deterministic Guardrails" that Scope 4 requires.
| Security Dimension |
Scope 4 Requirement |
Flow Implementation |
Gap |
| Identity context |
Dynamic identity lifecycle, federated auth, continuous identity verification, agent identity attestation |
API key auth, MCP session binding |
No agent identity attestation or dynamic identity lifecycle. Flow authenticates the agent but doesn't verify its internal state or attest to its identity to third parties |
| Data, memory, & state protection |
Behavioral authorization, adaptive access controls, continuous authorization validation |
Every submission is checked against schema and business rules — this provides continuous authorization validation at the data level. Gate versioning lets operators evolve rules over time. Business rules reject outputs that violate constraints regardless of which agent submitted them |
No ML-based adaptive controls — rules are deterministic, defined by humans. No behavioral authorization that learns from past patterns |
| Audit & logging |
Continuous behavioral logging, pattern analysis, predictive monitoring, automated incident correlation |
Full run audit trail. Chain tracking correlates related submissions. Circuit breaker events log failure patterns. Archive sync for long-term retention |
No predictive monitoring or ML-based pattern analysis. Circuit breaker counts failures but doesn't detect novel anomaly patterns |
| Agent & FM controls |
Behavioral analysis, anomaly detection, automated containment, self-healing security |
Circuit breaker provides automated containment — pauses the gate and notifies operators when failures accumulate. Self-correction chain tracking gives visibility into agent retry patterns. Reset-on-publish clears stale circuit breaker state when new rules are deployed, which is closer to operational recovery than true self-healing |
No behavioral analysis beyond failure counting. No anomaly detection on payload content. No automated response that adapts without human intervention |
| Agency perimeters & policies |
Self-adjusting boundaries, context-aware constraints, cross-system resource management, autonomous limit adaptation |
Business rules provide context-aware constraints (evaluated per-payload). Circuit breaker provides a form of autonomous limit adaptation — it auto-pauses the gate without human action. Monthly quotas cap resource usage |
No self-adjusting boundaries — rules are static until a human publishes a new version. No cross-system resource management |
| Orchestration |
Autonomous multi-agent orchestration, cross-session learning, dynamic service discovery |
MCP tool discovery lets agents find gates dynamically. Webhook delivery enables event-driven handoffs between stages — a validated payload can trigger the next agent or service without a central orchestrator. This supports loosely-coupled multi-agent pipelines |
No centralized multi-agent coordination. No cross-session learning. No dynamic service discovery beyond MCP tool listing. Each gate is independent — Flow doesn't manage the pipeline topology |
I want to be transparent about where the gaps are, because the Scope 4 requirements are genuinely hard. The paper calls for "continuous monitoring with machine learning-based anomaly detection" and "automated response systems for behavioral deviations." Flow's circuit breaker is an automated response system, but it's simple — it counts consecutive failures. It doesn't analyze payload content for anomalies, detect drift in agent behavior patterns over time, or predict when an agent is likely to start producing invalid output.
That said, Flow provides the infrastructure that makes Scope 4 deployment safer:
Every submission is validated — the agent can't skip the gate. Schema + business rules are deterministic, not probabilistic. A Scope 4 agent that submits an order with a negative total gets rejected regardless of how autonomously it's operating.
Self-correction is tracked — you can see whether a Scope 4 agent is self-correcting successfully (resilient autonomy) or spiraling into repeated failures (failing autonomy). Chain tracking gives you this visibility without instrumenting the agent itself.
Automated containment — the circuit breaker pauses the gate when failures accumulate. This is the "failsafe mechanism that can halt operations when confidence drops" that the paper recommends for Scope 4.
Human re-entry point — when the circuit breaker trips, the gate creator gets notified (in-app + email). This is the "human ability to inject strategic guidance without disrupting operations" pattern. The human publishes a new gate version (potentially with adjusted rules), which reactivates the gate and resets circuit breakers.
Flow coverage: Partial but meaningful. Flow provides the deterministic guardrails, automated containment, and audit infrastructure that Scope 4 requires. The gaps are in ML-based anomaly detection, agent identity attestation, and cross-session learning — areas that require capabilities beyond what a validation gateway provides on its own.
The Six Security Dimensions — Summary Matrix
Here's a consolidated view of how Flow maps across all four scopes and six dimensions:
| Dimension |
Scope 1 |
Scope 2 |
Scope 3 |
Scope 4 |
| Identity |
N/A |
JWT + API key + magic links |
+ MCP session binding |
Gap: no agent attestation |
| Data & state |
N/A |
RBAC, workspace scoping |
+ runtime schema validation, gate versioning |
Gap: no adaptive controls |
| Audit |
N/A |
Run logs, approval trails |
+ chain tracking, session tracking |
Gap: no predictive monitoring |
| Agent controls |
N/A |
Approval gateway |
+ circuit breaker, chain tracking (observes correction, doesn't drive it) |
Gap: no behavioral analysis |
| Agency perimeters |
N/A |
Schema versioning, expiring tokens |
+ runtime rules, quotas, circuit breaker |
Gap: no self-adjusting boundaries |
| Orchestration |
N/A |
Webhook delivery enables event-driven handoffs |
+ MCP tool discovery |
Gap: no centralized orchestration or cross-session learning. Supports loosely-coupled pipelines via webhooks, not coordinated multi-agent workflows |
The Key Architectural Patterns
The AWS paper concludes with five architectural patterns for agentic AI deployments. Flow aligns with four of them:
Progressive autonomy deployment — "Start with Scope 1 or 2 implementations and gradually advance." Flow supports this directly. A gate can start with approval workflows (Scope 2 — human reviews every submission). Once you're confident in the schema and rules, remove the approval step and let the agent operate autonomously (Scope 3). The gate's validation logic stays the same; you're just adjusting the human oversight level.
Continuous validation loops — "Establish automated systems that continuously verify agent behavior against expected patterns." This is literally what Flow does. Every agent submission is validated against the gate's schema and business rules. The self-correction loop (submit → fail → read errors → fix → resubmit) is a continuous validation loop operating at the individual submission level.
Human oversight integration — "Maintain meaningful human oversight through strategic checkpoints, behavioral reporting, and manual override capabilities." Flow's approval workflows are the strategic checkpoints. Chain tracking and circuit breaker notifications are the behavioral reporting. Gate versioning and manual pause/resume are the manual override capabilities.
Graceful degradation — "Design systems to automatically reduce autonomy levels when security events are detected." The circuit breaker does this: when an agent accumulates consecutive failures, the gate pauses, notifications fire, and the agent's effective autonomy drops to zero until a human intervenes or the cooldown expires. The paper specifically recommends systems that "automatically inject tighter restrictions such as requiring more HITL or reducing the actions an agent can take" — this is exactly what happens when a gate transitions from auto-approve to paused.
The one pattern we don't cover well is layered security architecture — "defense in depth with security controls at multiple levels." Flow operates at the application layer (validating agent outputs). It doesn't provide network-level controls, model-level guardrails, or infrastructure-level isolation. Teams building Scope 3-4 systems need Flow as one layer in a broader security stack, not as the only layer.
What We're Building Next
Reading the AWS framework confirmed some things on our roadmap and added others:
AI Judge (semantic validation) — Currently, Flow's validation is deterministic: JSON Schema types and expression-based business rules. For Scope 4 agents producing unstructured or semi-structured outputs, deterministic rules aren't always enough. We're building an LLM-based evaluation mode where a second model reviews the agent's output against criteria defined in natural language. This addresses the "continuous behavioral validation" gap at Scope 4.
Approval timeout enforcement — Our approval workflow creates a pending_approval state, but there's no automatic expiration. The paper's Scope 2 recommendation of "time-bounded approval tokens with automatic expiration" applies here. We're adding configurable timeout with auto-reject or auto-escalate behavior.
Agent behavioral baselining — The paper's Scope 4 requirements for "pattern analysis" and "predictive monitoring" are beyond what a simple failure counter provides. We're exploring tracking submission patterns per agent (payload shape, submission frequency, validation pass rate) and flagging deviations. Not ML-based yet, but statistical baselines that surface when an agent's behavior changes.
Where Flow Fits in Your Agentic Architecture
Rynko Flow isn't a complete Scope 4 security stack — no single product is. But it provides the validation gateway, automated containment, and audit infrastructure that the AWS framework identifies as critical across Scopes 2-4.
If you're building agents that produce data destined for production systems — orders, invoices, tickets, customer records — Flow gives you deterministic guardrails that work regardless of which model or framework your agent uses. The gate doesn't care whether the agent is a Claude tool-use loop, a LangGraph pipeline, or a custom orchestrator. It validates the output, tracks the correction chain, and trips the circuit breaker if things go sideways.
The AWS framework is worth reading in full — it provides a structured way to think about where your agent sits on the agency/autonomy spectrum and what security controls you need at that level. And if you're at Scope 2 or above, a validation gateway isn't optional — it's one of the six critical security dimensions.
Paper: The Agentic AI Security Scoping Matrix
Flow docs: docs.rynko.dev/flow
Get started: app.rynko.dev/signup — free tier, 500 runs/month, 3 gates, no credit card.
