Introduction

AI agents and agentic assistants increasingly operate inside business workspaces rather than isolated chat windows. They can read context, call tools, update files, run shell commands, use browsers, query knowledge bases, interact with SaaS systems, invoke skills or connectors, draft messages, and coordinate multi-step work across local and shared resources.

That shift changes the security problem. A model-safety review alone does not answer whether the surrounding workspace is safe for delegated agentic work. The security outcome depends on the combined system: the human delegation model, runtime action controls, endpoint and workspace boundaries, identity and credential handling, tool and skill provenance, context isolation, approval gates, logs, receipts, validation practices, and governance decisions.

aws2 currently profiles that combined system. It focuses on business agentic workspaces: environments where agents can observe workspace context and take actions through files, shells, applications, repositories, documents, communication systems, connectors, or other connected resources on behalf of people or organizations. The current workstream may support a future standalone standard only if the integrated profile proves distinct control value, credible evidence expectations, and plausible governance.

2.1 Problem Statement

Business agentic work creates risks that are not fully captured by generic AI governance checklists or generic endpoint-security baselines:

• agents may act with delegated human or organizational authority
• tools and connectors may create changes outside the chat interface
• local context, memory, and retrieved documents may influence action-taking behavior
• skills, prompts, plugins, scripts, and connectors may introduce supply-chain risk
• approvals may be missing, ambiguous, or hard to reconstruct
• logs may record outputs without proving what policy allowed or denied
• security evidence may expose secrets or private business content if not designed carefully

The core aws2 design question is: what should a scoped business workspace have in place before agents can defensibly observe context, invoke tools, and take actions with material impact, and how can that control posture be mapped to existing standards without implying unsupported compliance or certification?

2.2 Target Audience

This draft is written for:

• organizations deploying AI agents in business workspaces
• agent runtime and orchestration platform teams
• security, risk, compliance, and internal audit teams
• endpoint, identity, and workspace administrators
• maintainers of tools, connectors, plugins, skills, and skill sets
• reviewers evaluating whether agentic workflows have defensible boundaries and evidence

2.3 Relationship To Existing Standards And Guidance

aws2 is designed to map to and complement existing work. It does not replace OWASP, CSA, NIST, ISO, MITRE, AIUC-1, or government cyber guidance.

The working model is:

• OWASP AISVS informs levelled, testable AI security requirements.
• OWASP agentic AI materials inform agentic threat taxonomy and risk language.
• CSA AARM informs runtime action interception, policy decisioning, and tamper-evident records for agent actions.
• CSA AI Controls Matrix and CSA MAESTRO inform enterprise control objectives and layered agentic threat modeling.
• NIST AI RMF and NIST AI 600-1 inform governance, mapping, measurement, and risk-management structure.
• ISO/IEC 42001 and ISO/IEC 23894 inform management-system and risk-management context.
• AIUC-1 informs the market pattern of agent security, safety, reliability, scoping, certification, and evidence claims.
• Five Eyes agentic AI guidance informs conservative deployment defaults, least privilege, visibility, human oversight, and careful adoption.
• MITRE ATLAS informs adversary technique mapping and red-team scenarios.

aws2 should provide a focused profile for agentic workspace security and a practical evidence model for that boundary. It should close practical gaps left by using any one referenced framework alone while avoiding equivalence, compliance, or certification claims unless a future release profile and crosswalk support a specific bounded statement.

2.4 Design Goals

aws2 should:

• stay profile-first until release, governance, validation, and claim-review rules exist
• define a clear unit of assessment for agentic workspace systems
• separate runtime, workspace, skill or skill-set source, governance, and evidence responsibilities
• support levelled assurance for pilots, production systems, and high-impact environments
• make high-impact agent actions visible, gated, and reviewable
• make skill, tool, connector, and workflow provenance reviewable
• define evidence artifacts that can be shared or summarized without exposing secrets or confidential payloads
• keep claim language conservative until validation and governance exist

aws2 should avoid:

• presenting the working draft as a released standalone standard
• becoming a generic AI ethics framework
• becoming a full enterprise security baseline
• treating one runtime, repository, or product as the whole standard
• implying certification before a real certification path exists
• replacing external standards where mapping is the more defensible posture