From Framework to Runtime: What AWS's Agentic AI Scoping Matrix Means for the Skyrelis Strategy
AWS has given the industry a shared vocabulary for agent autonomy and risk. Here's how that framework maps onto the Skyrelis bet: that governance has to live at runtime, not in a developer's SDK.
By Dave Ginsburg, Marketing Consultant, Skyrelis · July 2026 · 8 min read
In November 2025, AWS Security Architects Aaron Brown and Matt Saner published the Agentic AI Security Scoping Matrix, a framework for classifying autonomous AI systems by how much agency they hold and how independently they act. AWS has since made it a standing reference on its AI security site. It's the clearest signal yet that the hyperscalers see the same problem Skyrelis was built to solve: as agents move from answering questions to taking actions, the security model underneath them has to change.
This matters strategically because AWS didn't just describe the problem. It defined the categories the market will use to talk about it. Any vendor claiming to secure agentic AI will increasingly be judged against this vocabulary. This post breaks down the matrix, the agency/autonomy distinction underneath it, AWS's six critical security dimensions, and where Skyrelis sits relative to each.
AWS's matrix scopes autonomy. Skyrelis enforces the boundary. The matrix tells an organization how much risk a given agent carries; Skyrelis is the runtime layer that makes sure the agent actually stays inside the boundary the organization assigned it, regardless of scope, framework, or cloud.
Two Axes, Not One: Agency vs. Autonomy
The most useful clarification in AWS's detailed write-up is one most summaries of the matrix miss: agency and autonomy are separate dimensions. Agency is what an agent is permitted to do. That means which systems it can touch and which operations it can perform. Autonomy is how independently it can act on that permission without a human in the loop. AWS is explicit that an agent can have high agency but low autonomy (broad permissions, but every action still needs approval), or the reverse (narrow permissions, but no approval required within that narrow lane).
A control plane that only manages one axis is incomplete. Skyrelis governs both independently at runtime: it can tighten autonomy (insert an approval gate, throttle action frequency) without touching an agent's underlying permissions, and it can tighten agency (revoke access to a specific tool or data source) without disabling the agent's ability to act autonomously elsewhere. That independent control over both axes, applied after deployment, not hardcoded at build time, is the practical difference between a framework and an enforcement layer.
The Four Scopes of Agentic Autonomy
Layered onto the two axes, AWS's matrix defines four scopes that most real-world agents fall into, ordered by how much agency and autonomy typically move together in practice.
| Scope | Definition | Illustrative Example (AWS) |
|---|---|---|
| Scope 1 | Human-initiated, read-only. Agent recommends but cannot act on external systems. | AI searches calendars for availability and returns suggestions. It cannot book anything. |
| Scope 2 | Human-initiated, agent can prepare changes but every action requires explicit human approval (HITL). | AI proposes a meeting time and asks permission before sending the invite; a human approves. |
| Scope 3 | Human-initiated, but the agent executes autonomously within bounded parameters once activated, with no per-step approval. | AI books the optimal meeting time and sends invites on its own, within its granted permissions. |
| Scope 4 | Self-initiating and continuous. The agent notices conditions and acts without being asked. | AI reads meeting notes, detects an action item to schedule, checks calendars, and sends the invite, unprompted. |
Six Critical Security Dimensions
AWS names six dimensions that security teams must account for at every scope. Its detailed post goes further than the summary matrix, showing exactly how the control requirement escalates within each dimension as agency and autonomy increase. That escalation table is the most operational part of the framework, and it's a close match for how Skyrelis's own platform is staged.
| Dimension | Scope 1 | Scope 2 | Scope 3 | Scope 4 |
|---|---|---|---|---|
| Identity Context | User/service auth, read-only permissions | + Human identity verification for approvals | + Agent authentication, identity delegation | Dynamic identity lifecycle, agent attestation |
| Data, Memory & State | Local resource permissions | Role-based access, HITL workflows | Context-aware authorization, just-in-time elevation | Behavioral authorization, adaptive access |
| Audit & Logging | Local activity logs, policy enforcement | Human decision audit trails | Reasoning-chain capture, session tracking | Continuous behavioral logging, predictive monitoring |
| Agent & LLM Controls | Process isolation, guardrails | Approval-gateway enforcement | Container isolation, tool sandboxing | Behavioral analysis, automated containment |
| Agency Perimeters & Policies | Fixed execution boundaries | Approval-based boundary changes | Dynamic boundary adjustment, runtime evaluation | Self-adjusting, context-aware boundaries |
| Orchestration | Simple, fixed workflow paths | Multi-step, approval-gated tool access | Dynamic tool orchestration, cross-system integration | Autonomous multi-agent orchestration |
Condensed from AWS's Table 2, "Critical security dimensions" (Brown & Saner, AWS Security Blog).
Identity Context
Preventing the "confused deputy" problem, where an agent does more than its initiator was ever authorized to do.
Data, Memory & State
Securing persistent agent memory and session state against poisoning; classifying data sensitivity dynamically.
Audit & Logging
Capturing not just actions but the reasoning chains behind them, in a tamper-evident, correlated way.
Agent & LLM Controls
Guardrails, sandboxing, and behavioral monitoring that can contain a misbehaving agent in real time.
Agency Perimeters & Policies
Defining boundaries that can adapt dynamically without ever letting an agent operate outside its intended design.
Orchestration
Managing agent-to-tool and agent-to-agent interactions as workflows become dynamic and self-directed.
Where Skyrelis Fits: Operationalizing the Matrix
AWS's framework is deliberately architecture-agnostic. It tells you what to worry about, not how to instrument it. That's the gap the Skyrelis strategy is built around. Rather than requiring developers to embed an SDK into every agent — an approach that breaks down the moment agents are built on different frameworks, run in different clouds, or are bought rather than built — Skyrelis governs agents from outside their code, at the point where they actually act.
Scope-by-scope: how the Skyrelis posture changes
Skyrelis isn't a single fixed control. It's a platform that scales its enforcement posture as an agent's scope increases, which mirrors exactly how AWS says security emphasis should shift.
| Scope | AWS's Primary Security Challenge | Skyrelis Posture |
|---|---|---|
| 1 | Protecting workflow integrity, preventing prompt injection from breaking predetermined flows | Discovery & classification baseline; passive visibility into read-only agent activity |
| 2 | Securing approval workflows, preventing human-authorization bypass | Behavioral profiling of proposed actions; policy checks staged ahead of human approval |
| 3 | Maintaining control during autonomous execution, scope creep, and behavioral drift | Real-time policy enforcement, rate limiting, and output filtering at the point of execution |
| 4 | Continuous behavioral validation and preventing capability drift with minimal human oversight | Full behavioral analytics engine with automated blocking, risk scoring, and audit-ready evidence generation |
Key Architectural Patterns and How Skyrelis Implements Them
Beyond the matrix itself, AWS's post lays out five patterns for deploying agentic AI safely. Each has a direct operational counterpart in how Skyrelis is built.
Progressive autonomy deployment
AWS recommends starting at Scope 1 or 2 and advancing only as organizational confidence and security capability mature.
Skyrelis: Full policy enforcement goes live at deployment, typically in under 30 minutes with zero code changes, so an organization gets real control at whatever scope an agent already operates at, and can let that agent’s autonomy grow with confidence instead of waiting on a phased security rollout.
Layered security architecture
Defense-in-depth across network, application, agent, and data layers, with special attention to identity, to avoid the confused deputy problem.
Skyrelis: Identity context mapping traces delegated permissions through the full human-to-agent-to-tool chain, independent of which layer initiated the action.
Continuous validation loops
Automated systems that verify agent behavior against expected patterns and escalate on deviation.
Skyrelis: The behavioral analytics engine baselines normal agent activity and flags anomalies continuously, not just at deployment time.
Human oversight integration
AWS makes a subtle but important point: oversight doesn’t shrink from Scope 1 to 4. It shifts. Approval-heavy review at low scopes gives way to audit, validation, and control-effectiveness assessment at high scopes.
Skyrelis: Structured logging and risk scoring are built for exactly that shift, giving security teams the audit and validation evidence they need once per-action approval is no longer how oversight happens.
Graceful degradation
Systems should automatically reduce autonomy or agency when anomalous or risky behavior is detected, rather than failing open.
Skyrelis: Runtime policy enforcement can tighten constraints, throttle actions, or disable an agent in real time when risk scores cross a threshold. That’s the mechanism AWS describes, implemented at the enforcement layer.
What This Means for You
- Score your own agents on Scope 1 to 4 before anyone does it for you. AWS's framework gives you a shared, vendor-neutral vocabulary for agentic risk. Place every agent you run on the matrix honestly, and treat wherever it lands as the start of the conversation, not the finish line.
- If you're a CISO, VP of Security, Head of IT, or Compliance leader, read this as a governance checklist. The six dimensions map directly onto the audit evidence, scope-based controls, and defensible sign-off you already need before an agent ships. Walk your current agent inventory against them, not just the summary matrix.
- If you're a CPO, CTO, VP Engineering, or Head of Trust and Safety, read this as a velocity check. You need credible Scope 3 and 4 coverage without slowing down releases or asking every engineering team to adopt an SDK. Look for controls that live at runtime, decoupled from your agents' code, so security keeps pace with how fast you actually ship.
- Don't accept "guardrails" as one undifferentiated pitch. AWS is explicit that agency (what an agent is permitted to do) and autonomy (how independently it acts) are separate dimensions. Ask any vendor whether they can tighten one without disabling the other. That answer tells you whether you're buying a real control plane or a marketing claim.
- If your compliance program still assumes human-in-loop approval and manual evidence trails, get ahead of it now. AWS itself says those assumptions collapse at Scope 3 and 4. You want automated, inline evidence generation in place before you get there, not after an auditor asks for it.
- Hold every security vendor, including us, to the matrix's own standard. AWS built it to be framework and vendor neutral, spanning any agent, anywhere. A control plane that requires embedding an SDK into every agent can't credibly claim that same coverage.
The takeaway
AWS has given the market a map. Its detailed framework post adds the operating patterns for using it safely. Skyrelis is the layer that enforces the terrain, turning the Scoping Matrix from a classification exercise into a runtime guarantee, at every scope, across every cloud.