Why AI agents need a CMDB, and what one actually looks like

The IT asset that has no system of record#

Every enterprise has a Configuration Management Database. It tracks every server, every network switch, every virtual machine and every container running in the environment. When a server goes down at 2 AM, the CMDB tells the on-call engineer what depends on it, who owns it and what services are affected. When an auditor asks for a complete inventory of production infrastructure, the CMDB generates the report.

The global CMDB software market was valued at $2.1 billion in 2024 and is expected to reach $6.9 billion by 2033. Large enterprises account for over 65% of that spend. The reason is simple: you cannot manage what you cannot see, and you cannot secure what you haven’t inventoried.

Now consider AI agents. According to Gravitee’s State of AI Agent Security 2026 report, more than 3 million AI agents are now operating within corporations. Only 47.1% are actively monitored or secured. That leaves an estimated 1.5 million agents running without oversight, accessing sensitive data, making decisions and connecting to critical systems with no audit trail and no inventory.

The hidden cost of this sprawl spans five dimensions:

• Token waste
• Infrastructure bloat
• Silent error cascading
• Governance overhead
• Regulatory exposure

Your servers have a CMDB. Your SaaS subscriptions have a management platform. Your cloud resources have a dashboard. Your AI agents have a shared spreadsheet that was last updated three weeks ago. Maybe a Slack channel. Maybe nothing.

This is the gap this article is about: why AI agents need a system of record with the same rigor and depth as your CMDB, what that system must track, how it integrates with your existing infrastructure and what happens when you don’t have one.

---

The 2026 inflection: from “can agents code?” to “can agents navigate my infrastructure?”#

The industry conversation has shifted. In 2024, the question was whether AI agents could perform useful work. In 2026, the question is whether they can operate safely within your specific infrastructure: your APIs, your data stores, your compliance boundaries, your cost constraints. The bottleneck is no longer the LLM. It’s the lack of a structured source of truth that agents can reason about.

Gartner’s February 2026 ThinkCast episode, IT Operations Are Not Ready for AI Agents: How to Respond Today, makes the case explicitly: I&O teams must shift from scripts and CLI to policy definition and workflow orchestration, because agents need structured context to act safely. Without it, they operate on what we call hallucinated topology: the agent’s best guess about infrastructure that it has never been given a verified map of.

The numbers back this up. Gartner predicts that over 40% of agentic AI projects will be canceled by end of 2027 due to escalating costs, unclear business value or inadequate risk controls. At the same time, 70% of enterprises will deploy agentic AI as part of IT infrastructure operations by 2029, up from less than 5% in 2025. The gap between these two predictions (massive adoption, massive failure rate) is the governance gap. The enterprises that close it will be the ones that give their agents a real system of record, not a hallucinated one.

The CNCF’s January 2026 forecast on the autonomous enterprise and the four pillars of platform control reinforces this from the infrastructure side. Four control mechanisms define whether agents can operate autonomously:

• Golden paths
• Guardrails
• Safety nets
• Manual review workflows

All four require structured data about what agents exist, what they’re allowed to do and what infrastructure they touch. That’s a registry.

---

The CMDB analogy: why it’s more than a metaphor#

A Configuration Management Database isn’t just an inventory list. In ITIL terms, the CMDB is a repository that stores information about configuration items (CIs): the components of your IT environment and, critically, the relationships between them. When a CMDB is functioning well, it answers three questions instantly: What do we have? How is it connected? Who is responsible?

AI agents are configuration items. They consume infrastructure resources while connecting to data sources and external APIs; they have owners (or should). They have lifecycles: created, deployed, modified and eventually retired. They interact with other systems and, increasingly, with each other. They carry risk that varies by what data they access and what actions they can perform.

By every meaningful definition, AI agents are IT assets.

But only 21.9% of organizations currently treat AI agents as independent, identity-bearing entities. The rest manage agents like software tools, which misses the fundamental difference: agents act autonomously. They don’t wait for a human to press a button. They:

• Invoke APIs
• Query databases
• Execute code
• Trigger workflows

A software tool sits in a repository until someone runs it. An agent runs itself.

The CMDB analogy is an architectural argument. The same disciplines that made IT infrastructure manageable are exactly what AI agents need:

• Centralized inventory
• Dependency mapping
• Lifecycle tracking
• Ownership assignment
• Change detection

The consequences of not having them are also the same: uncontrolled sprawl, invisible dependencies, orphaned assets and audit failures.

---

What a CMDB tracks vs. what an agent registry must track#

A traditional CMDB tracks configuration items across a standard set of attributes. For a server, that typically includes hostname, IP address, operating system, hardware specifications, physical or virtual location, owner, support group, deployment environment and the services it supports. The CMDB also maps relationships: this server hosts this application, which depends on this database, which connects to this network segment.

An agent registry needs all of that conceptual coverage, adapted for a fundamentally different kind of asset. Here’s what changes.

Attribute	Traditional CMDB (server)	Agent registry (AI agent)
Identity	Hostname, IP, MAC address	Unique ID, name, version, description, slug
Technical stack	OS, hardware, hypervisor	Framework, model provider, model version, prompt config
Ownership	Owner, support group	Owner, sponsor, team, escalation chain
Classification	Asset type, environment	Risk tier (data sensitivity, decision authority, blast radius)
Connections	Network segment, dependencies	Model APIs, data sources, tools, other agents
Lifecycle	Provisioned, active, decommissioned	Draft, development, testing, staging, production, retired
Compliance	N/A (infrastructure-level)	Per-agent certification against GDPR, SOC 2, EU AI Act
Behavioral state	Static configuration	Dynamic: model updates change behavior without code changes
Change detection	Config drift (manual scan)	Continuous drift detection (every 15 minutes)

Identity and metadata. Every agent needs a unique identifier, a human-readable name, a version number and a description of what it does. Unlike a server (whose function is evident from its hostname and network role), an agent’s purpose is defined by its prompt, its tool configuration and its behavioral boundaries. The registry must capture all of this.

Technical stack. Which framework was this agent built on? LangGraph, CrewAI, AutoGen, Microsoft Copilot Studio, a custom Python script? Which model does it use? Claude, GPT-4, Llama, a fine-tuned variant? Which model version, specifically? This matters because model updates change agent behavior, a governance concern that has no equivalent in traditional infrastructure.

Ownership and accountability. Every server in a CMDB has an owner. Every agent in a registry needs one too, but with an additional layer. Microsoft’s Entra Agent ID framework introduces the concept of “sponsors” for agent identities: human users who are accountable for making decisions about the agent’s lifecycle and access.

When the developer who built an agent leaves the organization, the registry must flag the orphaned agent immediately. This isn’t optional. Orphaned agents with stale permissions are one of the most common vectors for security incidents.

Data access and classification. What data does this agent access? Public information? Internal business data? Customer PII? Financial records? Protected health information?

The data sensitivity classification determines the agent’s risk tier and its governance requirements.

The EU AI Act Article 11 requires technical documentation that includes a description of the data the system processes. This is a compliance requirement, not just a best practice.

Decision authority. What actions can this agent take?

• Read information and generate recommendations?
• Write to databases?
• Send external communications?
• Execute financial transactions?

A read-only knowledge-base agent and a trading agent that executes orders autonomously are both “AI agents,” but they carry radically different risk profiles. The registry must capture this distinction with precision.

Tool access and permissions. Modern agents don’t just process language. They invoke APIs, browse the web, execute code and interact with other agents. Each tool an agent can access is a new risk surface. The OWASP Top 10 for Agentic Applications (2026) identifies tool misuse as a top-tier risk specific to agents. The registry must enumerate every tool, API and system integration an agent has access to and enforce least-privilege principles.

Lifecycle state. Where is this agent in its lifecycle? Still in development, under testing, deployed to staging, running in production, deprecated or retired?

A traditional CMDB tracks lifecycle states for servers and applications. An agent registry must do the same and enforce gates between states. A high-risk agent should not reach production without active certification.

Dependencies. This is where the graph dimension of a CMDB becomes critical. Agents depend on model providers, data sources, external APIs and increasingly on other agents. When an upstream model provider has an outage, which agents are affected? When a data source changes its schema, which agents break? When one agent in a multi-agent workflow fails, what cascades? Without dependency mapping, these questions are unanswerable.

Compliance and certification status. No equivalent exists in a traditional CMDB because servers don’t need to be individually certified against GDPR or SOC 2. Agents do. The registry must track which compliance frameworks apply to each agent, the current certification status, when the certification expires and what evidence has been submitted.

---

The architecture of an agent registry#

An agent registry has specific architectural requirements that distinguish it from both traditional CMDBs and general-purpose asset management tools.

A live, queryable registry, not a static document. The registry must be the authoritative source of truth, updated in real time as agents are deployed, modified and retired. It must support semantic search (finding agents by describing what they do in natural language) because in an estate of hundreds of agents, keyword-based search breaks down quickly.

TrueFoundry’s AI Agent Registry architecture uses vector embeddings to enable this kind of discovery, treating agents as searchable capability endpoints.

Automated discovery, not just manual registration. Manual registration is necessary but insufficient. Teams deploy agents without telling IT. 29% of employees admitted to using unsanctioned AI agents at work, according to Microsoft’s Cyber Pulse report.

The registry needs automated discovery mechanisms:

• Webhook connectors that receive deployment events from CI/CD pipelines
• API interceptors that detect new agents calling LLM providers
• Integration with identity platforms that register agent identities at creation time

Microsoft is building this into the identity layer with Entra Agent ID, which automatically surfaces agents created in Copilot Studio or Azure AI Foundry in the Entra admin center. But most enterprises have agents built across five or more platforms, not just Microsoft’s. The registry must be framework-agnostic, discovering and cataloging agents regardless of where they were built.

A dependency graph, not just a flat list. An inventory without relationships is a list. A CMDB without relationships is just a spreadsheet with a database behind it. The defining characteristic of a real CMDB is the relationship layer. An agent registry needs the same.

Agents connect to model providers, data sources, external APIs, internal services and other agents. These connections must be mapped, visualized and monitored.

This matters operationally:

• When a model provider updates its API, which agents are affected?
• When a data source goes offline, which workflows break?
• When an agent’s classification changes from medium-risk to high-risk (because someone gave it access to customer data), do the downstream agents that depend on it also need reclassification?

The dependency graph answers all of these questions. Without it, you’re managing agents in isolation. That’s how incidents cascade.

Risk classification as a first-class attribute. Traditional CMDBs classify assets by type (server, network device, application) and environment (development, staging, production). An agent registry must classify by risk. Risk is multi-dimensional. As we outlined in the Roval AI Agent Governance Framework, risk classification should span at least three dimensions: data sensitivity, decision authority and blast radius.

The registry must compute a composite risk tier for every agent and use that tier to drive governance decisions downstream: what level of oversight applies, what certification is required and whether the agent is allowed to operate in production at all.

Immutable audit trail. Every change to every agent record (registration, classification, reclassification, certification, configuration change, ownership transfer, status transition) must be logged in an append-only audit trail with the actor, the timestamp and the before-and-after state. This is not optional for enterprises subject to the EU AI Act, which requires automatic recording of events for high-risk AI systems under Article 12.

Even without regulatory pressure, the audit trail is what makes the registry trustworthy. If an engineer can silently change an agent’s risk classification from high to low without anyone noticing, the registry isn’t governing anything.

Integration with existing enterprise systems. The agent registry doesn’t exist in a vacuum. It must integrate with the enterprise’s existing stack:

• The CMDB (for infrastructure dependencies)
• The SIEM (for security event correlation)
• The identity provider (for ownership and access management)
• The GRC platform (for compliance evidence)
• The CI/CD pipeline (for deployment-time gates)

An agent registry that requires a team to manually cross-reference three other systems for every agent is an agent registry that won’t be used.

The hallucinated topology problem. Without a registry, an agent reasons about infrastructure it has never been given a verified map of. It assumes API endpoints are stable. It assumes data sources are available. It assumes permissions haven’t changed. This is hallucinated topology: the agent’s mental model of the environment diverging from reality.

The CNCF’s March 2026 cloud-native agentic standards document addresses this directly: it recommends service registries for agent and tool discovery, GitOps-based orchestration for agent workflows and custom Kubernetes watchers to monitor critical resources like model providers. Structured data from a registry provides the context window necessary for high-stakes decision-making. Without it, agents move from “executing with confidence” to “guessing with consequences.”

ServiceNow recognized this early. Their AI Control Tower uses the CMDB as the AI inventory data model, treating it as the system of record where both ServiceNow and third-party agents are registered and discovered. Their Knowledge 2025 session walks through how this works in practice: centralized visibility across ServiceNow and third-party agents, risk scoring and compliance tracking on a single pane. The principle is sound: agents need a verified source of truth, not a hallucinated one.

---

What happens without an agent registry: a Nordic case study#

Consider a hypothetical but realistic scenario. A Nordic pension fund with EUR 80 billion in assets under management and 1,200 employees begins deploying AI agents in late 2024. The initiative starts small: a few agents for internal knowledge retrieval, a couple for summarizing regulatory documents, one for drafting portfolio commentary.

By mid-2025, adoption accelerates:

• The quantitative research team builds agents for factor analysis and signal generation.
• The operations team deploys agents for trade settlement exception handling.
• The compliance team experiments with agents for AML transaction monitoring.
• The client services team rolls out an agent for answering client queries about NAV calculations and fund performance.

By early 2026, the fund has, by the best estimate of its CTO, somewhere between 35 and 60 AI agents running across the organization. The actual number is higher, because three teams deployed agents directly to cloud environments without going through IT.

Then several things happen in rapid succession.

The orphaned agent. A developer in the quant team leaves the fund. Three months later, IT discovers that an agent he built (one that processes dividend data from custodian feeds and has read access to the fund’s entire position database) is still running. Nobody knows exactly what it does. The documentation is a README file with four bullet points. The agent has been making API calls to a model provider that the fund never approved.

The compliance request. The fund receives a request from the Norwegian Financial Supervisory Authority (Finanstilsynet) regarding its use of AI systems, following the EU AI Act’s upcoming enforcement. The compliance officer needs to produce a list of all AI agents, their risk classifications, what data they access and who is accountable for each one.

The CTO opens the shared spreadsheet that was supposed to track this. It lists 22 agents. It was last updated four months ago. Six of the listed agents have since been retired. Fourteen running agents aren’t listed at all.

The cascading failure. The operations team’s settlement exception agent depends on an internal API that another team’s agent also calls. A configuration change to that API’s authentication mechanism (made for security purposes) breaks both agents simultaneously. The operations team notices within hours because settlements start failing. The other team doesn’t notice for a week because their agent fails silently, writing incorrect data to a reporting database.

The cost discovery. A quarterly infrastructure review reveals that LLM API costs have tripled in six months. Nobody can explain why. Without a registry that tracks which agents make which API calls with what frequency, there’s no way to attribute costs to specific agents, teams or use cases. The EUR 40,000-per-month bill turns out to be a testing agent that someone forgot to shut down after a proof of concept.

None of these scenarios are exotic. They are the predictable consequences of running dozens of autonomous AI agents without a centralized system of record. Every enterprise with meaningful agent adoption will encounter some version of each. The only question is when and how much it costs. For a structured checklist of these governance blind spots, see the ten questions every CTO should be able to answer about their AI agents.

---

---

Why your existing CMDB isn’t enough#

The natural instinct is to extend the existing CMDB. Just add “AI agent” as a new configuration item class in ServiceNow, map the attributes and call it done.

This approach gets you further than a spreadsheet, but it falls short in three critical ways.

CMDBs don’t model agent-specific attributes. A CMDB can track that an asset called “settlement-agent-v3” exists, who owns it and what infrastructure it runs on. It cannot track:

• The agent’s risk classification across four dimensions
• Its current certification status against GDPR and SOC 2
• Whether its certification has expired
• What LLM model it uses (and whether that model has been updated since certification)
• What prompts it sends and what tools it can invoke

These are agent-specific attributes that require purpose-built data models.

CMDBs don’t enforce lifecycle gates. A CMDB records the lifecycle state of an asset. It does not prevent an uncertified high-risk agent from reaching production. Agent governance requires enforcement: hard blocks, not just labels. When a Tier 3 agent sitting in staging tries to promote to production without an active compliance certification, the system needs to block the transition and explain why. This is policy-as-code enforcement, not configuration management.

CMDBs don’t detect behavioral drift. A server’s configuration doesn’t change by itself. An agent’s behavior does, because the underlying model updates, the data distribution shifts or the business context evolves. Drift detection (flagging when an agent’s behavior deviates from its certified baseline, when a certification is about to expire or when an owner has departed) requires continuous monitoring that runs on a cadence measured in minutes, not months. Traditional CMDBs are designed for configuration state, not behavioral state.

Capability	Traditional CMDB	Agent registry
Asset inventory	Yes	Yes
Ownership tracking	Yes	Yes + sponsor model
Dependency mapping	Yes	Yes + agent-to-agent
Risk classification	Basic (type/environment)	Multi-dimensional (data, authority, blast radius)
Compliance certification	No	Per-agent, per-framework, with auto-expiry
Lifecycle gate enforcement	No	Blocks uncertified agents from production
Behavioral drift detection	No	Continuous (every 15 min)
LLM request monitoring	No	Full prompt capture + policy analysis
Semantic search	No	Vector-based natural language search
Audit trail	Limited	Immutable, append-only, every state change

This is why an agent registry is a distinct system, not a tab in ServiceNow. It complements the CMDB (and should integrate with it for infrastructure dependencies), but it governs a layer that the CMDB was never designed to see. ServiceNow’s own AI Control Tower demo illustrates the gap: even with the CMDB as the underlying data model, they had to build an entirely new governance layer on top for risk scoring, compliance status and agent lifecycle management.

---

Build vs. buy: the decision framework#

Every enterprise facing the agent registry question will evaluate whether to build it internally or adopt a purpose-built platform. Here’s how to think about it.

The build case. If you have a small number of agents (under 20), all built on one framework, managed by a single team and subject to a single compliance framework, you can likely track them in a well-maintained internal tool: a purpose-built database application with a basic UI, an API for automated registration and a manual certification workflow. The build cost is moderate. The maintenance burden is manageable as long as the agent estate stays small.

Where building breaks down. It breaks down at three inflection points:

• Scale. When the agent estate crosses roughly 50 agents and spans multiple frameworks and teams, the internal tool needs multi-tenancy, role-based access control and automated discovery.
• Compliance complexity. When you need GDPR, SOC 2, EU AI Act and internal policies, each with different evidence requirements per risk tier, you’re suddenly building a compliance management system inside your agent registry.
• Continuous monitoring. When you need drift detection: a background process that runs every 15 minutes, checks certifications against expiry dates, detects configuration changes and flags orphaned agents.

At that third inflection point, you’re not maintaining a database application anymore. You’re operating a governance platform.

The buy case. A purpose-built agent registry (what we at Roval call the enterprise system of record for AI agents) provides the registry, risk classification, compliance certification, drift detection and audit trail in a single platform. It ships with built-in compliance frameworks (GDPR, SOC 2, EU AI Act). It auto-discovers agents via webhook connectors. It enforces production gates: high-risk agents cannot reach production without active certification. It captures every LLM request through a transparent proxy with under 1ms of overhead. It detects drift every 15 minutes and alerts when certifications expire, configurations change or owners depart.

The economic argument is straightforward. Building and maintaining an internal agent registry that covers all of these capabilities will cost two to three engineering headcount in perpetuity. A purpose-built platform costs a fraction of that and ships with the compliance frameworks, discovery mechanisms and drift detection that take months to build internally.

---

How Roval implements the agent registry#

Roval is the enterprise system of record for AI agents. The agent registry is the foundation of the platform: the equivalent of the CMDB, but purpose-built for AI agents with the risk classification, compliance certification and continuous monitoring that agents require.

Registration in under two minutes. Add an agent to the registry with its name, description, framework, model provider, model version, owning team, deployment URL and tags. Agent slugs are unique per organization. Every agent starts in Draft status.

Four-dimension risk classification. Classify every agent across data sensitivity (public / internal / confidential / restricted), decision authority (recommend only / act with approval / autonomous), blast radius (individual / team / organization / external) and regulatory exposure. The system computes a composite risk tier (1 through 4) with a numeric score. Configurable weights per organization. Auto-classification available with per-dimension reasoning for human review.

Enforced lifecycle management. Every agent follows a governed state machine: Draft, In Development, Testing, Staging, Production, Deprecated, Retired. Invalid transitions are blocked. Tier 3 and above agents cannot reach Production without an active, non-expired compliance certification. Every status transition is recorded in an immutable audit log.

Live dependency graph. Map how agents connect to model providers, data sources, external APIs and other agents. Open the org-wide graph to see nodes color-coded by risk tier, connected by directed edges. Multiple users can review the graph simultaneously with shared cursor positions.

Automated discovery via connectors. Configure webhook connectors to receive events from CI/CD pipelines, orchestration platforms and deployment tools. New agents are auto-registered as Draft. Existing agents are updated, not duplicated. When a connector detects a change to a previously certified agent, a drift event is created automatically.

Semantic search. Every agent description is embedded as a vector. Search by natural language query and get results ranked by semantic similarity. When you have 200 agents, you need to find them by what they do, not just what they’re called.

Continuous certification and drift detection. Certify agents against GDPR, SOC 2, EU AI Act or custom internal policies. Upload evidence per requirement. Auto-expiry by risk tier: 90 days for Critical (Tier 4), 180 days for High (Tier 3), 365 days for Tiers 1-2. A drift detector runs every 15 minutes and flags expiring certifications, configuration changes and owner departures.

LLM request monitoring. A transparent Go proxy that captures every prompt sent to every LLM API with under 1ms of overhead and a fail-open design that never breaks a developer’s workflow. Full prompt capture, policy compliance analysis within 30 seconds and threat detection for data exfiltration patterns and anomalous volume. One environment variable to install.

Audit trail for any auditor. Every state-changing operation recorded with actor, timestamp and before-and-after snapshots. Exportable as CSV or JSON, filtered by resource, actor, action or date range. The platform dashboard surfaces all of this on a single screen.

---

Getting started: the 30-day agent inventory sprint#

You don’t need a perfect system to start. You need to know what you have. A centralized agent inventory is the starting point. Here’s a practical approach for the first 30 days.

Week	Focus	Deliverable
1	Manual discovery	Survey every team lead and business unit head for agent lists
2	Infrastructure telemetry	Cross-reference API gateway logs for LLM provider calls; find unreported agents
3	Build initial registry	Minimum viable attributes per agent: name, owner, team, framework, model, data access, decision authority, risk tier
4	Assess and act	Prioritize high-risk agents for certification; flag orphaned agents for decommissioning; present baseline to leadership

Week 1: Manual discovery. Send a survey to every engineering team lead and business unit head: “List every AI agent your team has deployed, tested or is actively developing.” You’ll get an incomplete list. That’s fine. It’s a starting point.

Week 2: Infrastructure telemetry. Check your API gateway logs. Which endpoints are calling OpenAI, Anthropic or other LLM providers? Cross-reference with the manual list. You’ll find agents nobody reported. Check cloud resource tags for anything labeled “agent,” “assistant” or “bot.”

Week 3: Build the initial registry. For every discovered agent, capture the minimum viable attributes: name, owner, team, framework, model, data access, decision authority and deployment environment. Assign a provisional risk tier. Flag any agent with no identifiable owner.

Week 4: Assess and act. Identify the highest-risk agents: those accessing sensitive data or executing autonomous actions. Prioritize these for full classification and certification. Identify orphaned agents and assign temporary owners or mark for decommissioning. Present the results to leadership as the baseline for your agent governance program.

This 30-day sprint won’t give you a perfect registry. But it will give you something most enterprises don’t have: a defensible answer to the question “How many AI agents do we have?”

And then you can start governing them.

---

Sources and further reading#

Source	Link
Gravitee, State of AI Agent Security 2026	gravitee.io
Bessemer Venture Partners, Securing AI Agents: The Defining Cybersecurity Challenge of 2026	bvp.com
Microsoft Security Blog, Secure Agentic AI End-to-End	microsoft.com
Microsoft Entra Agent ID Documentation	learn.microsoft.com
Microsoft Entra Agent ID Governance	learn.microsoft.com
CMDB Software Market Report (DataIntelo)	dataintelo.com
Gartner, 40% of Enterprise Apps Will Feature AI Agents by 2026	gartner.com
Forrester, Predictions 2026: AI Agents, Changing Business Models	forrester.com
TrueFoundry, AI Agent Registry Architecture	truefoundry.com
Beam.ai, AI Agent Sprawl: The New Shadow IT	beam.ai
Cloud Latitude, The Dark Side of Autonomy: Agentic AI Orphan Security Risks	cloudlatitude.com
OWASP Top 10 for Agentic Applications (2026)	owasp.org
EU AI Act, Article 11 (Technical Documentation)	artificialintelligenceact.eu
EU AI Act, Article 12 (Record-keeping)	artificialintelligenceact.eu
Gartner, Over 40% of Agentic AI Projects Will Be Canceled by End of 2027	gartner.com
Gartner, Predicts 2026: AI Agents in IT Infrastructure and Operations	gartner.com
Gartner ThinkCast, IT Operations Are Not Ready for AI Agents (Feb 2026)	gartner.com
CNCF, The Autonomous Enterprise and Four Pillars of Platform Control (Jan 2026)	cncf.io
CNCF, Cloud Native Agentic Standards (Mar 2026)	cncf.io
ServiceNow AI Control Tower	servicenow.com
ServiceNow, Governing AI at Scale — Welcome to AI Control Tower (video)	youtube.com
ServiceNow, AI Control Tower Demo: Managing AI Risk, Compliance & Performance (video)	youtube.com
Roval, The AI Agent Governance Framework (8 Pillars)	roval.ai