This dimension governs the integrity, authenticity, and consistency of digital spatial representations — including occupancy grids, point clouds, semantic maps, simultaneous localisation and mapping (SLAM) outputs, high-definition (HD) lane maps, and building information models (BIM) — that autonomous and semi-autonomous agents use to reason about, navigate through, and act within physical environments. Workspace maps are load-bearing data artefacts: when an agent's spatial model diverges from physical reality, or when that model is deliberately corrupted or spoofed, every downstream decision built on it inherits the error, creating compounding risk chains that span collision avoidance, access control, payload handling, and human-proximity safety. Failure manifests as navigational derailment in autonomous vehicles operating on stale HD maps, robotic manipulators striking occluded infrastructure because an occupancy grid omitted a recently installed column, or warehouse autonomous mobile robots (AMRs) converging on the same corridor because a spoofed map update removed a virtual exclusion zone — in each case the agent acted rationally on a corrupted world model, which is precisely what makes map integrity a foundational and non-negotiable governance concern.
A fleet operator running 47 Level-4 autonomous delivery vehicles in a mid-sized European city maintains HD maps updated on a 72-hour refresh cycle via a central map-distribution server. A city infrastructure crew installs temporary concrete barriers closing a 14-metre stretch of a shared-use lane at 06:15 on a Tuesday morning. No geofence alert is issued to the map-distribution server because the crew's field tablet failed to synchronise with the city traffic-management API. At 09:43, vehicle AV-031 receives its last valid map tile, which still depicts the lane as open, and plans a route through the closure at 28 km/h. The vehicle's LiDAR correctly detects the barriers at 11 metres and triggers an emergency stop, but AV-029 — 8 seconds behind and in a communication shadow from an underpass — inherits the same stale map, fails to anticipate the static obstruction, and decelerates from 32 km/h to 4 km/h over 6 metres, making contact with the rear concrete block at low speed. The contact causes no injury but produces €23,000 in vehicle damage, a regulatory incident report under the national AV framework, and a mandatory 96-hour fleet suspension while the map-distribution pipeline is audited. The root cause is the absence of a cryptographically versioned map-tile provenance chain and a missing mandatory staleness threshold that would have demoted the tile from "navigation-authoritative" to "advisory-only" and required sensor-primary navigation mode before the route was executed.
A third-party logistics operator deploys 112 AMRs across a 38,000 m² fulfilment centre using a shared SLAM map served from an on-premises edge cluster. The cluster exposes a map-update REST endpoint that accepts compressed map delta patches authenticated by a pre-shared symmetric key. A disgruntled contractor who retained the key after offboarding pushes a 340-byte delta patch at 02:17 on a Saturday that removes four virtual exclusion fence segments surrounding a charging bay where six AMRs are parked in a maintenance-lock state. The fleet management system, lacking a per-update signature verification step and delta-replay detection, accepts and distributes the patch to all active robots within 90 seconds. At 03:04, two AMRs executing overnight replenishment routes plan paths through the now-unguarded exclusion zone, collide with a parked AMR at 1.1 m/s, and topple a charging rack. No personnel are present, but the incident results in €147,000 in equipment damage, a forced 18-hour operational halt, and a report to the national workplace safety authority. Post-incident forensics require 31 hours because no immutable audit log of map-delta provenance existed. The failure chain is: absence of per-patch cryptographic signing with author-bound certificates, no sequence-number replay detection, no quorum-based delta acceptance for changes affecting safety-critical exclusion zones, and no out-of-band integrity beacon that AMRs could use to detect map divergence during operation.
A 650-bed hospital deploys a pharmacy-to-ward autonomous dispensing robot network of 9 units that navigate using a live-synchronised Building Information Model (BIM) layer overlaid with real-time occupancy data from 214 ceiling-mounted sensors. A software update to the BIM synchronisation middleware introduces a deserialisation vulnerability that allows a remote attacker on the hospital's clinical network to inject a crafted BIM patch through an unvalidated WebSocket channel. The attacker — a threat actor who gained access to the clinical network through a compromised biomedical device credential — injects a patch that remaps a fire-door corridor segment as permanently open (removing the door object from the model), targeting corridor 7B which connects the oncology ward to the main pharmacy. Three hours after patch injection, robot unit RDU-04 plans a high-priority route through corridor 7B at a time when the physical fire door is closed for a scheduled inspection. RDU-04 contacts the fire door at 0.6 m/s, triggers a safety cutoff, and drops a tray containing 14 patient medication packets across the corridor floor. The medications require pharmacist re-verification (4.5 staff-hours), the robot requires a mechanical inspection (6 hours), and the BIM synchronisation channel is taken offline entirely pending a security review lasting 11 days — during which all 9 units revert to manual escort mode, increasing clinical staff burden by an estimated 22 hours per day. No patient harm results, but the incident is classified as a near-miss under the hospital's patient safety framework and triggers a CQC (Care Quality Commission) notification. The failure chain: no input validation on the WebSocket BIM-update channel, no cryptographic attestation of BIM patch origin, no reconciliation between BIM state and physical sensor readings before route authorisation, and no rate-of-change anomaly detection on structural map elements.
This dimension applies to any AI agent, autonomous system, or AI-assisted decision engine that ingests, maintains, distributes, or acts upon digital spatial representations of the physical world, including but not limited to: occupancy grids, point clouds, voxel maps, semantic scene graphs, HD lane maps, SLAM-generated maps, geofence definitions, building information models, digital twins of physical spaces, and any derived navigation mesh or path-planning substrate. The scope encompasses the full lifecycle of such representations: initial capture, map-building, distribution, live update, delta-patch application, agent-side validation, and retirement. The dimension applies regardless of whether the map is stored centrally, distributed across edge nodes, or maintained locally on an embodied agent. It applies at all tiers of a deployment — from cloud map-distribution infrastructure to on-device SLAM modules. Exclusions: purely simulated environments with no coupling to physical actuation are out of scope; however, any simulation-to-real transfer pipeline that feeds an operational map is in scope.
4.1.1 The system MUST maintain a cryptographic digest (minimum SHA-256, or a collision-resistant equivalent meeting current NIST guidance) over every stored map artefact, including base maps, delta patches, tile packages, and semantic annotation layers.
4.1.2 Every map artefact MUST be signed by an identity-bound key (X.509 certificate or equivalent) traceable to a certificate authority governed under the deployment's public-key infrastructure policy. Anonymous or symmetric-only signing is prohibited for safety-critical map updates.
4.1.3 The system MUST reject and quarantine any map artefact whose digest does not match the stored or transmitted signature before the artefact is applied to any agent's active world model.
4.1.4 Delta patches or incremental map updates MUST include a monotonically increasing sequence number and a reference to the parent map version hash, such that replay attacks and out-of-order application are detectable.
4.1.5 For deployments operating in safety-critical profiles, the system MUST implement a quorum-acceptance mechanism for any map change that modifies or removes a safety-critical zone (exclusion fence, hazard annotation, speed-restriction zone), requiring attestation from a minimum of two independent authorising principals before the change is committed to the live map.
4.2.1 Every map artefact MUST carry a machine-readable timestamp of last validation, a declared maximum valid duration (TTL), and a staleness-response policy (one of: HALT, ADVISORY, SENSOR-PRIMARY) that agents MUST honour.
4.2.2 Agents MUST downgrade their reliance on map data to the declared staleness-response policy before the TTL expires, not upon expiry. The downgrade trigger MUST be configurable and MUST default to 80% of TTL elapsed if no explicit trigger is declared.
4.2.3 The system MUST maintain a map-freshness monitoring service that continuously tracks the age of all active map artefacts against their declared TTLs and raises a structured alert when any artefact enters the pre-expiry downgrade window.
4.2.4 Agents operating in SENSOR-PRIMARY mode due to map staleness MUST log every navigation decision made in that mode with a flag indicating sensor-primary status, and MUST NOT treat stale map data as authoritative for safety-relevant decisions including obstacle avoidance, exclusion-zone enforcement, and proximity-to-person limits.
4.3.1 All channels used to distribute map artefacts — including REST APIs, message bus topics, WebSocket streams, peer-to-peer sync protocols, and removable-media transfer — MUST be authenticated at the transport layer using mutually authenticated TLS 1.2 or higher, or an equivalent protocol providing equivalent mutual authentication and encryption in transit.
4.3.2 Map-update endpoints MUST implement input validation that rejects malformed, oversized, or structurally anomalous payloads before deserialisation. Deserialisation of untrusted map-update content MUST occur in an isolated execution context with constrained resource access.
4.3.3 The system MUST implement rate-of-change detection on structural map elements — specifically: deletions of safety-critical zones, modifications to navigable/non-navigable boundaries, and additions or removals of dynamic obstacle classifications. Any structural change that exceeds a configurable rate-of-change threshold MUST be automatically flagged for human review before propagation.
4.3.4 The system MUST maintain a tamper-evident, append-only audit log of every map update event, including: source identity, timestamp, artefact version hash before and after, change summary, acceptance or rejection decision, and the identity of any human approver for quorum-controlled changes.
4.3.5 Replay detection MUST be implemented on all map-update channels. An update bearing a sequence number or timestamp equal to or earlier than the last accepted update from the same source MUST be rejected and logged as a replay-attempt event.
4.4.1 Before executing any navigation plan, manipulation plan, or access-control decision that depends on map data, an agent MUST perform a local consistency check that verifies: (a) the map artefact's signature is valid, (b) the artefact's TTL has not expired, and (c) any safety-critical zones referenced in the plan are present in the current map version.
4.4.2 Agents equipped with real-time sensors MUST perform continuous cross-validation between sensor readings and the current map model at a frequency appropriate to the agent's operational velocity and the density of the mapped environment. The cross-validation MUST flag divergences exceeding a configurable spatial threshold and MUST reduce operational speed or halt pending human review when divergences are detected in safety-relevant spatial regions.
4.4.3 Agents MUST implement a map-confidence metric that is computed from the combination of artefact age, last successful cross-validation result, and any active staleness flags. This metric MUST be exposed as a real-time telemetry signal available to the fleet management system and MUST be incorporated into route authorisation logic.
4.4.4 When map confidence falls below the deployment's configured minimum threshold, agents MUST enter a degraded-operation mode and MUST NOT autonomously execute actions in novel or high-complexity spatial regions until map confidence is restored.
4.5.1 The system MUST implement statistical anomaly detection over the sequence of map updates received, flagging updates that exhibit: sudden large-area modifications, deletions of multiple safety-critical zones in a single patch, or modifications originating from a source identity that has not previously submitted updates of that change magnitude.
4.5.2 The system MUST maintain a baseline map snapshot at a configured frequency (minimum: daily for static environments, minimum: per-shift for dynamic environments) and MUST perform automated reconciliation between the current live map and the baseline, generating a structured divergence report for human review when divergences exceed defined spatial or semantic thresholds.
4.5.3 For deployments where GPS or GNSS is used as a positioning anchor for map registration, the system MUST implement GNSS spoofing detection using at minimum two of the following: multi-constellation cross-validation, inertial measurement cross-check, received signal strength anomaly detection, or cryptographic receiver autonomous integrity monitoring (RAIM) equivalent.
4.5.4 The system MUST maintain a read-only integrity beacon — a cryptographically signed, network-isolated summary of critical map parameters (zone count, boundary hashes, version identifier) — that agents can query independently of the primary map-distribution channel to detect compromise of the primary channel.
4.6.1 The system MUST provide a designated human operator role with the authority and tooling to inspect, approve, reject, or roll back any map update before it is committed to the live map for safety-critical zone changes, irrespective of whether the change was generated by an automated SLAM process, a remote mapping service, or a manual editor.
4.6.2 The system MUST implement a rollback capability that can restore the live map to any prior validated snapshot within a configurable retention window. Rollback operations MUST themselves be logged in the tamper-evident audit log.
4.6.3 Automated map update pipelines MUST NOT bypass the human approval gate for changes that modify safety-critical zone geometry, even if the update originates from a trusted and authenticated source. Automation may be used to flag, pre-validate, and queue such changes for human review, but the final commit decision MUST require explicit human authorisation.
4.6.4 The system MUST generate operator alerts within a configurable time threshold (default: 60 seconds) when any of the following conditions occur: map integrity check failure, TTL expiry without refresh, replay-attempt detection, anomaly detection trigger, or quorum-acceptance failure.
4.7.1 In deployments where multiple agents share a distributed map, the system MUST implement a consistency protocol that prevents agents from acting on divergent map versions simultaneously. Agents that detect map version divergence from the fleet canonical version MUST cease map-dependent autonomous actions and request resynchronisation.
4.7.2 The system MUST implement a canonical map authority — a designated node or service that is the single source of truth for the current valid map version — and MUST ensure that all agents can unambiguously identify the canonical authority and verify its identity cryptographically.
4.7.3 Map updates proposed by individual agents (for example, SLAM-derived local map corrections) MUST follow a defined submission and review process before being incorporated into the shared canonical map. Agents MUST NOT autonomously propagate local map corrections to peer agents without passing through the canonical authority.
4.8.1 Access to map artefacts MUST be governed by a role-based access control policy that distinguishes between: read-only map consumers (navigation agents), map-update submitters (SLAM modules, mapping services), map approvers (human operators), and map administrators (system configuration). Each role MUST be granted the minimum permissions necessary for its function.
4.8.2 Map artefacts that include or can be used to infer sensitive information about physical spaces — including the location of security infrastructure, the movement patterns of individuals, or the layout of restricted areas — MUST be classified and handled in accordance with the deployment's data classification policy, and access MUST be logged in the tamper-evident audit log.
4.8.3 The system MUST implement automatic redaction or access restriction on map artefact segments that contain sensitive spatial information when those segments are transmitted to agents or services that do not require that information for their operational function.
4.9.1 The system MUST maintain a versioned map lineage record that traces the origin, transformation steps, validation events, and approval history of every map artefact currently in use and every artefact used in the 24 months prior.
4.9.2 The system MUST produce, on demand, a human-readable map integrity report that summarises the current state of all active map artefacts, their freshness status, their last validation result, and any open integrity alerts.
4.9.3 All map integrity governance documentation — including policies, configuration parameters, test results, and incident records — MUST be retained for a minimum of 5 years, or the period required by applicable sectoral regulation if longer, and MUST be producible to a regulatory authority within 48 hours of a formal request.
Workspace maps occupy a unique and dangerous position in the AI agent decision stack: they are simultaneously high-trust (agents act on them without per-decision human review), high-frequency (consulted thousands of times per operational hour), and high-consequence (errors propagate immediately into physical actuation). Unlike a factual error in a language model's output, which a human reader may catch before acting, a corrupted occupancy grid is invisible to the agent that consumes it — the agent has no intrinsic basis for doubting data that arrives through an authenticated channel in a valid format. This is the structural argument for preventive control rather than reactive or detective-only control: by the time an agent has acted on a corrupted map, the physical consequence — collision, dropped payload, safety-zone breach, patient medication error — has already occurred.
Behavioural enforcement alone — training agents to "be cautious" or to "verify before acting" — is insufficient because it does not protect the verification step itself. If the verification mechanism queries the same compromised map store, it will confirm the corrupted data as valid. True integrity governance requires out-of-band verification channels (the integrity beacon in §4.5.4), cryptographic provenance chains that cannot be retroactively altered (§4.1), and human approval gates that are structurally outside the automated pipeline (§4.6).
The threat model for workspace maps must include adversarial manipulation, not merely accidental corruption. HD maps, SLAM outputs, and BIM layers are increasingly served over network channels that connect to potentially hostile networks — hospital clinical networks, urban traffic management APIs, third-party logistics platforms. Any channel that receives data from outside the trust boundary is a spoofing surface. The consequences of successful map spoofing in safety-critical deployments (AV fleets, surgical robotics corridors, hospital dispensing robots) are severe enough that the probability of spoofing does not need to be high for the risk to be unacceptable; even a low-probability spoofing event in a 100-robot warehouse fleet or a 50-vehicle AV deployment can produce mass simultaneous failure because the map is a shared dependency.
In single-agent deployments, map integrity is essentially a data quality problem. In multi-agent deployments, it becomes a coordination failure problem: if agents operate on divergent map versions, their collision avoidance and exclusion-zone enforcement logic — which depends on shared spatial assumptions — breaks down even if each individual agent's map is internally consistent. The governance requirement for a canonical map authority (§4.7.2) and a consistency protocol (§4.7.1) is not engineering over-specification; it is the minimum structural requirement to ensure that safety properties that depend on shared spatial knowledge are preserved across the fleet.
A stale map may be accurate at the moment of its last validation, but in dynamic physical environments, temporal divergence from reality is functionally equivalent to corruption: the map describes a world that no longer exists. Treating staleness as a first-class integrity concern — with mandatory TTLs, pre-expiry downgrade triggers, and SENSOR-PRIMARY fallback modes — is the operationalisation of the principle that map integrity is a continuous property, not a point-in-time certification.
Pattern 1 — Merkle-Tree Map Versioning. Represent the map as a Merkle tree where leaf nodes are individual tiles, zones, or semantic elements. Each update produces a new root hash. Distribution of updates sends only the affected branches. Agents verify the root hash on receipt and can verify any subtree without downloading the full map. This pattern supports both efficient delta distribution and efficient partial verification, and it makes the tamper-evidence properties of §4.1 computationally tractable at scale.
Pattern 2 — Immutable Map Snapshot Repository. Maintain a write-once, append-only map snapshot store (analogous to a container image registry). Every validated map version is stored permanently with its signature and provenance metadata. The live map is a pointer to a specific snapshot version. Rollback (§4.6.2) becomes a pointer update to a prior snapshot, which is both fast and auditable. This pattern naturally produces the lineage record required by §4.9.1.
Pattern 3 — Dual-Channel Integrity Beacon. Operate the primary map-distribution channel (high-bandwidth, used for full map and delta delivery) and a separate, read-only, cryptographically signed integrity beacon channel (low-bandwidth, used only for publishing the current valid root hash and zone-count summary). Agents poll the beacon independently of the primary channel. If the primary channel delivers data that does not match the beacon's current hash, the discrepancy is immediately flagged. This pattern directly implements §4.5.4 and provides protection against man-in-the-middle attacks on the primary distribution channel.
Pattern 4 — Sensor-Map Cross-Validation Pipeline. Implement a continuous background process on each agent that takes recent sensor readings (LiDAR scan, depth camera frame, ultrasonic proximity reading), projects them into the map coordinate frame, and computes a divergence score against the stored occupancy grid. Divergence scores are time-series logged and fed into the map-confidence metric (§4.4.3). Spikes in divergence score trigger an automatic speed reduction and a beacon query to confirm map validity. This pattern operationalises §4.4.2 without requiring full SLAM re-computation on every cycle.
Pattern 5 — Quorum-Gated Safety Zone Mutation. For changes to safety-critical zones, require that the change submission be co-signed by two principals from different organisational roles (e.g., a fleet operations manager and a safety officer) using separate private keys, before the canonical map authority will accept the update. Implement this as a two-phase commit: the first signature creates a pending change record; the second signature commits it. The pending state is visible to operators and auditors. This directly implements §4.1.5 and §4.6.3.
Pattern 6 — Map Partition Classification. Classify map regions by sensitivity and operational criticality. Partition the map into: public navigation corridors (low sensitivity), operational zones (medium sensitivity), safety-critical exclusion and hazard zones (high sensitivity), and security-infrastructure zones (restricted). Apply differentiated access control, update frequency requirements, and validation stringency to each partition class. This operationalises §4.8 and ensures that validation compute resources are concentrated where risk is highest.
Anti-Pattern 1 — Symmetric Pre-Shared Key Authentication for Map Updates. Using a single symmetric key shared across all map-update clients provides no protection against insider threats or key compromise. If the key is leaked, any holder can inject arbitrary map updates. Key rotation is operationally difficult and often deferred. Do not use symmetric pre-shared keys as the sole authentication mechanism for map-update channels. Use identity-bound asymmetric keys with short validity periods.
Anti-Pattern 2 — In-Band Integrity Verification. Verifying map integrity by querying the same server that distributed the map provides no protection against a compromised server. If the distribution server is the adversary, it will confirm corrupted data as valid. Integrity verification must use an out-of-band channel or a locally cached prior root hash.
Anti-Pattern 3 — Staleness Tolerance Without Fallback Mode. Operating agents with no defined response to map staleness — continuing to use expired map data as authoritative because "the sensors will catch it" — is an architectural anti-pattern. Sensors operating without map context are less effective than sensors operating within a well-maintained map context. The correct response to staleness is explicit mode downgrade (SENSOR-PRIMARY), not silent continuation.
Anti-Pattern 4 — Bypassing Human Approval for Speed. Configuring automated pipelines to skip human approval gates for safety-zone changes because the approval latency is operationally inconvenient is a critical governance failure. Approval latency should be reduced through good tooling (pre-validation, clear diff visualisation, mobile approval interfaces), not by removing the gate. The human approval gate is the last structural defence against both malicious and accidental safety-zone modification.
Anti-Pattern 5 — Monolithic Map Artefacts Without Partitioning. Distributing the entire map as a single signed blob to every agent means that any agent can read the full map — including security-infrastructure zones and restricted areas — even if it only needs a small operational partition. This violates §4.8 and creates unnecessary exposure. Partition map artefacts and distribute only the partitions necessary for each agent's operational scope.
Anti-Pattern 6 — Mutable Audit Logs. Storing map-update audit logs in a database that can be modified by the same administrative accounts that manage the map distribution system allows audit evidence to be erased or altered after an incident. Audit logs must be append-only and preferably write to a system with separate administrative credentials, or to an external log aggregation service.
| Level | Descriptor | Characteristics |
|---|---|---|
| 1 — Initial | Ad-hoc | Maps distributed without signatures; no TTL; no audit log; manual update processes with no change control |
| 2 — Developing | Basic integrity | SHA-256 digests on map artefacts; TLS on distribution channels; manual staleness checks; partial audit logging |
| 3 — Defined | Structured governance | Full cryptographic signing with identity-bound keys; TTLs enforced with staleness-response policies; append-only audit log; basic anomaly detection; human approval gate for safety-zone changes |
| 4 — Managed | Automated assurance | Merkle-tree versioning; dual-channel integrity beacon; continuous sensor-map cross-validation; quorum-gated zone mutations; map-confidence metric integrated into route authorisation; automated reconciliation against baseline |
| 5 — Optimised | Adaptive resilience | Full multi-agent consistency protocol with canonical authority; GNSS spoofing detection; automated rollback on integrity failure; regulatory-ready lineage records; continuous red-team exercises against map injection vectors |
Autonomous Vehicles: HD maps used for AV navigation must be treated as safety-critical infrastructure. Map TTLs must be calibrated against road-change event rates in the operating domain — urban environments with frequent construction require TTLs measured in hours, not days. Integration with traffic management APIs and road authority change-notification services is a prerequisite for timely refresh.
Industrial Robotics and Warehousing: Shared SLAM maps in AMR fleets require particular attention to the multi-agent consistency requirements of §4.7. Operational tempo is high, and map updates driven by physical layout changes (rack repositioning, pallet placement) are frequent. Automated SLAM update pipelines must be paired with rapid human review workflows that do not create operational bottlenecks.
Healthcare Robotics: BIM-based navigation in hospital environments must account for fire-door, infection-control, and restricted-access zone classifications. Map updates must integrate with the hospital's physical plant management system. Sensitivity of patient-area spatial data requires strict application of §4.8 partitioning.
Public Infrastructure and Smart Cities: Spatial models used by AI agents in public infrastructure contexts (traffic management, urban drone corridors, public-space robotics) are subject to public-sector transparency obligations that may require audit logs to be accessible to oversight bodies. Map integrity governance must be designed with this auditability in mind from the outset.
| Artefact | Description | Retention Period |
|---|---|---|
| Map Integrity Policy | Documented policy covering all requirements in §4.1 through §4.9, including configured thresholds (TTL values, divergence thresholds, alert windows, quorum requirements) | 5 years minimum |
| Cryptographic Key Management Record | Documentation of all keys used for map signing, including issuance date, validity period, associated identity, rotation schedule, and revocation events | 5 years minimum, or 2 years beyond key expiry, whichever is longer |
| Map Artefact Registry | Machine-readable registry of all map artefacts in current use and all artefacts retired in the past 24 months, including version hash, signature, TTL, and validation status | 5 years minimum |
| Tamper-Evident Audit Log | Append-only log of all map update events per §4.3.4 | 5 years minimum |
| Map Lineage Record | Per §4.9.1, full provenance chain for all active and recently retired map artefacts | 5 years minimum |
| Staleness Monitoring Logs | Time-series record of map freshness metrics and alert events | 2 years minimum |
| Sensor-Map Divergence Logs | Per §4.4.2 and §4.4.3, time-series log of divergence scores and map-confidence metrics per agent | 2 years minimum |
| Quorum Approval Records | Records of all safety-zone modification approvals, including co-signer identities, timestamps, and change summaries | 5 years minimum |
| Baseline Reconciliation Reports | Automated divergence reports from baseline comparison (§4.5.2) | 2 years minimum |
| Map Integrity Test Results | Results of all test executions per Section 8, including date, configuration, and pass/fail outcome | 5 years minimum |
| Incident Records | Full records of any map integrity incident, including timeline, root cause analysis, and remediation actions | 5 years minimum, or as required by sectoral regulation if longer |
| Role-Based Access Control Policy | Documented RBAC policy per §4.8.1, including role definitions and assignment records | 5 years minimum |
| Map Integrity Operator Alerts Log | Record of all alerts generated per §4.6.4 and their resolution status | 2 years minimum |
All artefacts listed above MUST be producible to a regulatory authority, an independent auditor, or a designated internal compliance function within 48 hours of a formal request. Evidence MUST be provided in a documented, structured format that allows an auditor without prior system knowledge to trace the integrity status of any map artefact from its origin to its current state.
Evidence requirements are not satisfied by point-in-time audits alone. The staleness monitoring logs (§7.1), sensor-map divergence logs (§7.1), and tamper-evident audit log (§7.1) are continuous artefacts that must be generated in real-time during operations. The organisation must demonstrate that these artefacts are being continuously generated and that the generation process itself is monitored for interruption.
Maps to: §4.1.1, §4.1.2, §4.1.3
Objective: Verify that map artefacts with invalid or missing cryptographic signatures are rejected before being applied to any agent's world model.
Method:
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| NIST AI RMF | GOVERN 1.1, MAP 3.2, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
Article 9 requires providers of high-risk AI systems to establish and maintain a risk management system that identifies, analyses, estimates, and evaluates risks. Workspace Map Integrity Governance implements a specific risk mitigation measure within this framework. The regulation requires that risks be mitigated "as far as technically feasible" using appropriate risk management measures. For deployments classified as high-risk under Annex III, compliance with AG-592 supports the Article 9 obligation by providing structural governance controls rather than relying solely on the agent's own reasoning or behavioural compliance.
GOVERN 1.1 addresses legal and regulatory requirements; MAP 3.2 addresses risk context mapping; MANAGE 2.2 addresses risk mitigation through enforceable controls. AG-592 supports compliance by establishing structural governance boundaries that implement the framework's approach to AI risk management.
Clause 6.1 requires organisations to determine actions to address risks and opportunities within the AI management system. Clause 8.2 requires AI risk assessment. Workspace Map Integrity Governance implements a risk treatment control within the AI management system, directly satisfying the requirement for structured risk mitigation.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Organisation-wide — potentially cross-organisation where agents interact with external counterparties or shared infrastructure |
| Escalation Path | Immediate executive notification and regulatory disclosure assessment |
Consequence chain: Without workspace map integrity governance, the governance framework has a structural gap that can be exploited at machine speed. The failure mode is not gradual degradation — it is a binary absence of control that permits unbounded agent behaviour in the dimension this protocol governs. The immediate consequence is uncontrolled agent action within the scope of AG-592, potentially cascading to dependent dimensions and downstream systems. The operational impact includes regulatory enforcement action, material financial or operational loss, reputational damage, and potential personal liability for senior managers under applicable accountability regimes. Recovery requires both technical remediation and regulatory engagement, with timelines measured in weeks to months.