Just In
Ideas2IT is now an OpenAI Select Partner - recognized to help enterprises build, deploy, and scale AI with GPT-5, responsibly and at speed.
Read the announcement
If you own an estate of 20 or more agents, here's what to take from this article before your next agent ships.
An enterprise AI agent stack is only as governable as the shared layer underneath its agents. When 20 teams build agents separately, you get 20 paths into your systems, each with its own credentials and tool connections. Controlling agent sprawl comes down to deciding what moves into that shared layer and what stays with the teams building agents.
Someone in security asks a reasonable question: which of your agents can write to the CRM, and under whose credentials? You have more than 20 agents in production, and each team built its own. Each one reached the CRM its own way. The only way to answer is to open every repository and ask every team what they provisioned. That's the week agent sprawl lands on your desk as an architecture problem.
The question gets harder every quarter. KPMG's Q2 2026 AI Quarterly Pulse surveyed US organizations with $1 billion or more in revenue. Agent deployment held roughly flat at 53 percent, while the share orchestrating multiple agents across workflows doubled from 9 to 18 percent. Your agents are starting to call each other and share systems, and each one carries whatever access its team gave it.
The scale ahead makes the gap wider. Gartner expects the average Fortune 500 enterprise to have more than 150,000 agents in use by 2028, up from fewer than 15 in 2025. It also reports that only 13 percent of organizations believe they have the right agent governance in place today.
More policy won't close that gap, because a policy can only be enforced where agents pass through something shared. The decision in front of you is about the architecture of your enterprise AI agent stack: which capabilities move into one shared agent layer, and which stay with the teams building agents. The first step toward that decision is seeing what each team rebuilt.
Seeing that duplication starts with a single launch, so take a hypothetical but familiar case. A team plans to ship its next agent next sprint, and it needs read access to the CRM and a connector to the ticketing system. Four agents in your estate already have both, each built differently. None of that work transfers to the new agent. So the new team builds it a fifth time, with a new service account and a new API key.
Repeat that at every launch and the pattern becomes structural. OutSystems' 2026 State of AI Development report, a survey of about 1,900 IT leaders, found that 38 percent of organizations mix custom-built and pre-built agents in stacks that are hard to standardize and secure. It also found that 94 percent are concerned that sprawl is adding technical debt and security risk.
When independent teams build agents one at a time, each agent ends up carrying its own copy of the same six capabilities. Each copy is a path into your systems that works on its own and that nobody reviews alongside the others.
Each launch adds another row of copies to that table, and each copy stays in production until someone finds it.
You are running agents that different teams built, and the credentials behind them live wherever each team put them. Until you can see every agent next to the access it holds, every other decision about agent sprawl rests on guesswork. An agent inventory review gives you:
Request an Agent Inventory Review
The table shows six capabilities copied across your estate. The fix is deciding where each one belongs. Two questions settle it. Does every agent need this capability to behave identically? Would a security reviewer ask about it? A yes to either puts the capability in the shared layer.
Those questions match where Gartner's April 2026 guidance on agent sprawl starts. Gartner recommends rules on which connectors are permitted and a clear model for agent identity and permissions, including retiring redundant agents. The shared layer is where those rules run on every call.
Two capabilities split down the middle. Memory infrastructure belongs in the shared layer, so every vector store is inventoried and access-controlled the same way. Each agent's memory contents still stay scoped to that agent. A tool built for one agent still gets registered centrally, so it passes the same identity and access checks as every other tool. Its owning team keeps maintaining it.
The model gateway is also where cost control becomes enforceable. Token budgets enforced at the model gateway apply to every agent without each team writing its own metering.
Identity and tool access carry the most risk in that table, and they are where an estate built team by team drifts furthest from the split.
Identity and tool access decide whether you can answer the CRM question from one place, so both parts of AI agent access control belong in the shared layer.
An agent that runs on a borrowed user token or a shared service account inherits every permission attached to it. The OWASP GenAI Security Project's 2025 Top 10 for Agentic Applications lists identity and privilege abuse as its own risk category. It cites incidents where leaked credentials let agents act well beyond their intended scope.
Your identity program wasn't designed for agents. CyberArk's 2025 Identity Security Landscape, based on 2,600 security decision makers, found that machine identities outnumber human ones 82 to 1, and nearly half of them hold sensitive or privileged access. Every agent you ship adds to that count.
In the shared layer, AI agent identity management starts at registration, when every agent gets its own identity. Credentials are issued per agent and per tool, scoped to what that agent does. They expire quickly and are revoked when the agent retires. No team stores keys in its own repository, because no team issues them.
Identity tells you which agent is acting, and tool access decides what it can reach. The Model Context Protocol specification makes authorization optional. Servers running over the STDIO transport are expected to pull credentials from their environment. When several teams each stand up an MCP server in front of the same CRM, one system can end up with several authorization models.
A central tool registry holds every tool and connector, including MCP servers. It records which agents may call each one, and at what scope. The access trail on that same path records which agent used which tool, under whose authority. When security asks the CRM question again, the answer comes from one query.
You can describe your agent estate, but you can't yet show which agents are able to write to your most sensitive systems. That gap is where an agent with inherited access does damage before anyone notices. An access-map working session on your highest-risk systems produces:
Book an Access-Map Session
Once the shared layer holds identity and tool access, the next temptation is to let it hold everything. A central team that also owns prompts and workflows becomes the queue every agent team waits in.
Gartner's Max Goss made a related point in April 2026: organizations that block or restrict agent use push employees toward shadow AI, which carries far greater risk. Our reading is that an agent platform that turns every change into a ticket creates the same pressure. Teams route around it, and the duplication you removed returns outside the governed layer.
The shared layer works best as a contract. The platform team owns identity, the tool registry, the model gateway and the access trail, and publishes a paved path for building on them. Agent teams own everything that makes their agent useful, including the framework each team picked for its use case.
A simple test shows where the line sits. A team should be able to ship a new version of its agent without filing a ticket with the platform team. The only request that should need one is access to a system the agent has never touched before.
A layer that holds that line can absorb growth, and growth is the real test of the architecture.
Judge the architecture by agent 21. Its team registers the agent, and on day one it inherits an identity, scoped credentials, approved tools, a model budget and an access trail. Nothing gets rebuilt, and nobody files a ticket for each piece.
A few design choices make that possible. Registration is the only way an agent gets credentials, so nothing runs outside the registry. New agents start from versioned templates, so each one begins on a known, reviewed base. When an agent is retired in the registry, its access is revoked everywhere at once.
The shared layer governs what agents can reach. How a single agent behaves when a tool call fails is a separate design problem, covered in our guide to how a single agent should handle failed tool calls and handoffs.
Your existing agents move onto the layer in order of the access they hold. Agents that write to systems of record go first, because each one is a path that can change data. Read-only agents follow, and low-risk internal agents move last or retire.
Each migration swaps the agent's own credentials and connectors for the shared ones, and the agent's logic stays with its team. The hard part is building the layer while 20 teams keep shipping.
Ideas2IT builds this layer with Forward Deployed Engineers who embed inside your environment from day one. They work in your cloud accounts and repositories, join your platform team's standups and share its OKRs, so the layer gets built while your agent teams keep shipping. [CONFIRM WITH FDE LEAD before publish; delete if it can't be confirmed] In the agent estates Ideas2IT's FDE teams have assessed, credential management and tool connectors tend to have the most versions, because every team had its own answer for where API keys live. Centralizing those two first resolves the most access questions before much shared infrastructure is built.
That delivery model is platform-led. The layer is built on AgentHero, an open-source agentic infrastructure layer Ideas2IT built, so the engineers setting up your layer know it from the inside. AgentHero supplies the shared components this piece has argued for: an agent registry with life cycle controls, a tool registry with MCP support, secrets and authentication with encrypted credentials, workspace management, an AI gateway with token budgets and model routing, and input validation with injection scanning and rate limits. It is cloud-agnostic and framework-agnostic, and you own the code and every agent built on it.
What you receive is a shared layer your next agents build on from their first release. Your existing agents are assessed for migration in the access order described above.
You can build on AgentHero yourselves, or Ideas2IT's engineers can build the layer with you and hand your platform team one it already knows how to run.
Ideas2IT holds SOC 2 Type II and ISO 27001 certification [VERIFY: Ideas2IT's site badges read ISO 27002] and the AWS AI Services Competency, formerly the Generative AI Services Competency. Those matter when an engagement touches your identity systems, credential stores and cloud accounts.
Getting that layer in place starts with an assessment of your current estate. It maps every agent to the access it holds and applies the two questions to each capability. It then sequences the build so the next agent on your roadmap is the first to launch on the shared layer.
Didn't find what you were looking for?
