Shadow Agents: 96% Say They Know Every AI Agent They Run, Two-Thirds Had an Incident — The Registry Is the Missing Artefact
Mohammed Usman is the founder and CEO of Masarrati with 15+ years in product engineering. He has led the development of 10+ production AI, blockchain, and cybersecurity platforms for enterprise clients across UAE, MENA, and Europe.
TL;DR
Guild.ai's Morning Consult survey of 362 IT decision-makers (fielded 4–9 August, published 22 September 2026) finds 96% of organisations run agents in production and 47% run dozens, yet only 42.7% have a central dashboard, 39.8% keep audit trails, 31% have an automated kill switch, and 35.9% require registration before deployment; 60.6% think employees deploy agents without approval and 66.7% had an agent-related incident in the last 12 months. Teams of 20–199 engineers report incidents at 78% versus 43% for the smallest. The same week a UN-backed panel warned that agent safeguards are unravelling. The fix is not another dashboard: it is an owned agent registry with identity, owner, scope, data access, actions and evidence, enforced at deployment. We describe the schema and how to stand it up in a sprint.
Updated September 23, 2026
The confidence gap has a number now. On 22 September Guild.ai published The AI Agent Management Gap, a Morning Consult survey of 362 IT decision-makers at US companies with more than 100 employees, fielded between 4 and 9 August 2026. Its headline pairing: 96.4 percent of respondents are confident their organisation has a complete and accurate inventory of its AI agents, and 66.7 percent of organisations with agents experienced an agent-related operational consequence in the past twelve months.
The rest of the report explains how both can be true. Ninety-six percent of organisations have agents in production and 47 percent run dozens or more. Only 42.7 percent have a centralised dashboard or monitoring tool; 39.8 percent have logging or audit trails; 31 percent can stop a malfunctioning agent with an automated kill switch, though 76.5 percent say they can act within minutes once manual processes are counted. Only 35.9 percent require agents to be registered before deployment, and 60.6 percent think it very or somewhat likely that employees are deploying agents without formal approval. Companies with 20 to 199 engineers report agent incidents at nearly twice the rate of the smallest teams — 78 percent against 43 percent — and 61.2 percent of engineering teams say they lose time rebuilding agents that already exist elsewhere in the organisation.
Two weeks earlier Harness had reported the same shape from 700 engineering leaders — 77 percent confident in their inventory, 44 percent running discovery. Two surveys, two vendors, one finding: enterprises believe they know what is running, and the evidence says they do not.
The governance problem moved
The same day the Guild.ai report landed, AI Agent Store's briefing summarised the first thematic brief from a UN-backed scientific panel on AI, prompted by its investigation of a July breach of Hugging Face by evaluation agents from OpenAI. The panel's conclusion is the one that matters for enterprise architecture: the governance challenge is shifting from AI models to the agents that act on top of them, and preventing a repeat of one incident does not guarantee that increasingly capable agents can be kept reliably under control, since they may adopt their own goals, knowingly violate safety instructions and conceal their activity.
Read those two documents together and the enterprise lesson is not "buy monitoring". Guild.ai's own numbers say the harder problem is not response speed once something is flagged — it is knowing something is wrong in the first place, and knowing which agent did it. Monitoring can only watch what has been declared. The artefact that most organisations are missing is the declaration.
What "shadow agent" actually means
A shadow agent is not necessarily malicious or even unusual. It is an agent that exists outside the record: a Slack bot a team wired to an LLM with a shared API key; a scheduled script that now calls a model and acts on the result; a low-code automation that a business unit connected to the CRM; an evaluation harness in a developer's sandbox with production credentials in its environment. Each is invisible to the control plane, shares a service account with something else, has no owner of record, and — because it was never registered — has no evidence log to reconstruct what it did when the incident review asks.
The 61.2 percent duplicative-work figure is the same problem seen from the cost side. If nobody can see the agents that exist, teams rebuild them.
The registry: a schema, not a dashboard
The control-plane products launched this month — WSO2's open-source Agent Manager, Salesforce's AI Control Plane, Microsoft's Agent 365 arriving in the UAE region in October — all start from a register. The mistake is to wait for the product to populate it. A registry is a small, owned system of record that any of those products can import, and it can be built in one sprint. Each entry needs:
Identity. A unique principal per agent — its own credential, never a shared service account — so a kill switch, a log filter or a permission review can target it alone.
Owner and purpose. A named human owner, the business purpose in one sentence, and the workflow the agent belongs to. Guild.ai found organisations want to know "who owns them"; this is where that lives.
Scope of action. The typed tools the agent may call, each with a risk tier, and the actions that require human approval. Free-form code execution is a scope of "everything" and should be recorded as such.
Data access. Which systems and data classes the agent can read and write, mapped to the residency rule that applies — PDPL personal data, financial records, government data — so a residency review is a query over the registry rather than an investigation.
Model and harness. Which models it may call, through which gateway, and where it runs — hosted sandbox, partner environment or in-region — because model swaps and sandbox choices change both cost and compliance posture.
Evidence pointer. Where the agent's structured event log lives — every tool call with inputs, outputs, reasoning and correlation ID — so incident review starts from the record rather than from interviews.
Lifecycle state. Proposed, approved, running, paused, retired — with the kill switch bound to this field, so "stop" is a state change with an audit entry rather than a hunt for the process.
Enforcing it: registration as a deployment gate
A registry that is optional produces the 35.9 percent figure. The enforcement pattern that works is the one platform teams already use for services: no agent credential is issued without a registry entry, the model gateway rejects calls from unregistered principals, and the CI pipeline for anything that calls a model checks for a registry ID the way it checks for a service owner. Discovery tooling then has a specific job — finding calls to model endpoints that carry no registered identity — rather than the impossible one of finding "all agents".
For organisations in the UAE and the wider Gulf the timing matters. Dubai's push toward agentic public services means government-adjacent enterprises will be asked to demonstrate agent governance early, and a registry is the artefact that demonstrates it: it is the answer to "what agents do you run, who owns them, what can they touch, and how do you stop one" in a single export.
Where Masarrati fits
Masarrati builds AI agent systems and multi-agent platforms with the registry entry created before the first line of agent code: per-agent identity, typed tool contracts with risk tiers, a structured evidence log and lifecycle states bound to a kill switch. For enterprises that already run agents, we deliver the registry and the gateway enforcement as a standalone engagement — a sprint to inventory what exists, register it, and turn discovery into an exception report — and our GRC automation work keeps the registry and the evidence in the form auditors ask for. We build and hand over; your team owns the registry and operates the agents, on whichever control plane you choose. Our earlier piece on what to build before buying a control plane covers the governance surface each agent needs to expose; this one is about the record that ties them together.