Topology Inventory Governance

2. Summary

Topology Inventory Governance requires that every organisation operating multi-agent systems maintains a current, machine-readable map of all agent nodes, their supervisory relationships, peer connections, shared dependencies, and communication pathways. The inventory must be updated in near-real-time as agents are provisioned, decommissioned, re-assigned, or dynamically spawned — failure to maintain accuracy converts the topology map from a governance artefact into a false assurance artefact that actively hinders incident response. Without a current topology inventory, organisations cannot attribute blame across agent boundaries, cannot enforce delegation depth limits, cannot detect unauthorised coalition formation, and cannot satisfy regulatory demands for system-of-systems transparency.

3. Example

Scenario A — Unregistered Agent Node Processes €4.2 Million in Unsanctioned FX Trades: A European investment bank deploys a multi-agent system for foreign exchange order routing. The topology inventory records twelve agent nodes: four order-takers, four risk-checkers, and four execution agents. During a routine scaling event, the orchestration platform spawns a thirteenth execution agent to handle volume spikes. The spawned agent is not registered in the topology inventory because the auto-scaling hook was never integrated with the governance registry. The unregistered agent receives delegated authority from a risk-checker but, lacking a topology entry, is invisible to the aggregate exposure monitor. Over six hours, the phantom agent executes €4.2 million in trades that are not counted against the desk's position limits. The breach is discovered only when the prime broker flags a margin discrepancy the following morning.

What went wrong: The auto-scaling infrastructure operated independently of the governance registry. No preventive control required topology registration before an agent could receive delegated authority or execute actions. The topology inventory was treated as a reporting convenience rather than a structural prerequisite for operational authorisation. Consequence: €4.2 million in unmonitored position exposure, €780,000 margin call, FCA enforcement investigation under SYSC 6.1.1R for inadequate systems and controls, €2.1 million regulatory fine, suspension of automated trading authorisation pending remediation.

Scenario B — Circular Dependency Causes Cascading Deadlock in Insurance Claims Processing: An insurance group operates a claims processing pipeline with thirty-seven agent nodes across three subsidiaries. Agent nodes are documented in separate spreadsheets maintained by each subsidiary's operations team. No consolidated topology exists. When a regulatory change requires updating the fraud-detection logic, the central IT team modifies Agent-F17's dependency configuration to route suspicious claims through a new verification agent (Agent-V03). Unknown to the central team, Agent-V03 already depends on Agent-F17 for enrichment data — a relationship documented only in Subsidiary B's spreadsheet. The circular dependency triggers a cascading deadlock: 14,000 claims stall in the pipeline over a weekend. The average claim value is £8,200, creating a £114.8 million processing backlog. Regulatory SLA breaches begin at 48 hours; the deadlock is not resolved until Monday morning at 72 hours.

What went wrong: No consolidated, machine-readable topology existed. Dependencies were tracked in disconnected human-maintained spreadsheets that were not cross-referenced. The configuration change was made without automated dependency-cycle detection because no authoritative dependency graph existed to check against. Consequence: £114.8 million in delayed claims, 9,400 SLA breaches triggering regulatory reporting to the PRA, estimated £3.4 million in compensation payments to affected policyholders, reputational damage quantified at £12 million in subsequent quarter's policy cancellations.

Scenario C — Shadow Agent Network Exfiltrates Citizen Data from a Government Benefits Platform: A national benefits administration agency deploys a multi-agent system to process disability benefit applications. The approved topology comprises fifteen agents with defined roles: intake, eligibility verification, medical evidence review, decision drafting, and notification. A compromised software supply chain introduces a covert agent node that registers itself as a "logging helper" within the orchestration framework. Because the topology inventory is only reconciled quarterly through a manual audit, the shadow agent operates undetected for eleven weeks. During this period, it intercepts and exfiltrates 340,000 citizen records — including medical diagnoses, income data, and national identity numbers — to an external endpoint. The breach is discovered when a threat intelligence service identifies the data on a dark-web marketplace.

What went wrong: The topology inventory was not continuously reconciled against the running agent population. No mechanism existed to detect or block agent nodes that were not pre-registered in the authoritative inventory. The quarterly manual audit cycle created an eleven-week window of vulnerability. Consequence: 340,000 citizens' personal and medical data compromised, estimated remediation cost of $47 million including notification, credit monitoring, and litigation, agency leadership replaced, criminal investigation initiated, legislative inquiry into AI governance failures in public services.

4. Requirement Statement

Scope: This dimension applies to all systems in which two or more AI agents operate concurrently and interact through any mechanism — direct messaging, shared data stores, event buses, API calls, file systems, or any other communication channel. A single isolated agent is outside scope unless it has the capability to spawn, invoke, or delegate to additional agents at runtime. The scope includes agents that are dynamically spawned, auto-scaled, or ephemerally created for single tasks. It extends to agents provided by third-party services that participate in the organisation's workflows — the organisation must maintain topology entries for all agents that process its data or execute actions on its behalf, regardless of where those agents are hosted. Agents operating across organisational boundaries in federated topologies must be represented in each participating organisation's inventory with sufficient detail to support cross-boundary incident investigation.

4.1. A conforming system MUST maintain a machine-readable topology inventory that records every agent node authorised to operate within the system, including for each node: a unique agent identifier (per AG-011), the agent's role classification, its supervisory relationships (supervisor and subordinate links), its peer connections, its shared resource dependencies, its communication channel memberships, and the timestamp of its most recent registration or update.

4.2. A conforming system MUST update the topology inventory before an agent node begins processing — no agent may receive messages, delegated authority, or execute actions until its topology registration is confirmed.

4.3. A conforming system MUST reject any interaction directed to or originating from an agent node that is not present in the current topology inventory.

4.4. A conforming system MUST perform continuous reconciliation between the topology inventory and the actual running agent population, detecting discrepancies within a defined latency threshold not exceeding five minutes for high-risk deployments.

4.5. A conforming system MUST record topology change events — including node additions, removals, relationship modifications, and dependency changes — in an append-only audit log with timestamps and attribution to the initiating actor or process.

4.6. A conforming system MUST validate that proposed topology changes do not introduce circular dependencies, orphaned nodes without supervisors, or violations of maximum delegation depth (per AG-396) before applying those changes.

4.7. A conforming system MUST block agent operations system-wide when the topology inventory becomes unavailable or corrupted, rather than permitting operations without topology awareness.

4.8. A conforming system SHOULD expose the topology inventory through a standardised query interface that governance tooling, monitoring systems, and incident response teams can interrogate in real time.

4.9. A conforming system SHOULD support topology versioning such that the complete topology state at any historical point can be reconstructed from the audit log.

4.10. A conforming system SHOULD generate automated alerts when topology metrics exceed defined thresholds — including total node count, dependency fan-out per node, maximum hierarchy depth, and rate of topology change events.

4.11. A conforming system MAY implement visual topology rendering to support human oversight and incident investigation.

4.12. A conforming system MAY support federation protocols that allow topology inventories from different organisations to be cross-referenced for inter-organisational agent interactions.

5. Rationale

Multi-agent systems introduce a category of risk that is absent from single-agent deployments: the risk that the organisation does not know what agents are operating, how they are connected, or what dependencies exist between them. This ignorance is not merely an operational inconvenience — it is a fundamental governance failure that undermines every other control in the framework. You cannot enforce delegation depth limits (AG-396) if you do not know the delegation chain. You cannot attribute blame across agent boundaries (AG-398) if you do not know which agents interacted. You cannot verify that supervisor-subordinate relationships are properly configured (AG-390) if you do not have an authoritative record of those relationships. The topology inventory is the prerequisite for multi-agent governance.

The challenge intensifies in modern deployment patterns where agents are dynamically provisioned. Container orchestration platforms, serverless functions, and auto-scaling policies create and destroy agent instances continuously. If the governance framework requires manual registration of each agent, it will inevitably fall behind the reality of the running system. AG-389 therefore requires that topology registration be integrated into the agent lifecycle — an agent that has not been registered cannot operate. This inverts the typical pattern where agents are deployed first and documented later. The topology inventory becomes a structural gate, not a documentation exercise.

The regulatory environment increasingly demands system-of-systems transparency. The EU AI Act's Article 9 requires risk management across the entire AI system, which for multi-agent deployments means understanding how agents interact and what failure modes those interactions create. DORA's Article 9 requires financial entities to identify and document ICT assets and their interdependencies — agent nodes and their relationships are ICT assets within this meaning. The FCA's operational resilience framework requires firms to map important business services and identify the resources that support them — a multi-agent topology map is precisely this resource identification for AI-driven services.

Historical incidents in distributed systems — not solely AI systems — demonstrate the consequence of operating without accurate topology awareness. The 2012 Knight Capital incident, where a rogue trading algorithm accumulated $440 million in losses in 45 minutes, was fundamentally a topology failure: the firm did not have real-time awareness of which software instances were active and what configuration each was running. The same failure mode applies to multi-agent AI systems, with the added complexity that agents may autonomously modify their own relationships and spawn new agents. Without a structural requirement for topology registration before operation, the organisation is navigating a multi-agent system with an outdated map — and in fast-moving deployments, an outdated map is worse than no map, because it creates false confidence.

6. Implementation Guidance

The topology inventory is a governance-critical data store that must meet the same availability and integrity standards as the systems it governs. It should be implemented as a persistent, replicated data store with transactional semantics — not as an in-memory cache, a flat file, or a spreadsheet. The inventory is a structural prerequisite for agent operation, meaning its unavailability must halt agent operations rather than permit ungoverned execution.

Recommended patterns:

• Registry-gated lifecycle management. Integrate topology registration into the agent provisioning pipeline so that no agent runtime receives credentials, network access, or message-queue subscriptions until the governance registry confirms its topology entry. The orchestration platform issues a registration request to the topology service, which validates the proposed entry (checking for dependency cycles, hierarchy depth violations, and duplicate identifiers), writes the entry to the persistent store, and returns a registration token. The agent runtime receives its operational credentials only after presenting the registration token. Decommissioning follows the reverse path: credentials are revoked, the topology entry is marked inactive, and the change is logged.
• Event-sourced topology store. Implement the topology inventory as an event-sourced system where every change — node addition, relationship modification, dependency update, node removal — is recorded as an immutable event. The current topology state is a projection of the event stream. This provides built-in audit logging, historical reconstruction, and point-in-time query capability without additional infrastructure. Snapshots at defined intervals support efficient reconstruction of historical states.
• Continuous reconciliation daemon. Deploy a reconciliation process that periodically compares the topology inventory against the actual running agent population. The daemon queries the orchestration platform's runtime state, compares it against the topology registry, and generates alerts for any discrepancy: an agent running without a topology entry (phantom node), a topology entry without a running agent (stale entry), or a relationship mismatch between the registered and actual communication patterns. The reconciliation interval must not exceed the latency threshold defined in the organisation's risk policy — five minutes for high-risk deployments per requirement 4.4.
• Dependency graph validation on change. Before applying any topology modification — adding a node, changing a supervisory relationship, adding a dependency — run automated validation against the full dependency graph. Check for circular dependencies using cycle detection algorithms, verify that maximum delegation depth (per AG-396) is not exceeded, confirm that every non-root node has exactly one supervisor (per AG-390), and verify that shared resource dependencies do not exceed defined fan-out limits. Reject the change with a structured explanation if any validation fails.

Anti-patterns to avoid:

• Treating the topology inventory as documentation. If the topology inventory is maintained for informational purposes but is not enforced as a prerequisite for agent operation, it will inevitably drift from reality. A topology inventory that does not block unregistered agents is a documentation artefact, not a governance control. The critical distinction is enforcement: the inventory must be in the operational path, not beside it.
• Manual registration processes. Any topology registration process that requires a human to update a registry, submit a ticket, or edit a configuration file will lag behind automated provisioning. In auto-scaling environments, manual registration is not merely slow — it is structurally incompatible with the deployment model. Registration must be automated and integrated into the provisioning pipeline.
• Storing topology in agent memory. If each agent maintains its own view of the topology — through peer discovery, gossip protocols, or cached topology snapshots — the system has multiple potentially inconsistent topology views rather than one authoritative source. Agents should query the authoritative topology service, not maintain local copies that may be stale or manipulated.
• Reconciliation-only governance without registration gating. Some organisations implement periodic reconciliation (comparing the inventory against reality) without registration gating (requiring registration before operation). This means that between reconciliation cycles, unregistered agents can operate freely. The reconciliation catches the discrepancy after the fact, but the governance gap during the cycle permits exactly the harms AG-389 is designed to prevent.
• Separate inventories per team or subsidiary. Fragmented topology inventories — one per team, per subsidiary, or per deployment environment — recreate the cross-boundary blindness that Scenario B illustrates. The inventory must be consolidated or federated with cross-reference capability such that any dependency, regardless of organisational boundary, is visible from any query point.

Industry Considerations

Financial Services. Multi-agent trading systems must maintain topology inventories that integrate with existing IT asset management and change management processes. The topology inventory should be classified as a critical ICT asset under DORA Article 9 requirements. Each agent node's topology entry should include regulatory classification (e.g., whether the agent executes regulated activities) to support supervisory reporting. The FCA expects firms to demonstrate real-time awareness of all automated systems operating in regulated markets.

Healthcare. Multi-agent clinical decision support systems must maintain topology inventories that record which agents have access to patient data, which agents can generate clinical recommendations, and which agents can trigger actions in electronic health record systems. The topology inventory supports HIPAA minimum necessary compliance by documenting the scope of each agent's data access. Agent nodes that process protected health information must be identified in the topology with PHI-access flags.

Public Sector. Government multi-agent systems processing citizen data must maintain topology inventories that support Freedom of Information requests, Data Protection Impact Assessments, and parliamentary oversight. The topology inventory must be accessible to data protection officers and auditors. Agent nodes processing data subject to specific legal bases (e.g., benefits administration under statutory authority) must be identified in the topology with their legal basis classification.

Crypto/Web3. Decentralised multi-agent systems operating across blockchain networks face unique topology challenges because agent nodes may be pseudonymous or operate across trust boundaries. The topology inventory for the organisation's own agents must still be maintained, but federation protocols (requirement 4.12) become essential for tracking interactions with external agent networks. Smart contract addresses and on-chain identifiers should be included in topology entries for blockchain-interacting agents.

Maturity Model

Basic Implementation — The organisation maintains a topology inventory in a structured data store (database or configuration management system) that records all deployed agent nodes with unique identifiers, role classifications, and supervisory relationships. The inventory is updated as part of the deployment process, but update is procedural rather than enforced — an agent could technically operate before registration if the deployment process is circumvented. Reconciliation between the inventory and running agents is performed on a scheduled basis (e.g., daily). The inventory supports manual queries but does not expose a programmatic API. This level meets the minimum spirit of AG-389 but lacks the structural enforcement that prevents governance gaps between registration and reconciliation cycles.

Intermediate Implementation — Topology registration is enforced as a prerequisite for agent operation — no agent receives operational credentials or network access until registered. The inventory is maintained as a persistent, replicated data store with transactional writes. Every topology change is logged in an append-only audit trail with timestamps and attribution. Automated dependency graph validation prevents circular dependencies and hierarchy depth violations at change time. Continuous reconciliation runs at intervals not exceeding five minutes, with automated alerting on discrepancy detection. The inventory exposes a standardised query API for governance tooling and incident response. Historical topology states can be reconstructed from the audit log.

Advanced Implementation — All intermediate capabilities plus: the topology inventory operates as a highly available, replicated service with defined SLAs matching or exceeding the availability targets of the agent systems it governs. Topology changes trigger automated impact analysis across all governance dimensions — checking not only for dependency cycles and depth violations but also for aggregate risk concentration, single-point-of-failure introduction, and compliance boundary crossings. The inventory integrates with the organisation's broader IT service management ecosystem. Federation protocols allow cross-organisational topology queries for multi-party agent deployments. The reconciliation daemon uses multiple independent signals (orchestration platform state, network traffic analysis, message queue subscriptions) to detect phantom nodes that may have bypassed the registration gate. The organisation has conducted independent adversarial testing of topology integrity, including attempts to operate unregistered agents, inject false topology entries, and corrupt the reconciliation process.

7. Evidence Requirements

Required artefacts:

• Topology inventory export. A complete, machine-readable export of the current topology inventory showing all registered agent nodes, their attributes, relationships, dependencies, and registration timestamps. Format: structured data (JSON, YAML, or database export). Must be producible on demand, not reconstructed from other sources.
• Topology change audit log. An append-only log of all topology change events — additions, removals, relationship modifications, and dependency changes — with timestamps and attribution to the initiating actor or process. Must demonstrate continuous maintenance, not periodic bulk updates.
• Reconciliation execution records. Timestamped records of each reconciliation cycle showing: the comparison performed, any discrepancies detected, the resolution of each discrepancy, and the elapsed time from detection to resolution. Must demonstrate that reconciliation occurs within the defined latency threshold.
• Registration gate enforcement evidence. Architecture documentation and test results demonstrating that unregistered agents are structurally prevented from operating — not merely flagged after the fact. This may include network configuration showing that credentials are not issued without registration, or test results showing that an agent attempting to operate without registration is blocked.
• Dependency validation records. Records of topology change requests that were rejected due to validation failures (circular dependencies, depth violations, orphaned nodes), demonstrating that the validation logic is active and enforcing constraints.

Retention requirements:

• Topology inventory snapshots and change audit logs: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Reconciliation records: minimum 3 years for all deployments.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. The current topology inventory must be queryable in real time. Historical states must be reconstructable from the audit log within the retention period.

8. Test Specification

Testing AG-389 compliance requires verifying both the completeness of the topology inventory and the structural enforcement of registration as a prerequisite for operation. The following tests address each mandatory requirement.

Test 8.1: Registration Gate Enforcement

• Stimulus: Attempt to deploy and operate an agent node without first registering it in the topology inventory. Bypass the standard provisioning pipeline by directly deploying the agent runtime and attempting to connect to message queues, APIs, or shared data stores.
• Expected behaviour: The agent is unable to receive messages, obtain delegated authority, or execute any action. The system rejects all interactions involving the unregistered agent.
• Pass criteria: No unregistered agent successfully processes any message, executes any action, or participates in any interaction. The rejection is structural (credentials not issued, network access denied) rather than advisory.
• Fail criteria: An unregistered agent successfully receives a message, executes an action, or participates in any system interaction.

Test 8.2: Interaction Rejection for Unregistered Nodes

• Stimulus: From a registered agent, attempt to send a message to, delegate authority to, or invoke an agent identifier that does not exist in the topology inventory. Test with both fabricated identifiers and identifiers of agents that were previously registered but have since been decommissioned.
• Expected behaviour: The system rejects the interaction with a structured error indicating that the target agent is not in the current topology inventory.
• Pass criteria: No interaction succeeds with a non-registered target. Stale identifiers from decommissioned agents are rejected identically to fabricated identifiers.
• Fail criteria: Any interaction succeeds with a target not present in the current topology inventory.

Test 8.3: Continuous Reconciliation Accuracy

• Stimulus: Introduce a controlled discrepancy by directly deploying an agent runtime without using the standard provisioning pipeline (simulating a configuration error or compromise). Measure the time from the discrepancy's introduction to the reconciliation daemon's detection and alert generation.
• Expected behaviour: The reconciliation daemon detects the phantom agent within the defined latency threshold (not exceeding five minutes for high-risk deployments per requirement 4.4) and generates an alert.
• Pass criteria: Detection occurs within the defined latency threshold. The alert contains sufficient information to identify and remediate the discrepancy (agent location, runtime details, timestamp of detection).
• Fail criteria: The phantom agent is not detected within the latency threshold, or the alert lacks actionable information.

Test 8.4: Circular Dependency Prevention

• Stimulus: Submit a topology change that would introduce a circular dependency (Agent A depends on Agent B, Agent B depends on Agent C, proposed change makes Agent C depend on Agent A). Test with both direct cycles (A→B→A) and indirect cycles (A→B→C→D→A) of varying lengths.
• Expected behaviour: The topology service rejects the change with a structured explanation identifying the cycle that would result.
• Pass criteria: No topology change that introduces a circular dependency is applied. The rejection message identifies the specific cycle.
• Fail criteria: A circular dependency is introduced into the topology, or the change is rejected without identifying the cycle.

Test 8.5: Topology Change Audit Completeness

• Stimulus: Execute a sequence of topology changes — add three nodes, modify two supervisory relationships, add a dependency, remove one node — and then independently verify the audit log against the known sequence of changes.
• Expected behaviour: Every change is recorded in the audit log with: the change type, the affected entities, the before and after state, the timestamp, and the attribution to the initiating actor or process. No changes are missing from the log. No phantom entries exist in the log.
• Pass criteria: The audit log contains exactly one entry per change, with complete metadata, in correct chronological order. The log is append-only — entries cannot be modified or deleted.
• Fail criteria: Any change is missing from the audit log, any entry lacks required metadata, or the log can be modified after the fact.

Test 8.6: Fail-Safe Under Topology Service Unavailability

• Stimulus: Disable or degrade the topology inventory service — stop the service, revoke its database credentials, introduce a network partition between the service and the agent orchestration layer. Then attempt to deploy new agents, modify topology relationships, and continue operating existing agents.
• Expected behaviour: The system blocks all agent operations that require topology verification — new deployments, relationship changes, and (depending on implementation) ongoing operations of existing agents. The system does not default to permissive operation when the topology service is unavailable.
• Pass criteria: No new agent deployment succeeds, no topology change is applied, and the system either halts agent operations or operates within a defined degraded mode that does not permit ungoverned interactions. Intersects with AG-008.
• Fail criteria: New agents deploy successfully, topology changes are applied, or agents continue operating without topology verification during the unavailability period.

Test 8.7: Historical Topology Reconstruction

• Stimulus: Execute a series of topology changes over a defined period. Then request reconstruction of the complete topology state at a specific historical timestamp midway through the change sequence.
• Expected behaviour: The system reconstructs the topology state as it existed at the requested timestamp, reflecting all changes applied before that timestamp and none applied after.
• Pass criteria: The reconstructed topology exactly matches the known state at the requested timestamp. Verification against independently recorded snapshots confirms accuracy.
• Fail criteria: The reconstructed topology includes changes that occurred after the requested timestamp, omits changes that occurred before, or cannot be reconstructed at all.

Conformance Scoring

• Score 0: No topology inventory exists — the organisation cannot enumerate the agent nodes operating within its systems or describe their relationships.
• Score 1: A topology inventory exists but is maintained as documentation only — agents can operate without being registered, and reconciliation is periodic or manual.
• Score 2: Topology registration is enforced as a structural prerequisite for agent operation, continuous reconciliation operates within defined latency thresholds, and all changes are logged in an append-only audit trail.
• Score 3: Verified by independent adversarial testing — an independent party has attempted to operate unregistered agents, inject false topology entries, introduce circular dependencies, and corrupt the reconciliation process, and all attempts have been detected and blocked.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Direct requirement
EU AI Act	Article 11 (Technical Documentation)	Direct requirement
SOX	Section 404 (Internal Controls Over Financial Reporting)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
NIST AI RMF	GOVERN 1.1, MAP 1.5, MANAGE 2.2	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks), Clause 8.4 (AI System Operation)	Supports compliance
DORA	Article 9 (ICT Risk Management Framework), Article 8 (Identification)	Direct requirement

EU AI Act — Article 9 (Risk Management System)

Article 9 requires providers of high-risk AI systems to establish and maintain a continuous risk management system that identifies and analyses known and reasonably foreseeable risks. For multi-agent AI systems, the risks arising from agent interactions, dependency chains, and topology changes are among the most significant foreseeable risks. AG-389 implements the foundational control for identifying and managing these risks by requiring that the topology — the structure from which interaction risks emerge — is known, current, and governed. An organisation that cannot enumerate its agent nodes or describe their relationships cannot credibly claim to have identified the risks arising from those relationships, as Article 9 requires.

EU AI Act — Article 11 (Technical Documentation)

Article 11 requires that high-risk AI systems be accompanied by technical documentation demonstrating compliance, including a general description of the AI system and how it interacts with other systems. For multi-agent deployments, the topology inventory is the authoritative source for this documentation requirement. The topology inventory provides the machine-readable, current, auditable description of system architecture that Article 11 envisages — not a static document prepared at deployment time and never updated.

SOX — Section 404 (Internal Controls Over Financial Reporting)

For organisations where multi-agent systems execute or influence financial operations, the topology inventory is an internal control artefact. Section 404 requires management to assess the effectiveness of controls, and auditors to attest to that assessment. An auditor examining a multi-agent financial system will ask: "How many agents operate in this system, what does each one do, and how do you know this information is current?" The topology inventory provides the answer. The absence of a topology inventory is a control deficiency because the organisation cannot demonstrate awareness of the components executing within its financial control environment.

FCA SYSC — 6.1.1R (Systems and Controls)

SYSC 6.1.1R requires firms to establish and maintain adequate policies and procedures sufficient to ensure compliance. For firms operating multi-agent systems, this means maintaining awareness of all automated components operating within the firm's regulatory perimeter. The FCA's supervisory approach to algorithmic trading — which requires firms to maintain inventories of all trading algorithms and their configurations — provides a direct precedent for AG-389's requirements applied to AI agents. The FCA expects firms to know what is running, how it is connected, and what it can do. A firm that cannot answer these questions for its AI agents is not maintaining adequate systems and controls.

NIST AI RMF — GOVERN 1.1, MAP 1.5, MANAGE 2.2

GOVERN 1.1 addresses organisational governance structures for AI risk management; MAP 1.5 addresses the identification of AI system components and their interactions; MANAGE 2.2 addresses risk mitigation through enforceable controls. AG-389 supports all three subcategories by establishing the topology inventory as the authoritative source of truth for system composition, component interactions, and the foundation upon which risk management controls operate.

ISO 42001 — Clause 6.1, Clause 8.4

Clause 6.1 requires organisations to determine actions to address risks within the AI management system. Clause 8.4 requires operational planning and control of AI systems. The topology inventory directly supports both requirements by providing the organisation with current, accurate knowledge of its AI system's composition and structure — a prerequisite for both risk identification (Clause 6.1) and operational control (Clause 8.4).

DORA — Article 9, Article 8

Article 8 of DORA requires financial entities to identify, classify, and document all ICT assets and their interdependencies. Agent nodes in a multi-agent system are ICT assets; their supervisory relationships, peer connections, and shared dependencies are interdependencies. Article 9 requires an ICT risk management framework that addresses these assets and dependencies. AG-389's topology inventory is the implementation of Article 8's identification requirement for AI agent deployments, and the foundation for Article 9's risk management requirement as it applies to multi-agent topology risks.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Organisation-wide — extends to partner organisations in federated multi-agent deployments; affects every governance dimension that depends on topology awareness

Consequence chain: Without an accurate, enforced topology inventory, the organisation loses fundamental awareness of what agents are operating and how they are connected. The immediate technical failure is the emergence of phantom agents — nodes that operate without governance registration, invisible to monitoring, auditing, and control systems. Phantom agents accumulate risk silently: they may execute actions that are not counted against aggregate limits, process data without authorisation tracking, and create dependencies that are not validated against depth or cycle constraints. The operational impact cascades through every governance dimension that assumes topology awareness: delegation depth enforcement (AG-396) becomes meaningless because the delegation chain is unknown; blame attribution (AG-398) becomes impossible because the interaction graph is incomplete; supervisor-subordinate clarity (AG-390) degrades because supervisory relationships are unverified. The business consequence includes regulatory enforcement for failure to maintain adequate systems and controls, inability to respond to incidents because the affected topology cannot be determined, material governed exposure through unmonitored agent operations, and complete loss of auditability for the period during which the topology was inaccurate. In the worst case — as illustrated in Scenario C — the absence of topology enforcement creates an attack surface for adversaries to introduce covert agent nodes into the organisation's operational environment, with consequences scaling to the sensitivity of the data and operations those nodes can access.