Family Guides
AWS2-WSB: Workspace And Execution Boundaries
AWS2-WSB is about keeping agent activity inside the workspace and execution boundaries the business actually approved.
In ordinary business terms, this family asks: which files, repositories, systems, applications, network locations, shells, browsers, and hosted services can an agent reach, and what prevents the agent from crossing into places or actions that were not meant to be available?
This matters because an agent can combine ordinary workspace access, local automation, connector permissions, browser sessions, network access, and shell execution in ways that are broader than a human reviewer expects. A reviewer needs to see both the reachable resources and the controls that constrain reading, writing, executing, transmitting, and modifying those resources.
What This Family Covers
In scope:
- Workspace resources that agents can read, write, execute, send to, or modify.
- Local files, repositories, shared drives, browsers, shells, scripts, package installation paths, desktop apps, SaaS systems, connectors, and networked resources where applicable.
- Whether access is read-only, write-capable, execution-capable, externally transmitting, or able to change access or infrastructure.
- Filesystem, repository, sandbox, browser, network, hosted-service, and application boundaries used to limit agent access.
- Known exclusions, bypasses, or unsupported areas where the boundary does not apply.
- Production workflow access limits, network egress limits, connector scopes, repository scopes, environment profiles, and monitoring for boundary violations.
- Review or approval before broad filesystem impact, production write impact, access-control impact, external communication impact, sensitive-data movement, or rollback-difficult infrastructure impact.
- Boundary validation tests, controlled exercises, retained configuration evidence, denied-action records, and monitoring for bypass attempts.
Out of scope:
- The identity or authority model for who delegated work to the agent. That belongs mostly to
AWS2-DEL. - The runtime decision engine for allowing, denying, pausing, or rolling back individual actions. That belongs mostly to
AWS2-RUN. - Skill, tool, connector, plugin, or supplier provenance. That belongs mostly to
AWS2-SRC. - Prompt, memory, retrieval, and instruction-source boundaries. Those belong mostly to
AWS2-CTX. - Secrets, credentials, personal data, and sensitive-record handling. Those belong mostly to
AWS2-SEC. - General endpoint hardening, full cloud security, full network security, or a complete enterprise security baseline.
Level Summary
Levels are cumulative. Level 2 builds on Level 1, and Level 3 builds on both.
| Level | Plain-language meaning | Why this level exists | Typical evidence |
|---|---|---|---|
| Level 1 | The organization can explain what workspace resources and execution capabilities agents can reach, and which boundaries are supposed to limit them. | A reviewer cannot judge risk until the reachable files, systems, tools, networks, and execution paths are visible. | Reachable-resource inventory, execution-capability inventory, boundary description, known-exclusion list. |
| Level 2 | Production workflows enforce scoped access and require review for broad-impact workspace actions. | Production agent activity needs repeatable boundaries, not only documentation of what agents might reach. | Sandbox or environment profile, connector scope, repository scope, network egress policy, filesystem monitoring, approval policy, rollback point. |
| Level 3 | High-impact boundaries are tested, retained as evidence, and monitored for bypass attempts. | Sensitive or high-impact environments need evidence that boundaries work and that attempts to cross them are visible. | Boundary validation report, retained configuration evidence, denied-action logs, bypass-monitoring review, containment exercise record. |
Candidate Controls
AWS2-WSB-L1-001: Reachable Resource Inventory Level 1
Requirement summary
Identify the workspace resources agents can read, write, execute, send to, or otherwise modify, including local files, repositories, SaaS systems, browsers, shells, network endpoints, and shared workspace resources where applicable.
Why it exists
Agent risk depends on what the agent can reach. A system that can only read a narrow folder has a different boundary than a system that can edit repositories, use browser sessions, reach SaaS tools, send messages, and connect to internal network endpoints.
Why this level
This belongs at Level 1 because resource visibility is the foundation for any workspace boundary review. It does not require strong enforcement yet; it requires a reviewable inventory of reachable resources.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Reachable-resource inventory | Workspace or endpoint owner with runtime owner input | Before production use and after adding resources, connectors, repositories, or tools | Files, repositories, shared drives, SaaS systems, browser paths, shells, network endpoints, and other resources reachable by agents | Identifies reachable resources; does not prove access is correctly enforced or complete. |
| Connector and application reachability summary | Runtime platform owner or workspace owner | Before enabling connectors and after connector changes | Which apps, hosted services, and connector scopes are reachable from the scoped agentic workspace | Supports reachability review; does not prove least privilege or data-safety controls. |
AWS2-WSB-L1-002: Execution Capability Inventory Level 1
Requirement summary
Identify whether agents can execute shell commands, scripts, code, browser automation, package installation, or other local automation, and distinguish read-only, write-capable, execution-capable, and externally transmitting access.
Why it exists
Execution changes the risk profile. Reading a file, editing a file, running code, installing packages, automating a browser, and transmitting data outside the workspace are materially different capabilities.
Why this level
This belongs at Level 1 because reviewers need a clear capability inventory before they can decide which boundaries, approvals, logs, and tests are appropriate.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Execution-capability inventory | Workspace or endpoint owner with runtime owner input | Before production use and after enabling shell, browser, package, script, or automation features | Whether agents can read, write, execute, install, automate browsers, or transmit externally | Shows declared capabilities; does not prove denied paths cannot be reached. |
| Tool or runtime capability summary | Runtime platform owner | Before release and after runtime configuration changes | Which runtime features, tool categories, shell modes, browser modes, and external-transmission paths are available | Supports review of available capability classes; does not prove every tool call is mediated. |
AWS2-WSB-L1-003: Boundary Description And Exclusions Level 1
Requirement summary
Document filesystem, repository, network, sandbox, browser, hosted-service, or application boundaries used to limit agent access, including known exclusions from the boundary.
Why it exists
A boundary is only useful for review if people can understand where it starts, where it ends, and where it does not apply. Known exclusions matter because an agent might still reach a path through an unsandboxed browser, a shared mount, a connector, an inherited session, or a network route.
Why this level
This belongs at Level 1 because the first assurance step is a named and reviewable boundary. Stronger enforcement, testing, retention, and monitoring come later.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Workspace boundary description | Workspace or endpoint owner | Before production use, before review, and after boundary changes | Filesystem, repository, browser, network, sandbox, hosted-service, and application boundaries, plus known exclusions | Describes intended boundaries; does not prove they are enforced. |
| Known-exclusion register | Organization or governance owner with workspace owner input | Before production use and after discovering or accepting exclusions | Boundary gaps, unsupported resources, inherited access, bypass paths, rationale, owner, and review status | Makes exclusions visible; does not make them acceptable or safe. |
AWS2-WSB-L2-001: Scoped Production Access Level 2
Requirement summary
Enforce scoped access for production workflows so agents cannot freely read, write, execute, or transmit outside the approved workspace boundary, including through shells, browser automation, connectors, repository access, or network egress where applicable.
Why it exists
Production workflows need actual constraints. Without enforced scope, an agent may use an allowed tool, inherited session, connector, shell, browser, repository checkout, or network path to reach resources outside the approved boundary.
Why this level
This belongs at Level 2 because production operation requires more than an inventory and boundary description. The system should show configured or enforced limits that map to the approved scope.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Sandbox or environment profile | Workspace or endpoint owner | Before production use and after environment changes | Filesystem, process, shell, browser, package, network, and workspace limits for production workflows | Supports enforcement review; does not prove no escape or inherited access exists. |
| Network egress or connector policy | Workspace, network, or runtime platform owner | Before production use and after egress or connector-scope changes | Allowed destinations, denied destinations, connector scopes, external-transmission rules, and policy owner | Supports scope review; does not prove every outbound path is covered. |
| Repository or filesystem scope configuration | Workspace or endpoint owner | Before production use and after repository or storage changes | Approved repositories, folders, mounts, write locations, protected paths, and denied paths | Supports filesystem and repository review; does not prove all local or synced paths are covered. |
AWS2-WSB-L2-002: Broad-Impact Workspace Action Review Level 2
Requirement summary
Require review or approval before agents perform workspace actions with broad filesystem impact, production write impact, access-control impact, external communication impact, sensitive-data movement, or rollback-difficult infrastructure impact.
Why it exists
Some workspace actions are difficult to undo or create wide impact. Examples include bulk edits, production writes, access changes, external sends, sensitive exports, infrastructure changes, package installs, and destructive file operations.
Why this level
This belongs at Level 2 because managed production operation needs a repeatable review or approval rule for broad-impact actions, not only a general statement that the workspace has boundaries.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Broad-impact action policy | Organization or governance owner with runtime and workspace owner input | Before production use and after action-class changes | Which filesystem, production, access-control, external-communication, sensitive-data, and infrastructure actions require review or approval | Shows intended review triggers; does not prove every trigger is detected. |
| Approval or review receipt | Runtime platform owner or evidence owner | At request and approval time | Action class, scope, requester, approver or reviewer, decision, timestamp, conditions, and outcome | Supports review of selected actions; does not prove the action was safe or legally sufficient. |
AWS2-WSB-L2-003: Boundary Control Set Level 2
Requirement summary
Use sandboxing, environment profiles, repository scopes, connector scopes, network egress restrictions, filesystem monitoring, rollback points, or equivalent controls to separate low-risk work from high-impact work where applicable.
Why it exists
Different work deserves different containment. Low-risk drafting or local analysis should not automatically run with the same filesystem, network, connector, and production access as high-impact deployment or external communication work.
Why this level
This is a Level 2 SHOULD because it is a practical production containment pattern. The exact controls may vary by environment, but the system should show how low-risk and high-impact work are separated where applicable.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Environment profile matrix | Workspace or endpoint owner | Before production use and after profile changes | Low-risk, standard, and high-impact profiles with associated filesystem, network, connector, shell, browser, and rollback controls | Supports profile review; does not prove profiles are always selected correctly. |
| Rollback or containment record | Workspace, runtime, or operations owner | Before high-impact use and after rollback or containment exercises | Rollback points, containment options, owner, triggering conditions, and exercise or use results | Supports reversibility review; does not prove every high-impact action can be reversed. |
| Filesystem or boundary monitoring policy | Workspace or endpoint owner | Before production use and after monitoring changes | Monitored paths, denied writes, protected locations, alert routing, and review cadence | Supports monitoring review; does not prove all bypasses are detected. |
AWS2-WSB-L3-001: Boundary Enforcement Validation Level 3
Requirement summary
Validate boundary enforcement for high-impact environments through tests, reviews, or controlled exercises, including attempts to cross filesystem, repository, network, connector, or execution boundaries that are material to the assessment.
Why it exists
Boundaries can look correct in documentation and still fail in practice. High impact environments need tests or exercises that attempt material boundary crossings, such as writing outside an allowed folder, reaching a blocked endpoint, using an unapproved connector, or executing an unsupported command.
Why this level
This belongs at Level 3 because validation adds higher assurance beyond configured controls. It is especially important where a boundary failure could affect production, sensitive data, external commitments, or business continuity.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Boundary validation report | Evidence or audit owner with workspace and runtime owner input | During validation, before high-impact release, or during periodic review | Tested filesystem, repository, network, connector, browser, and execution boundary scenarios; expected results; actual results; findings; remediation | Supports selected boundary-validation claims; does not prove every bypass path was tested. |
| Controlled boundary exercise record | Workspace or endpoint owner with evidence owner review | During tabletop, red-team, or controlled exercise | Attempted boundary crossings, detection or denial behavior, containment, rollback, and follow-up actions | Supports exercise review; does not prove real attackers or malformed tools cannot bypass controls. |
AWS2-WSB-L3-002: Retained Boundary Configuration Evidence Level 3
Requirement summary
Retain evidence of boundary-relevant configuration for material production periods, including sandbox, deployment, network, filesystem, repository, browser, and connector-scope configuration where applicable.
Why it exists
A review after an incident, audit period, or material change needs to know which boundary configuration was active at the time. If configuration evidence is overwritten or not retained, the organization may be unable to reconstruct what protections existed.
Why this level
This belongs at Level 3 because retained configuration evidence supports higher-assurance review over time. It goes beyond having controls now by preserving what was in effect during material production periods.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Boundary configuration snapshot | Workspace, endpoint, network, or runtime platform owner | At release, after material configuration changes, and during review periods | Sandbox, deployment, network, filesystem, repository, browser, connector, and environment-scope settings in effect for the named period | Supports historical review; does not prove settings were complete or tamper-proof. |
| Configuration change record | Workspace or operations owner | When boundary-relevant configuration changes | Change owner, date, rationale, approved scope, affected resources, review decision, and rollback or remediation path | Supports change traceability; does not prove the changed boundary was effective. |
AWS2-WSB-L3-003: Boundary Bypass Monitoring Level 3
Requirement summary
Monitor for attempts to bypass workspace boundaries, including denied file writes, denied command execution, unexpected connector use, unexpected network egress, sandbox escapes, or policy-triggered access outside the approved scope.
Why it exists
Denied and unexpected activity can show that a boundary is being tested, misconfigured, or abused. Monitoring these attempts helps the organization detect policy gaps, tool misuse, unsafe prompts, malicious skills, or boundary drift.
Why this level
This is a Level 3 SHOULD because ongoing bypass monitoring is a stronger assurance practice. It can require integration between runtime logs, endpoint controls, network controls, connector telemetry, and review workflows.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Denied-action or boundary-trigger log | Runtime platform owner, workspace owner, or evidence owner | During operation and review sampling | Denied file writes, denied commands, blocked network egress, blocked connector use, sandbox triggers, policy outcome, timestamp, and associated workflow | Supports bypass monitoring review; does not prove all bypass attempts are logged. |
| Boundary monitoring review | Evidence or audit owner with workspace owner input | Periodically and after material alerts | Alert patterns, unexpected boundary attempts, triage decisions, remediation, exceptions, and follow-up tests | Supports monitoring process review; does not prove absence of undetected bypasses. |
External Mapping Notes
The family-first crosswalk treats AWS2-WSB as a candidate-control family shaped by sandboxing, deployment architecture, infrastructure containment, filesystem monitoring, network restriction, connector boundary, and rollback signals. It should stay tied to concrete workspace, endpoint, runtime, configuration, and validation evidence rather than broad claims about endpoint or cloud security.
Relevant source signals include:
- OWASP AISVS contributes workload sandboxing and tool or plugin containment signals. Its public
v0.1status and incubator posture do not proveaws2or AISVS conformance. - AIUC-1 contributes useful comparator signals around deployment model, infrastructure, MCP or A2A transport, interface security, MFA, TLS or OIDC, and scans, but there is no AIUC-1 certificate equivalence.
- OWASP Agentic Skills Top 10 contributes sandboxing, network restriction, and filesystem monitoring signals for agentic skill and tool risk.
- CSA MAESTRO contributes deployment, infrastructure, container, and orchestration threat-modeling signals, but not a hardening test suite.
- Five Eyes agentic AI adoption guidance contributes practical signals around incremental deployment, resilience, reversibility, security controls, and containment.
Formal Standard Link
Use this guide with the formal AWS2-WSB candidate requirements. If the guide and the standard draft disagree, the standard draft controls.