Family Guides
AWOSS-SCP: Scope, Inventory, And Ownership
Start with the review boundary. AWOSS-SCP gives an agentic workspace system a name, a map, accountable owners, and explicit exclusions before anyone tries to judge its security posture.
A reviewer should be able to tell which agent runtimes are included, what they can reach, which tools or skills are available, what context or memory can influence them, and which nearby systems are deliberately outside the scope.
That clarity is easy to lose. One workflow can span a desktop workspace, repositories, local files, SaaS tools, retrieval sources, chat history, memory, shell commands, approval steps, and evidence exports. Without a stable scope record, every later control review rests on guesswork.
What This Family Covers
In scope:
- The named system boundary for the assessed agentic workspace system.
- Agent runtimes, tools, skills, connectors, workspace resources, data sources, context sources, retrieval sources, memory sources, users, approvers, administrators, and evidence owners.
- Explicit exclusions that a reviewer could otherwise confuse with the scoped system.
- Ownership across workspace or endpoint, runtime platform, skill or skill-set source, organization or governance, and evidence or audit responsibilities.
- Inventory processes, boundary-change review, historical scope records, and drift review.
Out of scope:
- Whether access is technically enforced. That belongs mostly to
AWOSS-WSB,AWOSS-RUN,AWOSS-SEC, and related families. - Whether a delegated action is authorized. That belongs mostly to
AWOSS-DELandAWOSS-RUN. - Whether logs are complete and protected. That belongs mostly to
AWOSS-LOG. - Whether validation proves controls are effective. That belongs to
AWOSS-VAL.
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 name the system, its boundary, key parts, owners, and exclusions. | A reviewer needs a stable target before reviewing controls or claims. | Scope record, owner matrix, exclusion list, intended-use note, basic component map. |
| Level 2 | The organization keeps the inventory repeatable and reviews material boundary changes before production use. | Production systems change through new tools, connectors, data sources, delegated authority, and evidence claims. | Inventory export, boundary-change record, approval record, reconciliation result. |
| Level 3 | The organization can reconstruct prior production scope and independently review high-impact boundary changes or drift. | High-impact or sensitive systems need evidence of what agents could access at the relevant time, not only what is approved today. | Historical scope records, separated review records, drift report, exception or remediation record. |
Candidate Controls
AWOSS-SCP-L1-001: Scope Record Level 1
Requirement summary
Maintain a scope record that identifies the agent runtimes, connected tools, skills, connectors, workspace resources, data or context sources, memory sources where applicable, human users, approvers, administrators, and evidence owners that are in scope.
Why it exists
Without one scope record, different teams may review different systems while using the same claim. One team might mean the agent runtime, another might include the user's workstation, and another might include repositories, retrieval stores, and Slack or mail connectors. The scope record prevents that ambiguity.
Why this level
This belongs at Level 1 because every later control depends on knowing what system is being discussed. It does not require automation or historical reconstruction yet; it requires a named, reviewable baseline.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Scope record | Organization or governance owner | Before review and before any alignment claim | System name, assessment date, in-scope runtimes, tools, connectors, resources, owners, and evidence sources | Shows what is named in scope; does not prove controls are enforced. |
| Tool, data, memory, and component map | Runtime platform owner with workspace owner input | Before use and after material changes | How runtimes, tools, repositories, data categories, retrieval sources, and memory sources relate to the system | Supports boundary review; does not prove safe data handling or access isolation. |
AWOSS-SCP-L1-002: Explicit Exclusions Level 1
Requirement summary
Identify out-of-scope systems, resources, data sources, context sources, roles, or action classes that a reviewer could reasonably confuse with the assessed boundary.
Why it exists
Agentic work often sits next to adjacent systems. If exclusions are not visible, a reader may assume that the assessment covers nearby repositories, personal workspaces, production systems, shared drives, other teams' connectors, or action classes that were never reviewed.
Why this level
Exclusions are a foundation requirement because they keep early claims honest. Level 1 does not require continuous discovery of every possible adjacent system; it requires enough explicit exclusions to avoid misleading review boundaries.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Exclusion list in the scope record | Organization or governance owner | Before review and before external mapping statements | Systems, roles, data sources, connectors, or action classes excluded from review | Clarifies claim scope; does not prove excluded resources are technically unreachable. |
| Intended-use and impact note | Business owner with security review input | Before production use or pilot approval | Expected workflows, impact assumptions, and areas intentionally not covered | Supports reader understanding; does not establish legal classification or production readiness. |
AWOSS-SCP-L1-003: Responsibility Owner Model Level 1
Requirement summary
Assign at least one named owner or owner group for workspace or endpoint, runtime platform, skill or skill-set source, organization or governance, and evidence or audit responsibilities.
Why it exists
Agentic workspace security crosses multiple ownership areas. If nobody owns a category, follow-up work can stall: one team may control endpoint access, another runtime policy, another skill source review, another legal or governance claims, and another evidence exports.
Why this level
Level 1 needs named responsibility even if the ownership model is simple. More advanced levels add repeatability, review, and separation, but the first step is knowing who can answer questions.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Owner matrix | Organization or governance owner | Before review and refreshed when teams or responsibilities change | Owner groups for workspace, runtime, source trust, governance, and evidence responsibilities | Shows accountability routing; does not prove owners performed reviews. |
| Evidence owner list | Evidence or audit owner | Before evidence collection | Who can produce inventories, logs, approvals, validation records, and claim-limit records | Supports evidence collection; does not prove evidence completeness. |
AWOSS-SCP-L2-001: Repeatable Inventory Process Level 2
Requirement summary
Maintain a repeatable inventory process for in-scope runtimes, tools, skills, connectors, repositories, workspace resources, data categories, memory or retrieval sources, and external systems reachable by agents.
Why it exists
Production agentic systems change. A one-time list can become stale as teams add connectors, install skills, grant repository access, add retrieval indexes, change memory behavior, or expose new SaaS systems.
Why this level
This belongs at Level 2 because it adds managed repeatability beyond the initial Level 1 scope record. The organization should be able to produce a current inventory through a known process rather than recreate it manually from memory.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Runtime and tool inventory export | Runtime platform owner | During operation and before production review | Runtimes, tools, connectors, skills, versions, owners, and availability state | Shows configured or available items; does not prove each item is approved or safe. |
| Connected resource inventory | Workspace or endpoint owner | During operation and after access changes | Repositories, files, SaaS systems, shells, networks, and data categories reachable by agents | Supports reachability review; should avoid raw confidential payloads and does not prove boundary enforcement. |
AWOSS-SCP-L2-002: Material Boundary-Change Review Level 2
Requirement summary
Review material boundary changes before production use, including new high-impact tools, expanded filesystem or repository access, new connectors, new delegated authority paths, or changed evidence collection or claim scope.
Why it exists
Agentic risk can change when a new tool, connector, authority path, or data source is added. Even if each change seems small, it can alter what the agent can observe, decide, or invoke.
Why this level
This belongs at Level 2 because production boundary changes need repeatable review before use. Level 1 can describe the starting boundary, but Level 2 asks the organization to manage boundary changes as the system evolves.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Boundary-change record | Organization or governance owner with runtime owner input | Before production use of the change | Changed tools, connectors, resources, authority paths, evidence scope, reviewer, decision, and date | Supports change review; does not prove all technical enforcement was tested. |
| Scope review or approval record | Organization or governance owner | Before production use or release | Approval status, reviewer role, rationale, conditions, and follow-up actions | Shows review happened for the named change; does not certify system security. |
AWOSS-SCP-L2-003: Inventory Reconciliation Level 2
Requirement summary
Reconcile runtime configuration, tool availability, and source inventories against the approved scope record on a periodic or release-driven basis.
Why it exists
Drift can appear between what is approved and what is actually available. Tools can remain enabled after a pilot, connectors can be added outside the normal review path, and source inventories can fall behind runtime state.
Why this level
This is a Level 2 SHOULD because reconciliation is a managed production practice that improves confidence in the inventory. Some early systems may do it manually, but the expectation should become routine for production use.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Reconciliation report | Runtime platform owner with evidence owner support | Periodically or before release | Differences between approved scope records, runtime configuration, available tools, and source inventories | Supports drift detection; does not prove every unauthorized path was impossible. |
| Remediation or exception record | Organization or governance owner | After reconciliation finds a difference | Whether the difference was approved, removed, time-limited, or assigned for remediation | Shows handling of known differences; does not prove unknown differences do not exist. |
AWOSS-SCP-L3-001: Historical Scope Records Level 3
Requirement summary
Retain historical scope records for material production periods so reviewers can reconstruct what agents could observe or invoke at the time of a relevant event.
Why it exists
Incident review, audit review, legal review, and high-impact workflow review often happen after the fact. A current scope record is not enough if the system had different tools, connectors, repositories, memory sources, or owners at the time of the event.
Why this level
This belongs at Level 3 because it supports higher assurance. The system must keep past boundary evidence, not only the latest approved state.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Historical scope records | Evidence or audit owner | During material production periods and retained after changes | Time-bounded records of in-scope runtimes, tools, resources, context sources, owners, and exclusions | Supports reconstruction; does not prove action-level traceability without AWOSS-LOG evidence. |
| Versioned inventory snapshots | Runtime platform owner or evidence owner | At releases, material changes, or scheduled intervals | What was configured or available at the relevant period | Supports review of past state; does not prove each action used every listed item. |
AWOSS-SCP-L3-002: Separated Review For High-Impact Boundary Changes Level 3
Requirement summary
Require independent or separated review for material boundary changes that introduce high-impact action authority, sensitive data access, production write access, or new trusted runtime or skill sources.
Why it exists
The same person or team that wants a powerful new capability may miss the full risk of adding it. High-impact boundary changes deserve review by someone with enough separation to challenge assumptions and record conditions.
Why this level
This is Level 3 because it adds stronger assurance for changes that could materially affect business operations, sensitive data, production systems, or trusted execution paths.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Independent boundary-review record | Organization or governance owner | Before high-impact production use | Reviewer independence or separation, change summary, risk rationale, decision, conditions, and date | Supports higher-assurance review; does not prove the technical control design is sufficient. |
| High-impact access change package | Runtime platform owner with workspace and source owners | Before approval | New action authority, sensitive data access, production write path, or trusted source added to scope | Helps reviewers understand impact; does not by itself authorize use. |
AWOSS-SCP-L3-003: Drift Detection And Review Level 3
Requirement summary
Detect and review drift between approved scope records and observed runtime, connector, skill, or workspace state.
Why it exists
For high-assurance systems, waiting for a manual inventory review may be too slow. Drift can indicate unauthorized connector installation, disabled boundary controls, newly reachable repositories, unexpected memory sources, or a source-trust gap.
Why this level
This is a Level 3 SHOULD because stronger drift detection may require monitoring, integrations, or review capacity that not every Level 1 or Level 2 system has. For sensitive or high-impact systems, it becomes a practical way to notice when the real boundary no longer matches the approved one.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Drift detection report | Runtime platform owner or evidence owner | During operation and after detected drift | Observed mismatch, source of observation, affected component, decision, and remediation status | Supports drift review; does not prove all drift types are detectable. |
| Drift review log | Organization or governance owner | After detection and during periodic review | Triage owner, risk rating, acceptance or remediation, and closure evidence | Shows known drift was reviewed; does not prove no unreviewed drift remains. |
External Mapping Notes
The family-first crosswalk treats AWOSS-SCP mostly as a source of evidence for scope, inventory, ownership, intended use, component mapping, and boundary review.
Relevant source signals include:
- EU AI Act role and scoped deployer/provider analysis maps to evidence for role clarity, but does not determine legal classification.
- OWASP Agentic Skills Top 10 supports skill inventory, owner mapping, installation approval, and incident-response evidence, but does not define a full workspace boundary.
- CSA AI Controls Matrix supports structured scope, lifecycle, role, ownership, and control-applicability evidence.
- CSA MAESTRO and MITRE ATLAS are useful advisory inputs for architecture and threat-model scoping, but they are not boundary-conformance standards.
- NIST AI RMF and NIST AI 600-1 support intended-use, impact, risk-context, generative-AI profile, and use-case inventory evidence.
- ISO/IEC 42001 and ISO/IEC 23894 support management-system and risk-scope evidence, but do not create an
awossassessment boundary by themselves. - Five Eyes agentic AI adoption guidance supports component inventories and tool, data, memory, workflow, and privilege mapping.
Formal Standard Link
Use this guide with the formal AWOSS-SCP candidate requirements. If the guide and the standard draft disagree, the standard draft controls.