Terms And Definitions

This section defines working-draft terms. Definitions may be refined as the control families and crosswalk are completed. Terms are ordered alphabetically.

4.1 Agent

An AI-enabled system component that can interpret a user or system objective, use context, make or suggest decisions, and invoke tools or workflows to make progress toward that objective.

4.2 Agentic Workspace System

The scoped environment in which AI agents can observe workspace context and take actions through tools, applications, files, shells, repositories, documents, communication systems, connectors, or other connected resources on behalf of people or organizations.

4.3 Approval Gate

A policy or workflow checkpoint that requires explicit authorization before an agent or runtime may perform a defined action or class of actions.

4.4 Candidate Requirement

A draft requirement that expresses intended control behavior but has not yet been finalized in a released aws2 version.

4.5 Connector

An integration boundary that connects an agent runtime to a resource domain such as an application, service, data source, communication channel, local environment, or external system.

A connector is not the action itself. It defines or supplies the reachability, authentication path, authorization scope, account or session binding, tenant or workspace boundary, data-access boundary, and transport context through which tools operate.

A connector may expose one or more tools. For example, a Slack connector may bind the runtime to a specific Slack workspace, identity, token scope, and API surface; tools exposed through that connector may search messages, draft replies, send messages, or create canvases.

4.6 Control Family

A group of related candidate requirements organized around one security objective and one dominant layer of the agentic workspace system.

4.7 Control Owner

The person, team, vendor, or organizational function responsible for implementing, maintaining, or proving a control for the scoped system.

4.8 Delegated Authority

The authority an agent uses or appears to use when acting on behalf of a user, role, service account, organization, or workflow. Delegated authority may be technical, organizational, or both.

4.9 Evidence Artifact

A durable record that supports review of a control, decision, event, configuration, source, approval, validation result, or claim. Evidence artifacts should be scoped, attributable, time-bounded, and reviewable without unnecessary exposure of secrets or confidential payloads.

4.10 Evidence State

The assessed state of reviewable evidence for a candidate requirement. The working-draft states are evidence available, evidence partial, evidence unavailable, and evidence not required for draft review.

4.11 High-Impact Action

An action that can materially affect confidentiality, integrity, availability, finances, legal position, customer commitments, external communications, production systems, access control, safety, or other material business outcomes.

Examples may include:

• sending external communications
• changing access controls
• committing or deploying code
• executing shell commands with broad filesystem, network, or production impact
• modifying production data
• deleting or overwriting important records
• installing or updating trusted skills, plugins, tools, or connectors
• sharing confidential information outside the approved boundary

4.12 Implementation State

The assessed state of a candidate requirement for a scoped system. The working-draft states are implemented, partially implemented, planned, not implemented, and not applicable with rationale.

4.13 Inherited Control

A control whose implementation or evidence is supplied by another system, team, provider, or governance process outside the direct owner of the assessed agentic workspace system.

4.14 Receipt

A structured evidence artifact that records a specific event or decision, typically including a stable identifier, timestamp, actor or system identity, action class, scope, policy result, approval state, and redaction-safe metadata.

4.15 Released Version

A future version of the standard designated as released through the repository manifest and changelog. Released versions should be append-only except for explicit errata.

4.16 Responsibility Owner

The primary owner category used by aws2 to classify accountability for a control. The current owner categories are:

• workspace or endpoint owner
• runtime platform owner
• skill or skill-set source owner
• organization or governance owner
• evidence or audit owner

4.17 Runtime Platform

The software layer that receives objectives, manages agent state, mediates tool calls, applies policies, invokes tools or connectors, records execution events, and coordinates approvals or other controls before, during, or after agent actions.

4.18 Skill Or Skill Set

A skill is a reusable unit of agent behavior, instructions, prompts, scripts, tool-use guidance, or workflow logic that can be installed, selected, invoked, or updated by a user, workspace, runtime, or agent.

A skill set is a collection, bundle, package, repository, catalogue, or distribution of one or more skills. Where this draft says "skill or skill set", the requirement applies to both individual skills and grouped or distributed skills.

4.19 Tool

A discrete callable operation exposed to an agent or runtime. A tool has action semantics: it may observe information, perform computation, communicate with a system, transform data, or change a workspace resource.

A tool may be native to the runtime or exposed through a connector. It is assessed primarily by what operation it can perform, what inputs it accepts, what outputs or side effects it can produce, and whether the operation is high-impact.

For example, search messages, draft reply, send message, and create canvas are tools. The Slack connector is the integration boundary that makes those tools available for a particular Slack workspace, identity, token scope, and API surface.

4.20 Working Draft

A mutable draft of the standard that is available for internal design, mapping, review, and implementation experiments, but that does not create a released standard or public conformance claim.

4.21 Workspace Resource

A local, shared, or remote resource available inside the work environment that an agent can observe, modify, invoke, query, send to, or use as context. Examples include files, repositories, documents, knowledge bases, shells, calendars, mailboxes, chat systems, SaaS applications, and development tools.