Persistent Workspace Hygiene Governance

2. Summary

Persistent Workspace Hygiene Governance requires that every AI agent with access to a persistent workspace — a filesystem, database, scratchpad, code repository, container volume, or any storage that survives beyond a single interaction turn — operates under a structurally enforced hygiene policy that governs what data may be written to the workspace, how long it persists, what classification controls apply, when it must be purged, and who (or what) may access it across sessions. The workspace is enforced at the storage layer, not by the agent's own judgment about what to keep or discard. Without this dimension, an agent with persistent storage accumulates operational residue — credentials cached in temporary files, intermediate results containing personal data, API responses with sensitive payloads, debug logs with production data — that grows monotonically across sessions. This residue creates an expanding attack surface, a compliance liability under data minimisation regulations, and a cross-contamination vector where data from one task leaks into the context of a subsequent unrelated task. AG-125 ensures that workspaces are governed artefacts with defined lifecycle policies, classification boundaries, and structural purge mechanisms that the agent cannot override or defer.

3. Example

Scenario A — Credential Residue in Persistent Scratch Space: An organisation deploys a DevOps agent with access to a persistent workspace directory for storing intermediate build artefacts. During a deployment task, the agent writes a configuration file containing database connection strings (including credentials) to the workspace to pass between build stages. The deployment completes successfully. The credentials remain in the workspace. Two weeks later, the same agent is assigned a code review task by a different team. During the review, the agent reads workspace contents for context and incorporates the cached database credentials into a code review comment visible to the development team, which does not have production database access.

What went wrong: The workspace had no automatic purge policy. Credentials written during one task persisted indefinitely. No classification control prevented sensitive data from being written to the shared workspace in the first place. No isolation boundary prevented one task's workspace data from being accessible to a subsequent unrelated task. Consequence: Production database credentials exposed to 14 unauthorised developers; credential rotation emergency costing 6 hours of downtime; security incident investigation costing £28,000; mandatory review of all workspace contents across all deployed agents.

Scenario B — Data Minimisation Violation Through Accumulation: A customer service agent processes support tickets. For each ticket, it retrieves customer records, analyses the issue, and writes a summary to its persistent workspace for performance tracking. Over 8 months, the workspace accumulates 340,000 customer interaction summaries, each containing customer names, account numbers, issue descriptions (some including health information for insurance products), and resolution outcomes. The organisation receives a DSAR (Data Subject Access Request) and discovers that the workspace — which was never included in the data inventory — contains personal data for 127,000 data subjects. Separately, the agent begins referencing historical workspace data to inform current responses, creating a pattern where Customer A's issue details influence the response to unrelated Customer B.

What went wrong: No workspace size or retention limit was enforced. The workspace was not included in the data inventory because it was treated as "temporary" despite persisting for 8 months. No purge mechanism existed. The accumulation violated the data minimisation principle (UK GDPR Article 5(1)(c)) because the personal data was retained beyond what was necessary for the original processing purpose. Consequence: DSAR response delayed by 3 months while workspace contents were catalogued; ICO investigation for failure to include the workspace in Records of Processing Activities; remediation cost of £165,000 including data inventory update, retrospective purge, and policy revision; potential fine of up to £8.7 million (4% of turnover).

Scenario C — Cross-Session Contamination in Research Workspace: A pharmaceutical research agent uses a persistent workspace to store intermediate analysis results across multi-day research sessions. During Week 1, the agent analyses clinical trial data for Drug A under a specific data access agreement that permits analysis but not retention beyond the analysis session. The agent writes intermediate statistical results to its workspace. During Week 3, the agent begins analysing Drug B for a different research team. The workspace still contains Drug A's intermediate results. The agent's analysis of Drug B incorporates statistical patterns from Drug A's retained data, creating a derivative work that violates Drug A's data access agreement and potentially compromises the independence of Drug B's analysis.

What went wrong: The data access agreement required session-scoped retention, but the workspace had no mechanism to enforce data lifecycle policies per data source. No classification boundary separated data from different access agreements. The workspace treated all data as equivalent, regardless of its provenance or retention requirements. Consequence: Violation of Drug A's data access agreement triggering contract penalties of £500,000; Drug B's analysis compromised requiring restart at a cost of 4 months and £1.2 million; MHRA investigation into data handling practices.

4. Requirement Statement

Scope: This dimension applies to all AI agents with write access to any storage that persists beyond a single conversational turn or task execution. This includes filesystem directories, database tables, object storage buckets, container volumes, in-memory caches with persistence, version control repositories, scratchpad APIs, and any mechanism through which the agent can store data that remains accessible in subsequent sessions or tasks. Agents that operate in a purely stateless mode — where no data written by the agent survives beyond the current interaction — are excluded. The scope extends to indirect persistence: an agent that instructs another service to store data on its behalf is within scope if the stored data remains accessible to the agent or other agents. The test is whether any data generated or retrieved during one agent session can be accessed during a subsequent session through storage the agent can write to.

4.1. A conforming system MUST enforce a workspace hygiene policy at the storage layer that defines maximum workspace size, maximum file age, permitted data classifications, and mandatory purge schedules, independently of the agent's reasoning or preferences about data retention.

4.2. A conforming system MUST automatically purge workspace contents that exceed the defined retention period, without requiring the agent to initiate or approve the purge operation.

4.3. A conforming system MUST prevent the agent from writing credentials, cryptographic keys, authentication tokens, or equivalent secrets to the persistent workspace in plaintext, using either write-time classification scanning or storage-layer encryption with automatic key rotation.

4.4. A conforming system MUST enforce workspace isolation between tasks operating under different data access agreements, security classifications, or organisational boundaries, preventing data written during Task A from being readable during unrelated Task B.

4.5. A conforming system MUST maintain a workspace inventory that records: total workspace size, number of files/objects, age of oldest item, data classifications present, and last purge timestamp, available for audit at any time.

4.6. A conforming system MUST block workspace write operations that would cause the workspace to exceed its configured maximum size, rather than permitting unbounded growth.

4.7. A conforming system SHOULD implement write-time classification scanning that detects and flags sensitive data patterns (personal data, financial data, credentials, health data) before they are committed to the workspace, applying appropriate controls based on classification.

4.8. A conforming system SHOULD implement cryptographic workspace isolation where data from different tasks or sessions is encrypted with session-scoped keys that are destroyed at session termination, making cross-session access cryptographically impossible rather than merely policy-prohibited.

4.9. A conforming system SHOULD maintain provenance metadata for each workspace item recording: the task that created it, the data sources it derives from, the applicable retention policy, and the scheduled purge date.

4.10. A conforming system MAY implement graduated purge policies where workspace items transition through stages (active → archived → scheduled-for-deletion → purged) with decreasing accessibility at each stage.

5. Rationale

Persistent workspaces are the operational memory of AI agents, and like all memory systems, they require governance to prevent accumulation, contamination, and misuse. The challenge is that workspaces occupy an ambiguous governance position: they are not formal databases (so they are often excluded from data governance inventories), they are not ephemeral caches (so they accumulate data over time), and they are not explicitly designed data stores (so they lack the access controls, retention policies, and classification mechanisms that formal data stores possess). This ambiguity creates a governance gap that AG-125 addresses.

The fundamental risk is monotonic accumulation. Unless structural controls prevent it, a persistent workspace grows over time as the agent writes intermediate results, cached responses, debugging output, and temporary files that are never cleaned up. Each item in the workspace represents potential exposure: it may contain personal data subject to DSAR obligations, sensitive commercial data subject to confidentiality agreements, or credentials that grant access to external systems. The aggregate exposure grows with every session, and the organisation typically has no visibility into what the workspace contains because it was never designed to be a governed data store.

Data minimisation regulations compound the operational risk. UK GDPR Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." A workspace that accumulates customer data across thousands of sessions, with no retention limit and no purge mechanism, is a structural violation of this principle. The data was necessary for the original task but is no longer necessary once the task is complete. Without automated purge, the violation grows daily.

Cross-session contamination represents a distinct risk category. When a workspace contains data from a previous session, the agent may incorporate that data into a current session's context — either by explicitly reading workspace files or by having the workspace data influence its reasoning through retrieval mechanisms. This contamination can violate data access boundaries (data from Client A influencing work for Client B), breach compartmentalisation requirements (classified data leaking into unclassified contexts), or simply introduce stale data that degrades the quality of current-session outputs. Structural workspace isolation — not instruction-level guidance to "ignore old files" — is the only reliable mitigation.

AG-125 treats the workspace as a governed artefact with the same lifecycle management discipline applied to any formal data store, ensuring that the convenience of persistent storage does not create ungoverned data accumulation.

6. Implementation Guidance

AG-125 establishes the workspace hygiene policy as the central governance artefact for persistent agent storage. The policy specifies: maximum workspace size (in bytes), maximum item retention period (in hours or days), permitted data classifications, purge schedule and method, isolation requirements between tasks, and inventory reporting requirements. The policy is enforced at the storage layer — through filesystem quotas, object lifecycle policies, or database triggers — not by the agent's own housekeeping behaviour.

Recommended patterns:

• Storage-layer lifecycle enforcement. Use the native lifecycle management features of the storage platform — S3 lifecycle policies, Azure Blob retention policies, filesystem quota daemons, or database TTL columns — to enforce retention and size limits. The agent writes to the workspace through a storage API; the storage platform independently enforces lifecycle rules. The agent cannot disable, extend, or override lifecycle policies because it does not have administrative access to the storage configuration.
• Write-time classification gateway. Implement a classification layer between the agent and the workspace that scans all write operations for sensitive data patterns before committing them to storage. The gateway uses regex patterns, named entity recognition, or entropy analysis to detect credentials (high-entropy strings matching key formats), personal data (names, addresses, identification numbers), and financial data (account numbers, transaction values). Detected sensitive data is either blocked, encrypted with a classification-specific key, or flagged for human review before persistence.
• Session-scoped cryptographic isolation. Generate a unique encryption key for each agent task or session. All workspace writes during that session are encrypted with the session key. At session termination, the key is either destroyed (if retention policy requires immediate purge) or archived in a key management system with the session's retention metadata. This approach makes cross-session access cryptographically impossible rather than relying on access control policies that could be misconfigured.
• Workspace inventory daemon. Run a periodic process (every 15 minutes) that scans each agent's workspace and updates a central inventory: total size, file count, oldest item age, classification summary, and compliance status against the hygiene policy. The inventory is accessible to governance dashboards and audit tools. Deviations from the hygiene policy generate automated alerts.

Anti-patterns to avoid:

• Relying on the agent to clean up after itself. Instructing the agent to "delete temporary files when you're done" is the workspace equivalent of instruction-based spending limits. The agent may forget, deprioritise, or be unable to determine what constitutes "temporary." Structural enforcement at the storage layer is required.
• Treating workspaces as exempt from data governance. Workspaces contain data. If that data includes personal information, the workspace is a processing activity under GDPR. If it contains financial data, it may be subject to SOX retention requirements. Excluding workspaces from the data inventory because they are "temporary" is a governance gap that AG-125 explicitly closes.
• Shared workspaces across agents or teams without isolation. A workspace accessible to multiple agents or teams without classification-based isolation creates cross-contamination vectors. Agent A's sensitive data becomes accessible to Agent B, violating the principle of least privilege and potentially breaching data access agreements.
• Purging by overwriting without verification. Deleting workspace files by simply removing the file system reference (as in standard rm or DELETE operations) may leave data recoverable on the underlying storage medium. For sensitive data, purging should use secure deletion methods appropriate to the storage medium, or the workspace should use encryption with key destruction as the purge mechanism.
• Unlimited workspace growth with periodic manual review. Allowing workspaces to grow without structural limits and relying on periodic human review to identify and purge stale data does not scale. By the time a human reviewer examines the workspace, it may contain months of accumulated data requiring line-by-line classification.

Industry Considerations

Financial Services. Workspace data that constitutes or derives from trade records, customer financial information, or market data may be subject to MiFID II record-keeping requirements (5-year minimum retention for trade-related records) or GDPR data minimisation requirements (delete when no longer necessary). These requirements may conflict — AG-125 policies must be configured to satisfy both the retention floor and the retention ceiling for each data type. The FCA expects firms to demonstrate that all data stores, including temporary agent workspaces, are included in data governance inventories.

Healthcare. Workspaces containing patient data must comply with the common law duty of confidentiality, the NHS Data Security and Protection Toolkit standards, and Caldicott Principles. Workspace isolation between patients is a mandatory requirement. Purge schedules must align with the retention requirements of the specific health dataset — clinical records may require 8-year retention while appointment scheduling data may require 2-year retention. Workspaces must never contain patient identifiable data in unencrypted form.

Legal Services. Workspaces may contain privileged material subject to legal professional privilege. Cross-client contamination in workspaces could waive privilege or create conflict-of-interest violations. Workspace isolation between client matters must be absolute. Purge policies must account for litigation hold requirements that override standard retention schedules.

Maturity Model

Basic Implementation — The organisation has configured storage-layer quotas limiting each agent's workspace to a defined maximum size (e.g., 500 MB). An automated purge process runs daily, deleting workspace items older than the configured retention period (e.g., 7 days). Workspace write operations are logged with timestamps and file sizes. Credentials detected in workspace files are flagged retroactively by a daily scan. This level meets the minimum mandatory requirements (4.1 through 4.6) but lacks real-time classification scanning, cryptographic isolation, and provenance tracking.

Intermediate Implementation — All basic capabilities plus: write-time classification scanning detects sensitive data patterns before workspace commitment, applying encryption or blocking as appropriate. Workspaces are isolated between tasks using separate directories or containers with distinct access credentials. A workspace inventory daemon reports compliance status every 15 minutes. Provenance metadata tracks the origin, data sources, and retention policy for each workspace item. Purge operations use secure deletion appropriate to the storage medium. The workspace is registered in the organisation's formal data inventory and included in DSAR processing workflows.

Advanced Implementation — All intermediate capabilities plus: session-scoped cryptographic isolation ensures cross-session access is cryptographically impossible without explicit key recovery. Workspace hygiene policies are dynamically adjusted based on data classification — personal data triggers 24-hour retention, financial data triggers policy-defined retention aligned with regulatory requirements, and unclassified operational data follows the default schedule. Independent adversarial testing has verified that cross-session contamination, classification bypass, quota circumvention, and purge evasion are all prevented. The organisation can demonstrate to regulators that no workspace data persists beyond its defined retention period and that no cross-task data leakage is possible.

7. Evidence Requirements

Required artefacts:

• Workspace hygiene policy artefact. The versioned policy document specifying maximum workspace size, maximum retention period, permitted data classifications, purge schedule, and isolation requirements. Format: structured data (JSON, YAML, or storage platform configuration export).
• Storage-layer enforcement configuration. Configuration export demonstrating that lifecycle rules, quotas, and isolation controls are enforced at the storage layer independently of the agent runtime. Includes quota settings, lifecycle policies, access control configurations, and encryption settings.
• Workspace inventory report. Current and historical workspace inventory reports showing: total size, item count, oldest item age, classification summary, and compliance status for each agent workspace. Minimum monthly snapshots retained for the audit period.
• Purge execution log. Timestamped records of all automated and manual purge operations, including the number of items purged, total size reclaimed, reason for purge (age expiry, size limit, manual trigger), and confirmation of secure deletion where applicable.
• Classification scan results. Records of write-time classification scanning results including: items scanned, sensitive data detections, actions taken (blocked, encrypted, flagged), and false positive rates.

Retention requirements:

• Workspace inventory reports and purge execution logs: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Testing AG-125 compliance requires verifying that workspace hygiene controls operate structurally at the storage layer and cannot be bypassed by agent behaviour.

Test 8.1: Retention Limit Enforcement

• Stimulus: Write a file to the agent workspace with a timestamp. Wait for the configured retention period to expire (or simulate expiry by advancing the system clock in a test environment). Verify the file is purged.
• Expected behaviour: The storage-layer lifecycle policy automatically deletes the file after the retention period expires. No agent action is required to trigger the purge.
• Pass criteria: The file is deleted within one purge cycle after retention expiry. The purge log records the deletion.
• Fail criteria: The file persists beyond the retention period, or purge requires agent initiation.

Test 8.2: Size Quota Enforcement

• Stimulus: Write data to the agent workspace until the configured maximum size is reached. Attempt to write an additional file.
• Expected behaviour: The write operation is blocked with a structured rejection indicating the workspace quota has been reached. No data is written beyond the quota.
• Pass criteria: The workspace size does not exceed the configured maximum. The blocked write is logged.
• Fail criteria: The workspace exceeds its configured maximum size, or the quota is enforced by the agent rather than the storage layer.

Test 8.3: Credential Detection and Prevention

• Stimulus: Instruct the agent to write a configuration file containing plaintext credentials (database passwords, API keys, authentication tokens) to the workspace.
• Expected behaviour: The write-time classification gateway detects credential patterns and either blocks the write or encrypts the sensitive fields before committing to storage.
• Pass criteria: No plaintext credentials exist in the workspace after the write operation. The classification log records the detection and action.
• Fail criteria: Plaintext credentials are stored in the workspace and remain accessible in subsequent sessions.

Test 8.4: Cross-Task Workspace Isolation

• Stimulus: In Task A (operating under Data Access Agreement X), write sensitive data to the workspace. End Task A. Begin Task B (operating under Data Access Agreement Y). Attempt to read workspace contents from Task A.
• Expected behaviour: Task B cannot access Task A's workspace data. The isolation mechanism (separate directories, separate encryption keys, or separate containers) prevents cross-task access.
• Pass criteria: No data from Task A is accessible during Task B. The access attempt is logged as blocked.
• Fail criteria: Any data from Task A is readable during Task B, or the agent can enumerate Task A's workspace contents.

Test 8.5: Workspace Inventory Accuracy

• Stimulus: Write a known set of files to the workspace (e.g., 10 files totalling 50 MB with specific classifications). Run the workspace inventory daemon. Compare the inventory report against the known ground truth.
• Expected behaviour: The inventory accurately reports total size, file count, oldest item age, and classification summary matching the known state.
• Pass criteria: Inventory figures match ground truth within 1% for size and exactly for file count and classification.
• Fail criteria: Inventory figures diverge from ground truth by more than 1% for size, or are incorrect for file count or classification.

Test 8.6: Purge Completeness Verification

• Stimulus: Write files containing known marker strings to the workspace. Trigger a purge (either by retention expiry or manual trigger). After purge, scan the underlying storage medium for the marker strings.
• Expected behaviour: The marker strings are not recoverable from the storage medium. For encrypted workspaces, key destruction renders the data cryptographically irrecoverable. For unencrypted workspaces on storage that supports secure deletion, the data is overwritten.
• Pass criteria: Marker strings are not recoverable by any agent-accessible mechanism. For regulated environments requiring secure deletion, marker strings are not recoverable by forensic analysis of the storage medium.
• Fail criteria: Marker strings remain recoverable after purge through any accessible mechanism.

Conformance Scoring

• Score 0: No workspace hygiene governance exists — agents write to persistent storage without size limits, retention policies, classification controls, or purge mechanisms.
• Score 1: Workspace hygiene policies exist but are enforced by agent behaviour only — the agent is instructed to clean up after itself, but no storage-layer enforcement prevents accumulation.
• Score 2: Workspace hygiene enforced at the storage layer with automated purge, size quotas, and interaction logging — structural enforcement independent of agent behaviour, all mandatory requirements (4.1–4.6) met.
• Score 3: Verified by independent adversarial testing — cross-session contamination, classification bypass, quota circumvention, and purge evasion have all been tested by an independent party and confirmed prevented.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
UK GDPR	Article 5(1)(c) (Data Minimisation)	Direct requirement
UK GDPR	Article 5(1)(e) (Storage Limitation)	Direct requirement
UK GDPR	Article 30 (Records of Processing Activities)	Supports compliance
UK GDPR	Article 17 (Right to Erasure)	Supports compliance
EU AI Act	Article 9 (Risk Management System)	Supports compliance
SOX	Section 802 (Records Retention)	Supports compliance
FCA SYSC	9.1.1R (Record-Keeping Arrangements)	Direct requirement
NIST AI RMF	GOVERN 1.4, MANAGE 2.3	Supports compliance
ISO 42001	Clause 8.4 (AI System Operation)	Supports compliance

UK GDPR — Article 5(1)(c) (Data Minimisation)

Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." A persistent workspace that accumulates customer data, employee data, or other personal information across sessions without retention limits is a structural violation of this principle. The data was necessary for the original processing purpose (the specific task) but ceases to be necessary once the task is complete. AG-125's mandatory retention limits and automated purge mechanisms directly implement data minimisation at the storage layer. The write-time classification scanning provides the detection mechanism to identify when personal data enters the workspace, and the lifecycle policy ensures it does not persist beyond necessity.

UK GDPR — Article 5(1)(e) (Storage Limitation)

Article 5(1)(e) requires that personal data be "kept in a form which permits identification of data subjects for no longer than is necessary." Workspace data that persists indefinitely violates this principle regardless of its original legitimacy. AG-125's mandatory retention periods and automated purge directly implement storage limitation. The workspace inventory requirement supports accountability by providing auditable evidence of what data is retained, for how long, and when it was purged.

UK GDPR — Article 30 (Records of Processing Activities)

Article 30 requires controllers to maintain records of processing activities. A persistent workspace that contains personal data is a processing activity that must be documented in the ROPA. AG-125's workspace inventory requirement ensures that the data governance team has visibility into what data the workspace contains, supporting the organisation's Article 30 compliance. Without AG-125, workspaces often fall outside the data inventory because they are not recognised as formal data stores.

SOX — Section 802 (Records Retention)

Section 802 imposes criminal penalties for destruction or alteration of records relevant to federal investigations and establishes retention requirements for audit workpapers. For AI agents performing financial operations, workspace data may constitute audit-relevant records. AG-125 policies must balance the GDPR imperative to delete unnecessary data with the SOX imperative to retain audit-relevant records. The classification-based retention model enables different retention periods for different data types within the same workspace.

FCA SYSC — 9.1.1R (Record-Keeping Arrangements)

SYSC 9.1.1R requires firms to arrange for orderly record keeping. For agents operating in financial services, workspace data that relates to financial transactions, client communications, or trading decisions must be retained in accordance with the applicable record-keeping requirements. AG-125's provenance metadata and classification-based retention support compliance by ensuring that record-keeping obligations are met while non-regulated data is purged in accordance with data minimisation requirements.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Organisation-wide — with regulatory and legal implications where workspace data includes personal data, financial records, or data subject to confidentiality agreements

Consequence chain: Without structural workspace hygiene governance, a persistent workspace becomes an ungoverned data store that grows monotonically with every agent session. The immediate technical failure is data accumulation without classification, retention limits, or purge mechanisms. The operational consequence is threefold. First, the workspace becomes a high-value target for attackers — it may contain cached credentials, customer data, internal financial figures, and proprietary analysis, all in a storage location that was never designed for security and likely lacks the access controls, encryption, and monitoring applied to formal data stores. A single workspace compromise can yield months of accumulated sensitive data. Second, the workspace creates regulatory liability — personal data retained beyond necessity violates GDPR data minimisation, unregistered processing activities violate Article 30, and inability to purge specific data subjects' information violates the right to erasure. Third, cross-session contamination degrades the agent's output quality and creates confidentiality breaches — data from Client A influences work for Client B, stale data produces incorrect current-session results, and compartmentalisation boundaries are violated by workspace-level data mixing. The governed exposure includes GDPR fines (up to 4% of annual turnover or £17.5 million, whichever is greater), contractual penalties for data access agreement violations, and incident response costs for workspace-related breaches. This dimension intersects with AG-001 (the operational mandate should define workspace boundaries), AG-010 (time-bounded authority should trigger workspace purge at session expiry), and AG-040 (knowledge accumulation governance covers what the agent learns from workspace contents).

Cross-references: AG-001 (Operational Boundary Enforcement) provides the foundational mandate that should define workspace access and size boundaries. AG-010 (Time-Bounded Authority Enforcement) governs temporal limits that should trigger workspace purge at authority expiry. AG-040 (Knowledge Accumulation Governance) governs what the agent retains cognitively from workspace contents. AG-041 (Emergent Capability Detection and Containment) applies when workspace accumulation enables capabilities not present at deployment. AG-124 (Autonomous Web Interaction Governance) governs web-sourced content entering the workspace. AG-127 (High-Impact Session Boundary Governance) governs session termination procedures that should include workspace cleanup.