The next enterprise AI failure may be neither hallucination, hack nor outage. It may be quieter: an agent, an MCP server or a skill that somebody connected six months ago, nobody owns today, and nobody can confidently describe. It still has access to a CRM, a document store, a ticketing system or a payment-adjacent workflow.
AWS published general-availability guidance for its Agent Registry on 31 August. The point is not that one cloud provider has a registry. It is that it names the operational problem accurately. Once teams build agents and tools in isolation, organisations lose their inventory, duplicate work and struggle to prove which capability was reviewed, by whom, against which version and for what access.
That pattern is bigger than AWS. Agent builders are connecting models to CRM records, support systems, knowledge bases, messaging platforms and internal APIs through MCP and similar interfaces. TechCrunch’s reporting on Clipto is an adjacent signal: assistants are increasingly being given access to large collections of document data, with user-authorised scope becoming part of the product design. The question is whether the company has a control layer before it does.
Inventory comes before autonomy
Every mature security programme begins by knowing what exists: devices, identities, applications, data stores and privileged connections. Agentic AI needs the same discipline. An AI agent is not merely a model. It is a package of instructions, model routes, context, tools, credentials, memory, triggers, approvals and a runtime that can take one or more actions. An MCP server is not merely an integration. It is a new capability surface that can make data or an action discoverable to a compatible client.
If those components are tracked only in chat threads, browser settings, a developer laptop or a vendor dashboard, leadership does not have an agent programme. It has a collection of exceptions. The apparently small omissions matter. A decommissioned employee’s tool credential, an unreviewed calendar connector or a forgotten test environment can become the path through which an otherwise sensible assistant sees too much or does too much.
A registry is necessary. It is not the whole control plane.
AWS describes two useful ideas: a governance plane that holds the full record of resources and their lifecycle, and a curated discovery plane that exposes only approved capabilities. Its Registry can catalogue MCP servers, Agent2Agent agents, skills and custom resources; it can connect publishing to approval hooks, access controls and audit logging. That is a sensible operating pattern.
But no vendor catalogue can by itself make a deployment safe. A reliable enterprise control plane also needs workload-level identity, least privilege, data classification, evaluation evidence, logging, rate and spend limits, human approval for consequential actions, incident response and a tested way to revoke access. A registry tells you what is supposed to exist. Runtime controls tell you whether it is behaving within its authority.
This distinction matters particularly for a multi-cloud, private or sovereign organisation. AWS’s auto-detection is valuable for selected AWS AgentCore environments, but it is not a universal scan of every SaaS workspace, laptop, model provider or private deployment. The right objective is vendor-neutral visibility: a single inventory and policy model that can reference every environment, while respecting the isolation requirements of each region, business unit and regulated workload.
The four records I would require for every production capability
The inventory should be useful to operations, security, legal and the business owner—not an architecture diagram that nobody updates. I would require one short, machine-readable record for every agent, tool, skill and MCP endpoint. It should exist before production access is granted and change through the same delivery workflow as the code or configuration.
- Identity and owner: a named accountable business owner, technical owner, service identity and escalation route.
- Purpose and authority: the job it may perform, prohibited actions, human approval thresholds and the systems it may call.
- Data and geography: data classes, retention, model/provider route, processing region and whether private, sovereign or air-gapped execution is required.
- Evidence and lifecycle: version, evaluation result, security review, approval date, cost centre, monitoring location, renewal date and kill-switch or retirement procedure.
The discipline has a commercial upside as well. A searchable catalogue prevents three teams from building three slightly different lead-qualification agents, customer-service connectors or document extractors. Reuse works only when the approved capability is understandable, discoverable and trusted. Otherwise every team rebuilds, every integration creates a new risk path, and the AI programme becomes more expensive as it grows.
MCP changes the review process—not the need for one
Open standards are useful because they reduce one-off integration work. They also make it easier for an agent to discover capabilities dynamically. That is exactly why the review needs to move upstream. Before an MCP endpoint is approved, verify its publisher, transport security, authentication method, scopes, tool descriptions, data outputs, side effects, logging and revocation path. Treat a tool that can create, update, send, delete or approve as a privileged integration, even when a chat interface makes it feel casual.
NIST’s AI Risk Management Framework remains a useful discipline here: govern the programme, map the context, measure the risks and manage them continuously. For agentic systems, that translates into a recurring control loop. The inventory discovers the surface. Evaluations test the intended and prohibited behaviours. Runtime observability reveals what actually happened. A human owner decides when to expand, pause or retire authority.
This is also why I do not recommend a public WebMCP surface for administration, publishing, billing or sensitive-data access. Discovery should be bounded; action should be authenticated, scoped and approval-gated. Shofield AI’s own WebMCP surface is read-only for this reason.
The 30-day cleanup every leadership team can start now
Week one: stop new production agent connections that cannot name an owner and an approved purpose. Inventory agents, MCP servers, API keys, automation platforms, browser extensions and model-provider projects already touching company data. Week two: classify each item by data sensitivity and action authority, then remove abandoned credentials and duplicate experiments.
Week three: choose the highest-value workflow—sales follow-up, service triage, patient access, finance operations or knowledge support—and run a permission and failure review. Test how the agent behaves with stale information, a malformed tool response, an unexpected request and a revoked credential. Week four: publish the approved catalogue, designate curators and give executives a short monthly view of new, changed, rejected and retired capabilities.
The aim is not to slow down adoption. It is to make safe reuse faster than uncontrolled experimentation. Teams should be able to find an approved connector or AI Employee in minutes, understand its authority and deploy it through a repeatable path. That is how governance becomes an accelerator rather than a presentation for the audit committee.
My view: agent sprawl is now a board-level operating risk
The companies that benefit most from AI will not be the ones with the longest list of agents. They will be the ones that can safely give the right agent the right job, then prove what it accessed, why it acted and how to stop it. That is the difference between an impressive pilot and a dependable operating capability.
At Shofield AI, our AI Employees, Model Gateway, Company Brain, agent runtime and Mission Command are designed as connected layers: one place to understand the workflow, control identities and permissions, evaluate performance, monitor behaviour and preserve human authority. We can work with existing systems and providers; the goal is not to force a platform replacement. It is to turn fragmented AI experiments into a governed production estate.
If you cannot list an agent, identify its owner and revoke its authority, you have not deployed automation. You have created unmanaged operational access.
If your organisation is already connecting agents to customer, employee or operational systems, now is the time to establish the inventory and governance layer. Shofield AI can map the existing landscape, identify the highest-risk gaps and design the controls that let useful autonomous workflows scale with confidence.