How to Build an AI Agent Inventory for FCA and ICO Supervision

At some point in the next twelve months, an FCA or ICO supervisor is going to ask a regulated firm to produce its AI agent inventory. The firms that have one (current, evidenced, and defensible) will handle that conversation confidently. The firms that do not will face a very different kind of meeting.

This article explains exactly how to build an AI agent inventory that holds up under supervision. Not a conceptual framework. A practical guide covering scope, discovery method, classification, and evidence: the four components that separate a defensible inventory from a spreadsheet that will not survive scrutiny.

FCA SYSC 8, EU AI Act Article 26, and the ICO AI Governance Framework (Control 4) all require regulated firms to maintain demonstrable oversight of AI systems in operation. An AI agent inventory is the foundation of that oversight.

Why a Spreadsheet Is Not Enough

The typical starting point for AI governance in most regulated firms is a manually maintained register: a spreadsheet listing the AI tools the IT or procurement team is aware of, updated when someone remembers to update it.

This approach fails regulatory scrutiny for three reasons. First, it captures only sanctioned tools. The AI agents that present the highest governance risk are frequently the ones that were not formally approved: Apps Script automations, Power Automate flows, individual employees' ChatGPT plugin connections. A manually maintained register does not find these.

Second, a spreadsheet is not evidence of monitoring. A supervisor asking for your AI agent inventory is not asking for a list. They are asking for proof that you know what is operating in your environment, that you are actively monitoring it, and that your knowledge was current as of a specific date. A spreadsheet does not provide that proof.

Third, a spreadsheet does not capture cross-platform patterns. An AI agent that reads customer data on Google Workspace and sends communications via Microsoft Exchange appears as two separate entries in a spreadsheet, or more likely, does not appear at all. The cross-platform combination is the risk. The individual platform entries are not.

What Regulators Actually Want to See

Before describing how to build an AI agent inventory, it is worth being precise about what FCA and ICO supervisors are actually asking for. Regulatory expectations in this area are derived from three sources:

FCA SYSC 8: Material Third-Party Arrangements

SYSC 8 governs outsourcing and material third-party arrangements. As AI agents increasingly access regulated data, perform functions affecting customers, or execute activities that form part of regulated services, they fall within the scope of what SYSC 8 was designed to govern. The FCA expects firms to identify these arrangements, assess their materiality, and demonstrate ongoing oversight. An AI agent inventory is the mechanism by which a firm demonstrates it knows what third-party AI arrangements are in place.

ICO AI Governance Framework: Control 4

The ICO's 11-control AI Governance and Accountability Framework includes Control 4: transparency and accountability for AI systems. The ICO expects organisations to maintain awareness of AI systems that process personal data, including their purpose, the categories of data processed, and the basis for their use. An AI agent inventory is the operational implementation of Control 4.

EU AI Act Article 26: Monitoring and Documentation

Article 26 requires deployers to monitor AI system operation and maintain documentation of that monitoring. The inventory is the foundation. You cannot monitor systems you have not inventoried.

The Four Components of a Defensible AI Agent Inventory

Component 1: Scope Definition

Before you can build an inventory, you need to define what counts as an AI agent for regulatory purposes. A workable definition for regulated firms: any software component that uses machine learning, large language models, generative AI, or rule-based automation to perform tasks that affect regulated activities, process personal data, or make or contribute to decisions that affect customers or employees.

Practically, this includes:

• Third-party AI tools procured through formal IT processes
• AI features embedded in SaaS products that your organisation uses: Salesforce Einstein, Microsoft Copilot, Google Workspace AI features
• Custom integrations built by your development team using AI APIs: OpenAI, Anthropic, Google Gemini, AWS Bedrock
• Automations built by business users using low-code/no-code platforms: Microsoft Power Automate, Google Apps Script, Zapier with AI steps
• Third-party SaaS tools with AI features that received OAuth grants to your organisational data when an employee connected their account

Component 2: Discovery Method

Once scope is defined, you need a method for finding AI agents within that scope. This is where most organisations' approaches break down. The problem is not that they do not look. It is that they look in the wrong places.

Checking the IT-approved software register finds sanctioned tools. It does not find the unsanctioned ones. Checking individual platform admin consoles finds what each platform knows about. It does not find cross-platform patterns.

A systematic discovery approach needs to query workspace admin APIs directly (Google Workspace Admin SDK, Microsoft Graph, Salesforce connected apps, OpenAI workspace settings) to enumerate every OAuth grant at admin level, both delegated (acting as a user) and application-level (service identities). This programmatic approach surfaces the long tail: the Apps Script running on a product manager's account, the Power Automate flow connecting to an external AI API, the ChatGPT plugin that a compliance analyst authorised six months ago.

Component 3: Classification

Discovery produces a list. Classification makes the list useful. Each discovered AI agent needs to be assessed across the dimensions that determine its governance risk:

• Data access scope: what categories of data can the agent access? Personal data? Financial data? Regulated information?
• External communication capability: can the agent send data outside the organisation? Via email, API calls, webhooks?
• Human-in-the-loop status: are there human approval steps in the agent's workflow, or does it operate fully autonomously?
• Regulatory touchpoints: does the agent touch activities that fall within regulated services? Credit assessment, customer communications, claims handling?
• Cross-platform pattern: does the agent operate across multiple platforms in ways that create compound risk not visible from any single platform?

Classification should produce a risk category for each agent (high, medium, or low) with the reasoning documented. The reasoning matters as much as the classification: a supervisor will want to understand why you classified a specific agent at a specific risk level, not just see the label.

Component 4: Evidence of Currency

The final component is what turns the inventory from a document into evidence. The inventory needs to be dated, signed, and reproducible, so that a supervisor can confirm not just what your inventory says today, but what it said at a specific date in the past, and that it has not been altered since.

This is the component most organisations are missing. A well-maintained spreadsheet, however accurate, does not provide evidence of currency. A cryptographically signed evidence pack, generated on a specific date, with a signature that can be verified against the content, does.

Maintaining the Inventory Over Time

Building the inventory is a one-time exercise. Maintaining it is an ongoing programme. Three practices make maintenance manageable:

Regular discovery cycles

Run programmatic discovery on a regular cadence (monthly is appropriate for most regulated firms) to detect new agents that have appeared since the last cycle. New SaaS tools with AI features, new OAuth grants authorised by users, new automations built by business teams: these appear between cycles and need to be captured.

Change-triggered updates

Major technology changes (new SaaS deployments, significant platform upgrades, AI vendor contract changes) should trigger an out-of-cycle inventory update. Building this into your change management process avoids the inventory becoming stale between regular cycles.

Signed evidence at each cycle

Each regular cycle should produce a signed evidence pack: a timestamped, cryptographically signed snapshot of the inventory and its findings at that point in time. This creates a chain of evidence showing continuous monitoring, which is what Article 26 and ICO Control 4 require, not just a current state picture.

How AETHER Pulse Builds and Maintains Your AI Agent Inventory

AETHER Pulse automates the discovery, classification, and evidence generation components of the AI agent inventory programme. It connects to Google Workspace, Microsoft 365, OpenAI Assistants, Salesforce Agentforce, Microsoft Copilot Studio, LangSmith, and AWS Bedrock through workspace admin APIs, enumerating every OAuth grant at admin level: delegated and application-level.

Each discovered agent is classified using AETHER's five-dimensional framework. Eight cross-platform toxic-combination patterns are detected through deterministic logic that produces reproducible findings. At configurable cadences (monthly by default) AETHER generates a signed evidence pack covering the full inventory, classifications, and findings, signed with HMAC-SHA256 per-tenant keys.

The evidence pack can be presented to a supervisor or auditor with the signature verified against the content, confirming that what they are seeing is identical to what was generated at the time of the scan. That is what regulatory-grade AI agent inventory evidence looks like.

Published methodology: aetherpulse.app/methodology

Frequently Asked Questions

How often should we update our AI agent inventory?

Monthly is a defensible minimum for most regulated firms, aligned to risk committee meeting cycles. The key is that the cadence is documented, followed consistently, and that each cycle produces signed evidence of the inventory state at that point.

Do we need to include AI features embedded in SaaS tools we use?

Yes, if those features access regulated data or perform functions that affect regulated activities. The fact that the AI feature is embedded in a tool you use for another purpose does not remove the governance obligation. Microsoft Copilot accessing customer data in your CRM, for example, is within scope.

What if we discover AI agents we did not know about?

Discovery of previously unknown agents is the expected outcome of a systematic inventory exercise. Most organisations find more than they expect. The important thing is to classify the discovered agents, assess their risk, and take proportionate action where risks are identified. The discovery itself demonstrates your governance programme is working.

Can we use a GRC tool to manage our AI agent inventory?

GRC tools can provide a framework for recording and managing inventory data. However, they typically do not provide programmatic discovery across workspace admin APIs or generate cryptographically signed evidence of inventory currency. A GRC tool combined with automated discovery and evidence generation is a stronger approach than either alone.

See how AETHER Pulse automates AI agent discovery and inventory →