AI agent governance: mapping agents alongside the rest of your IT landscape
An agent prepares payment reminders, retrieves customer data from the ERP and sends emails from the corporate mailbox. The accounting team knows how it works. But who knows which access rights it uses, what information it sends to its model, and whether another tool already covers the same need?
AI agent governance starts with this visibility: identifying each agent and linking it to the applications, data and activities it acts on. The IT map provides a framework for consolidating this information and reviewing it with the relevant owners.
The need is already tangible. In a Cloud Security Alliance survey of 418 IT and security professionals, 82% of respondents reported discovering previously unknown AI agents in their organisation over the past year. [1]
Where are the AI agents already operating in your IT landscape?
An agent can be enabled within a software product, built by a business team or developed in-house. Its introduction therefore does not always involve a project known to the IT department.
This article covers agents and assistants built on language models and connected to enterprise tools to retrieve information or perform actions. An assistant used without such connections can also raise confidentiality issues; it is simply outside the scope addressed here.
To build an initial inventory, several sources can be cross-referenced:
| Source | What to identify |
|---|---|
| AI features in software | The agents or assistants actually enabled, their users and their access rights. |
| Team subscriptions | Use of services such as ChatGPT, Claude or Le Chat, and the applications connected to them. |
| Cloud accounts and API access | The applications or automations that call models, their owners and their billing. |
| Automation platforms | Workflows in n8n, Make or Power Automate that include a language model, and the actions they execute. |
| MCP servers | The tools and data exposed, and the assistants authorised to use them. |
| In-house development | The agents deployed, their runtime environment and the team that maintains them. |
An API key, a model or an MCP server does not constitute an agent in itself. Each is an entry point for identifying usage. MCP (Model Context Protocol) allows an AI application to access tools and resources, among other capabilities. [2]
The inventory then works back from these traces to an identifiable use case: which agent, for which task, and under whose responsibility?
How should an agent be described in the IT map?
An agent shares several attributes already tracked for an application: an owner, a lifecycle, dependencies and a cost. The map must also specify its level of autonomy and the actions it is authorised to perform.
The metamodel defines the asset types, their properties and their relationships in the repository. Seven categories provide a basis for adding agents to it:
| Category | Information to document |
|---|---|
| Agent | Purpose, environment, status (test, pilot, production, retired) and level of autonomy. |
| Model | Model or models used, provider, version where known, and processing location. |
| Applications and access | Applications called, direct connection or via MCP, account used, permissions and authorised actions. |
| Data | Business objects concerned, their sensitivity, and the information actually transmitted to external services. |
| Business activity | The process or capability that the agent supports or automates. |
| Owners | Business owner, technical owner and the person responsible for overseeing its use. One person may hold several of these roles. |
| Contract and cost | Billed service, contract or subscription, attributable consumption and cost centre. |
Illustration based on the Boldo interface · fictional data
Each record should also carry a last-verified date. Information that is still unknown remains flagged as such, with a named person responsible for completing it.
The nature of the relationships is what makes the map usable. “Reads invoices”, “drafts an email” and “sends a reminder without approval” describe different capabilities. A generic “uses email” relationship cannot distinguish between them.
Permissions granted must also be distinguished from actions actually performed. The map describes documented access and dependencies; execution logs are needed to verify actual activity.
Example: a payment reminder agent
The following situation is fictional.
During a spending review, an IT department identifies language model consumption that no known project accounts for. It traces it back to the accounting team, which has built an agent to send reminders for unpaid invoices.
1. Understand how it operates. The agent retrieves invoices and customer contact details from the ERP, drafts the messages and sends them by email without human approval. Accounting owns the use case, but no technical owner has been assigned.
2. Document its relationships. The team records the applications called, the account used and its permissions. A review of the workflow confirms that customer names, amounts and due dates are sent to a model service hosted outside the European Union. These flows are added to the map.
3. Identify an overlap. Once linked to the collections process, the agent appears alongside a CRM module used by the sales team. This proximity calls for verification: do both tools act on the same invoices? A comparison of their rules confirms that some customers may receive two reminders.
4. Decide on next steps. The owners can adapt the agent, limit the data it transmits, add human approval or align its scope with that of the CRM module. They can also favour the existing module and decommission the agent. The decision depends on the business need, the quality of service and the constraints on data processing.
5. Implement the decision in the tools. If the agent is retained, its access and behaviour are adjusted, a technical owner is assigned and the record is updated. If it is decommissioned, its execution is stopped and its dedicated access rights are revoked, after checking for any shared dependencies. Its history remains available in the repository.
Illustration based on the Boldo interface · fictional situation and data
The map does not make the decision. It consolidates the information required and identifies who needs to be consulted.
Which decisions does the map help prepare?
Review access and dependencies
Starting from an application, the team can identify the agents authorised to act on it and validate whether their permissions still match the need. Starting from a model service, it can identify the use cases and processes affected by a change of provider or a service outage.
These analyses depend on the quality of the relationships recorded. A known technical connection does not describe all the data flowing through it. For sensitive use cases, the map must be complemented by a review of configurations and data flows.
Prepare the compliance assessment
The inventory helps identify the systems to be assessed under the EU AI Act, depending on their use and the organisation’s role. An agent designed to analyse or screen job applications, for example, requires a review of the provisions on high-risk systems in employment.
Regulation (EU) 2026/1744 postpones to 2 December 2027 the application of the main obligations for the high-risk systems listed in Annex III. Other provisions of the AI Act already apply. [3]
For financial entities subject to DORA, the relevant ICT service contracts must be recorded in the register of information required by the regulation. [4] Linking agents to their services and contracts supports this classification work. The map provides useful input; compliance also requires controls and procedures.
Understand costs and duplication
Linking an agent to its contract, its consumption and its business activity makes it possible to review costs with the team that benefits from it. When a subscription or API access is shared, an allocation rule is required to avoid counting the same cost more than once.
The map also helps identify similar use cases. As in the invoice example, comparing them opens a discussion on scope and expected outcomes. Two tools associated with the same process are not automatically interchangeable.
Where to start
Select a well-understood process and a small number of agents whose use can be validated with the teams. Prioritise those that perform actions without approval or handle sensitive data.
For each agent, first document its purpose, owner, accessible applications, permissions, transmitted data and model. This initial scope is sufficient to identify missing information and raise specific questions.
Then establish two lifecycle rules:
- At go-live: the record is completed, access rights are reviewed and responsibilities are assigned.
- At decommissioning: execution is stopped, access rights are revoked or adjusted, and the record moves to “retired” status, with its history retained.
The second rule deserves particular attention: only 21% of respondents to the Cloud Security Alliance survey report having a formal process for decommissioning agents. [1]
Include the inventory check in existing architecture reviews. Update the records whenever an agent changes model, tools, permissions or level of autonomy: such changes can alter its scope of action between two reviews.
Mapping your AI agents in Boldo
In Boldo, the starting point is the same as for the rest of the IT landscape: describing assets and their relationships in a shared repository. For AI agents, the scope to establish covers their purpose, their owners, the applications they use, the data concerned and the processes they support.
Start from a concrete case, such as your collections process. The map should help you identify the use cases that contribute to it, their dependencies and the information to validate before a decision.
Request a demo to discuss your case and define how to integrate your agents into your IT map.
Sources
- Cloud Security Alliance, Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises, 2026. Survey of 418 IT and security professionals conducted in January 2026, commissioned and funded by Token Security. Press release, 21 April 2026.
- Model Context Protocol, Architecture overview.
- European Union, Regulation (EU) 2026/1744 of 8 July 2026, in particular the amendment to Article 113 of the AI Act.
- European Union, Regulation (EU) 2022/2554 (DORA), Article 28(3).
