System Boundary And Responsibility Owners

7.1 Boundary Requirement

Every future awoss assessment, mapping, or implementation claim should begin with a system boundary. The boundary should be specific enough that a reviewer can identify the agents, humans, tools, resources, runtime, authority paths, evidence sources, owners, and exclusions involved.

A boundary that only says "our AI agent platform" or "our workspace" is not sufficient. The boundary must explain what the agent can observe and what the agent can do.

7.2 Required Boundary Elements

A scope record should identify the following boundary elements when they exist:

• human users who delegate work to agents
• approvers, reviewers, administrators, and control owners
• agent runtimes and orchestration components
• agent-associated identities, user identities, service accounts, or delegated authority paths
• tools, skills, connectors, plugins, scripts, and helper services
• local and shared files, repositories, documents, knowledge bases, and workspace systems reachable by agents
• shells, code execution environments, browsers, desktop apps, SaaS systems, mail, calendar, chat, and ticketing systems reachable by agents
• memory, context, retrieval, and instruction sources that can influence action-taking behavior
• approval gates, runtime policies, denied-action paths, and emergency-stop mechanisms
• logs, receipts, validation outputs, evidence stores, and evidence owners
• external systems and third-party providers in scope
• exclusions, assumptions, inherited controls, and claim limits

7.3 Primary Trust Boundaries

awoss treats the following as primary trust boundaries:

• human to agent delegation
• runtime policy layer to tool or action execution
• agent-associated identity to user or organization identity
• local workspace to external services and shared resources
• trusted skill or tool sources to untrusted or newly introduced sources
• memory, retrieval, and context inputs to action-taking components
• evidence records to mutable operational systems

Candidate controls should make these boundaries visible and reviewable.

7.4 Responsibility Owner Categories

Every future control should identify one primary responsibility owner. Shared responsibility can be documented, but one owner should be accountable for making the control real for the scoped system.

Workspace or endpoint owner:

• owns workstation, file, repository, shell, browser, SaaS, network, sandbox, and local execution boundaries
• typically includes IT, endpoint engineering, platform engineering, repository administrators, or workspace system owners

Runtime platform owner:

• owns agent orchestration, tool invocation, memory behavior, policy enforcement, approval gates, event generation, and runtime controls
• may be an internal platform team, agent runtime vendor, or orchestration provider

Skill or skill-set source owner:

• owns reusable skills, prompts, scripts, connectors, tool definitions, dependencies, source trust, update paths, and capability declarations
• may be a skill author, package maintainer, integration developer, or source repository maintainer

Organization or governance owner:

• owns policy decisions, risk acceptance, role assignment, training, deployment rules, exceptions, third-party review, and business accountability
• typically includes security leadership, risk, compliance, procurement, internal audit, legal, or the business system owner

Evidence or audit owner:

• owns evidence collection, retention, validation outputs, audit readiness, review procedures, evidence redaction, and evidence integrity
• may be an assurance team, internal audit, compliance operations, external assessor, or evidence pipeline maintainer

7.5 Owner Assignment Rules

Owner assignment should follow these rules:

• Assign the owner who can most directly implement or remediate the control.
• If a control is mainly about proof rather than prevention, prefer the evidence or audit owner.
• If a control is mainly about policy, risk acceptance, or business approval, prefer the organization or governance owner.
• If a control is inherited from a provider or another team, identify both the inherited source and the local owner responsible for accepting that inheritance.
• Do not assign ownership to "the AI" or "the agent." Human, organizational, or provider ownership must remain explicit.

7.6 Boundary Change Management

Material changes to the boundary should trigger review. Material changes include:

• adding a new runtime, agent, or sub-agent
• adding a new high-impact tool, connector, or skill source
• expanding filesystem, repository, SaaS, shell, or network access
• changing identity, credential, or delegated-authority paths
• changing approval policies for high-impact actions
• changing evidence retention or log generation
• changing external providers or third-party dependencies
• moving from pilot to production use

At Level 1, boundary changes should be documented. At Level 2, boundary changes should be reviewed by named owners. At Level 3, boundary changes should be subject to stronger change control, validation, and evidence retention.