Build An Agent Tool Inventory Before Internal AI Agents Reach Production

Tools & Technical Tutorials

11 June 2026 | By Ashley Marshall

Internal AI agents fail quietly when nobody can list the tools they can call. Build the inventory before production, because tool access is where agent risk becomes operational risk.

Tool Access Is Where Agent Risk Becomes Real

The fastest way to misunderstand an internal AI agent is to treat it as a smarter chatbot. A chatbot produces text. An agent can retrieve files, query a CRM, update a ticket, send an email, create a refund, open a pull request, run a script, call an MCP server, hand off to another agent or trigger a workflow in Zapier, Make, ServiceNow, Salesforce, HubSpot, Jira, GitHub, Xero, Sage or Microsoft 365. The risk is not only in the model. It is in the tool surface that turns model output into business action.

The NCSC made this point plainly in its recent guidance on agentic AI. It said agentic systems can access data sources, remember context, make decisions, use tools and take actions without continuous human intervention. It also warned that broader access, unpredictable behaviour, task chaining and dependency on external systems increase the attack surface. That is exactly why a production review that only checks prompts, model choice and privacy settings is incomplete. The business needs to know what the agent can touch and what it can change. Source: NCSC, Thinking carefully before adopting agentic AI.

An agent tool inventory is the missing operating document. It is not a vendor brochure and it is not a developer README. It is a live register of each tool the agent can call, the business owner for that tool, the technical owner, the reason it is enabled, the permissions granted, the data categories involved, the actions allowed, the approval gate, the log location, the rollback route and the next review date. If the agent can call a payment tool, the inventory says who approved payment capability. If it can write to CRM, the inventory says whether it can update all records or only assigned accounts. If it can send an email, the inventory says whether messages are drafted, queued or sent automatically.

What this means in practice: before production, ask the team to print the agent's tool list and explain it in plain English. If nobody can explain why a connector is enabled, who owns it, what permission it uses and how to disable it quickly, the agent is still a pilot. That is not anti-innovation. It is the minimum discipline needed before a probabilistic system gets operational hands.

What Belongs In The Inventory

A useful inventory starts with boring fields, because boring fields make incidents easier. Record the agent name, version, environment, business purpose, owner, technical maintainer, model provider, orchestration framework and production status. Then list each tool separately. For every tool, capture the connector name, vendor, authentication method, permission scope, data accessed, action types, approval requirement, rate limit, error handling, audit log destination, data retention, review date and emergency disable path. This turns "our support agent uses Zendesk and Slack" into a defensible map of what the agent is actually allowed to do.

The ICO's disclosed internal AI policy is a useful benchmark because it shows how a regulator thinks about its own AI use. It says AI governance decisions should be logged, every AI deployment should have a risk assessment, accountability should be assigned, and an AI inventory should be maintained as part of the service catalogue. It also says no AI solution should be deployed without documented verification and validation, and that internal AI should be monitored for compliance, task performance, fairness, usage and cost effectiveness. Source: ICO internal AI use policy disclosure.

For a tool inventory, the key is granularity. "Microsoft Graph" is not enough. Which Graph scopes? Mail.Read, Mail.Send, Files.Read.All, Sites.Selected, Calendars.ReadWrite or User.ReadBasic.All are very different risk decisions. "CRM access" is not enough. Can the agent read all contacts, update pipeline stages, merge records, export lists or create tasks? "GitHub access" is not enough. Can it read private repositories, create branches, approve workflows, access secrets or trigger deployment actions? "Database access" is not enough. Is it read-only, row-filtered, masked, write-capable or connected through a governed API?

What this means in practice: build the inventory at the same time as the agent, not after launch. Use a spreadsheet if you must, but keep it close to the deployment process. For small teams, a simple register in Notion, Airtable, Confluence or a protected repository is better than a polished governance tool nobody updates. For larger teams, connect it to identity governance, CMDB, data catalogue or SIEM tooling. The format matters less than the discipline: every enabled tool needs a named purpose, bounded permission and review owner.

Map Permissions Before You Debate Model Risk

Many internal AI reviews start with the wrong question: which model are we using? Model choice matters, but a cautious model with excessive permissions can still cause serious damage. A capable model with narrow permissions, strong logging and human approvals may be safer than a weaker model with broad tool access. The practical question is not "is the model safe?" It is "what can this agent do if it misunderstands a goal, receives hostile input or follows a bad instruction?"

Microsoft's February 2026 Cyber Pulse article reported that more than 80 percent of Fortune 500 companies use active AI agents built with low-code or no-code tools, based on Microsoft first-party telemetry from November 2025. It also reported that 29 percent of employees had turned to unsanctioned AI agents for work tasks, and it identified a registry as one of five core capabilities for agent observability and governance. Source: Microsoft Security, Cyber Pulse on AI agents.

Those figures matter for UK mid-market businesses because low-code agent building is moving faster than governance. A department can create an agent in Copilot Studio, Salesforce Agentforce, ServiceNow, Google ADK, LangGraph, n8n, Zapier Agents or a custom OpenAI Agents SDK workflow before security, legal and operations have a shared view of its tool access. This is how shadow AI becomes action-capable. The agent is not only answering questions. It is authenticating to systems through OAuth, API keys, service principals, personal accounts or MCP servers that may not be visible in the normal software register.

A permission map should distinguish read, write, execute and communicate. Read access means the agent can retrieve data. Write access means it can alter records. Execute access means it can run code, start jobs, trigger automations or call systems that perform changes elsewhere. Communicate access means it can send messages to customers, suppliers, staff or public channels. Each category needs a different approval threshold. A research assistant that reads public documents is low-risk. A finance agent that can read supplier emails, update Xero and send payment instructions is not low-risk just because the prompt says "be careful".

The leading misconception is that the agent cannot do anything dangerous unless the model is malicious. That is too narrow. Most production failures will come from ordinary misinterpretation, excessive access, stale context, prompt injection through documents or emails, weak approval points, poor logging and unclear ownership. A tool inventory does not make the model perfect. It makes the blast radius visible.

Approval Gates Should Match The Tool, Not The Demo

An agent demo usually shows the happy path. The user asks for help, the agent selects the right tool and the result appears. Production is less tidy. A customer email can include a malicious instruction. A CRM record can contain old notes. A supplier invoice can be ambiguous. A policy document can conflict with a newer decision. A model can call the right tool with the wrong argument. The inventory should therefore record approval gates per tool and per action, not as a vague promise that "a human is in the loop".

OpenAI's Agents SDK documentation is useful here because it treats tools as action channels and includes mechanisms such as function tools, local runtime tools, hosted tools, agents as tools, conditional tool enabling, approval gates and tracing. Its tracing documentation says traces can record LLM generations, tool calls, handoffs, guardrails and custom events. That is the kind of implementation detail a production inventory should demand from any agent platform or custom build. Sources: OpenAI Agents SDK tools documentation and OpenAI Agents SDK tracing documentation.

The approval gate should be explicit. A summarisation tool may need no approval if it only reads permitted documents and produces a draft. A CRM update may need approval when it changes a customer status, but not when it adds an internal note. An email tool may be allowed to draft messages automatically but require human approval before sending. A refund tool may require approval above a GBP 25 threshold. A code execution tool should run in a sandbox by default and require review before changes reach a production repository. A payment or payroll tool should have a very high bar, with segregation of duties and a clear audit trail.

What this means in practice: define tool modes. Use "disabled", "read-only", "draft", "approve before action", "limited autonomous action" and "fully blocked in production" as practical states. Put those states in the inventory and in the agent configuration. This avoids a common production trap where stakeholders think the agent is only drafting, while developers have already enabled a write-capable connector because it was useful during testing. The inventory becomes the shared contract between the business process and the technical build.

UK Governance Requires Evidence, Not Intent

For UK businesses, agent tool inventory is not only a security habit. It is evidence. If an internal agent processes personal data, UK GDPR accountability still applies. If it supports regulated financial services, existing FCA rules still apply. If it affects employment, recruitment, complaints, credit, healthcare, legal work or vulnerable customers, the business needs to show how it understood and controlled the workflow. A tool inventory gives compliance teams something concrete to review instead of a general description of an "AI assistant".

The ICO warned in May 2026 that organisations using AI tools to process high-risk personal data should have a data protection impact assessment and appropriate safeguards, including against AI-targeting attacks. It also pointed organisations to the government's AI Cyber Security Code of Practice. Source: ICO, five steps to protect your organisation from AI-powered cyber threats. The ICO's wider AI strategy says it will engage with industry on the data protection implications of agentic AI, including accountability and redress. Source: ICO AI and biometrics strategy plan of action.

The FCA is also taking a live testing approach rather than pretending AI can be judged only on paper. In April 2026 it named eight firms in the second cohort of AI Live Testing, including Barclays, Experian, GoCardless, Lloyds Banking Group Scottish Widows and UBS. The use cases include agentic payments, anti-money laundering detection, Know Your Customer and credit score insights. The FCA said testing will conclude by the end of 2026, with an evaluation report due in Q1 2027, and noted a 49 percent increase in Regulatory Sandbox and Innovation Pathways applications on the previous year. Source: FCA announcement on the second AI Live Testing cohort.

The practical message is clear. Regulators are not asking firms to stop using AI. They are asking firms to understand risk, test in context, document decisions, monitor behaviour and keep accountability visible. An agent tool inventory helps with all five. It links the DPIA to actual connectors. It links cyber review to actual permissions. It links operational testing to actual action paths. It links incident response to actual logs. For any business preparing internal agents for production, that is the difference between "we intended it to be safe" and "we can show how it was controlled".

Start Small, Then Make The Inventory A Release Gate

The counterargument is that an inventory sounds like paperwork. Internal teams are already under pressure to ship. If every proof of concept needs a governance pack, experimentation slows down and staff go back to unsanctioned tools. That concern is real. The answer is not to impose a heavyweight approval board on every prompt experiment. The answer is to make the inventory proportionate and to use it as a production gate, not a creativity tax.

Start with three levels. Level one is exploration: no business system access, no personal data, no external messages, no write actions. The inventory can be light, usually just owner, purpose and tool names. Level two is controlled pilot: limited data, named users, read-only or draft-only actions, test logs and a short review date. The inventory should record permissions, approval points and rollback. Level three is production: live business data, repeatable workflow, more users, possible customer impact or write actions. The inventory becomes mandatory and should be reviewed by the process owner, technical owner and whichever of security, data protection, legal or compliance is relevant.

Microsoft's May 2026 Entra guidance shows where enterprise tooling is heading. It says agent identities can be governed in a similar lifecycle to human identities, with sponsors responsible for oversight, access packages with expiry dates and automatic expiry if a sponsor takes no action. Source: Microsoft Entra guidance on governing agent identities. Most SMEs will not need the full enterprise stack immediately, but the pattern is useful: named identity, named sponsor, time-bound access, review before renewal and automatic loss of access when approval lapses.

What this means in practice: add an inventory check to your release checklist. Before an internal agent goes live, the product owner signs that each tool is needed, each permission is minimal, each high-risk action has an approval gate, logs are available, incidents have an owner and the next review date is set. For help building that operating model, Precise Impact AI can support a practical implementation review focused on your actual workflows, not a generic AI policy. The goal is simple: let useful agents reach production quickly, but only after the business can answer the questions that matter when something goes wrong.

Frequently Asked Questions

What is an agent tool inventory?

It is a live record of every tool, connector, API, data source and action an AI agent can use. It records who owns each tool, why it is enabled, which permissions it has, what approval is required and where activity is logged.

When should we create the inventory?

Create it while the agent is being built and make it mandatory before production. A light record is enough for early exploration, but any agent using live business data or write-capable tools needs a proper inventory before launch.

Who should own the inventory?

The business process owner should own the purpose and risk decisions. A technical owner should maintain configuration, permissions, credentials, logs and disablement routes. In small businesses those roles may sit with the same person, but they should still be named.

Is this only for regulated businesses?

No. Regulated firms have extra pressure, but any organisation connecting agents to CRM, finance, HR, customer support, email, documents or code repositories needs to know what those agents can do.

Does a tool inventory replace a DPIA?

No. If the agent processes high-risk personal data, a DPIA may still be required. The inventory supports the DPIA by showing actual connectors, data flows, permissions, approval gates and logs.

What is the biggest mistake teams make?

The biggest mistake is enabling broad tool access during a pilot and forgetting to narrow it before production. Demo convenience often becomes production risk unless the inventory forces a review.

How often should the inventory be reviewed?

Review it whenever the agent changes tools, permissions, model, data source or workflow. For production agents, set a regular review cycle, with shorter periods for write access, personal data, money movement or customer communications.

Can we use a spreadsheet?

Yes, if it is maintained and tied to release decisions. A spreadsheet is better than no register. As agent use grows, move the inventory into your identity, CMDB, data catalogue, repository or governance tooling.