2026 is the year
of agent management.

To whoever is accountable for the agents

Three things happened at once this year. Almost nobody connected them.

The consensus reading is that this is a security problem. We think that reading is wrong, and the error is expensive. A security framing buys a tool and a review board. Neither produces a list, an owner or a number, and those three absences are the entire problem. This report makes the case and says what would prove us wrong.

Lyzr Research, October 2026

Agents that IBM expects most large enterprises to be running by the end of 2026

Sit with that number. Almost nobody approved sixteen hundred of anything. They arrived a few at a time, from six directions, each one individually reasonable and none of them wrong.

Almost nobody approved sixteen hundred of anything

Building an agent got dramatically cheaper, and the approval step disappeared.

Both halves matter and the second one matters more. A low-code platform turns an agent into an afternoon. That is the price collapse. But the thing that actually changed the count is that building one stopped requiring anyone’s permission. An engineer needs a repository. A business user needs a login they already have. Price collapses are visible in a budget. Permission collapses are not visible anywhere, which is why the count surprised everybody.

• Nobody holds the list. Discovery by questionnaire finds the agents people remember to declare, which is rarely the set that causes the incident.
• Nobody owns the individual agent. The builder moved on. The business unit assumes technology owns it. Technology assumes the business unit does.
• Nobody can say what any of it returned. Spend arrives as one invoice with no breakdown. There is no numerator and there is no denominator.
• Any one of these is an ordinary operational gap. All three at once, at four figures of scale, is a different category of problem and it does not respond to ordinary fixes.

One of these lines is a technology adoption curve, which is a thing organizations are good at. The other is an operational capability curve, which is a thing organizations are good at only when somebody is made responsible for it.

The gap between those two lines is the entire subject of this report

Delegate to something that acts for you and it knows more about what it did than you do.

The best-engineered agents in most enterprises and the least centrally visible, because they live in repositories rather than a console. The team knows exactly what they built. Nobody else does.

What closes it

• Discover across repositories and cloud accounts, not by survey
• Take the owner from the commit history rather than a form
• Treat the service account as the identity to trace
• Require registration at deploy, not at design

Assembled by people in renewals, HR, operations or marketing on a platform the company already pays for. Often no engineering involvement at all, and often no awareness that software has been created.

What closes it

• Treat the platform itself as an origin and discover inside it
• Require a named owner at creation, enforced by the platform
• Expire anything dormant automatically
• Stop calling it citizen development in security documents

Arriving in a vendor release, sometimes enabled by default, operating on your data under a contract signed before agents existed as a category. Invisible to any inventory built around things you built.

What closes it

• Add an agent question to vendor review and re-ask it at every major release
• Audit which purchased platforms have agent features switched on
• Require contractual notice of new agent capability
• Record vendor-operated agents in the same registry as your own

Reading repositories, opening pull requests, touching build systems. Treated as developer tooling rather than production software, so the usual controls never attach.

What closes it

• Route them through the same gateway as everything else
• Retain traces even where a human reviews the output
• Scope repository access deliberately rather than by default
• Include them in the count, because an auditor will

Outside your perimeter entirely. Their trace, not yours, if a trace exists at all. Your regulator will still consider it your responsibility.

What closes it

• Contractual right to the trace, in the schedule
• Named agents listed, not a general clause about AI
• A tested way to require they stop
• Annual attestation that the list is current

Nothing is wrong with this one. It has an owner, a purpose, a review record and a roadmap slot. The danger is treating the list it produces as the inventory.

What closes it

• Keep doing this
• Stop presenting its output as the count
• Use it as the template for what registration should look like
• Measure the gap between it and discovery, monthly

Shadow IT produced SaaS discovery. Unmanaged cloud produced posture management. Both arrived late, and both arrived anyway.

The pattern is identical each time and the sequence does not vary. Capability becomes available without central approval. Adoption outruns inventory. An incident makes the gap visible. A discovery category forms, matures, and becomes a line item nobody questions. The only variable is how long an organization spends in the window between step two and step three, and what that window costs them.

Call it a security problem and you get a tool and a review board. Neither produces a list, an owner, or a number.

The security risk is real, and serious people are working on it competently. Our argument concerns where the problem sits. Security functions are built to find and stop bad things. The three things that broke here are absences. A register is missing. An accountable name is missing. A unit cost is missing. Those are management artifacts, and no detection product has ever produced one. Buying a better detection product will not start.

Any organization produces systems that copy the shape of its own communication structure.

Only variety can absorb variety. A controller needs at least as many responses as the system it controls has states.

Of 47 technology vendors polled who recognize agent control planes as a distinct category; 92% have assigned a product team; 40% report active customer buying motions

That is what a category looks like in the months before it becomes obvious. Microsoft shipped Agent 365 in May. Palo Alto bought Portkey. Fiddler repositioned in January. Salesforce is calling MuleSoft Agent Fabric a vendor-agnostic control plane. Everybody is claiming the same layer at the same time, which is usually the signal that the layer is real and that nobody owns it yet.

Everybody is claiming the same layer at once

A gateway routes. It does not govern. Those are different verbs, and mixing them up is expensive.

An AI gateway is genuinely useful and it is the right first purchase for most platform teams. It centralizes model access, kills key sprawl, attributes cost and enforces rate limits. What it cannot do is tell you what the agent did after the model answered. It sees a request and a response. It does not see the tool call, the write to the system of record, or the human who approved it. If your question is cost, buy a gateway. If your question is what happened, a gateway will not answer it.

Observability tells the team that built the agent how it is behaving. It does not tell you what exists.

Tracing and evaluation products are excellent and the teams building agents should have them. But they instrument what somebody chose to instrument, which means they are blind by construction to the agents nobody registered. They are built for a developer debugging behavior, not for an executive answering an examiner. Both jobs are legitimate. One product does not do both, and assuming otherwise is the most common expensive mistake in this category right now.

Every platform ships a console for its own agents. A tower that sees one airline is not a tower.

Microsoft governs the Microsoft estate well, and increasingly reaches beyond it. AWS and Google do the same within their own boundaries. These are serious products and if ninety percent of your agents live in one ecosystem you should use the native console and stop reading. The problem is that almost nobody is at ninety percent, and the first incident will involve an agent the console could not see, because that is the definition of the gap.

Buy identity from one vendor, a gateway from another, cloud governance from a third and runtime monitoring from a fourth, and each becomes another island.

This is the structural trap and it is where most organizations will end up by accident. Every one of those four purchases is defensible on its own merits. Together they produce four partial pictures, four consoles, four definitions of what an agent is, and no answer to the only question that matters, which is what is running. The missing piece sits between the islands, and almost nobody is buying it because almost nobody has noticed it is a separate purchase.

There are only two ways to make money in business. Bundling and unbundling.

Which tools an agent may call, and with whose permission. The newest layer and the least settled, because the protocols underneath it are barely two years old.

What closes it

• Scope tool access per agent, not per platform
• Inherit the permission of the person, not the service account
• Record every tool call against the case
• Treat a new tool as a change requiring approval

One path for model calls, with budgets, routing and limits. The most mature layer and the easiest to buy, which is why most organizations start and stop here.

What closes it

• Route everything through one path, including coding tools
• Attribute spend to an agent and an owner at the gateway
• Hard limits rather than alerts
• Make the paved road easier than the alternative or teams will route around it

A person on consequential actions, with the approval recorded. Thinnest coverage in the market, and the layer most often faked.

What closes it

• Define consequential narrowly, so the rate is sustainable
• Record the override, not just the approval
• Measure the rate a reviewer can actually sustain
• If nobody has ever rejected one, the control is not working

Tracing and scoring agent behavior. Strong products, built for the people who build agents rather than the people accountable for them.

What closes it

• Use it, and stop calling it governance
• Pair it with discovery or it only sees the known estate
• Make traces readable by somebody who did not build the system
• Keep evaluation separate from inventory in your own architecture

Reconstructing one decision months later, for somebody who did not build the system. The rarest capability of the five and the one every incident ends at.

What closes it

• Retain by case rather than by log file
• Long enough to survive an examination cycle
• Test it by having an outsider reconstruct one
• Include the human action in the record

Each small exception, once it causes no harm, quietly becomes the new standard. Nobody ever decides to lower the bar.

The bad version starts with a question nobody can answer, long before any breach.

Somebody asks what an agent did. Not an attacker, not a regulator. Usually a customer or a finance controller. The answer takes four days and is incomplete. That becomes a finding. The finding becomes a policy. The policy becomes a freeze, because a freeze is the only instrument available to somebody who cannot see what they are stopping. The freeze lands on the good projects as hard as the bad ones, and the organization spends the next year rebuilding permission it already had.

The good version is unglamorous. Somebody produces a list, and keeps producing it.

It starts with a discovery run that surprises everybody. Owners get attached over a few weeks, which is tedious and generates arguments that turn out to be the useful part. Traffic moves through one path. Somebody tests the stop control and writes down how long it took. None of this needs a transformation program, and none of it needs a new budget cycle. The entire difference between the two scenarios is a quarter of unglamorous work done before anybody asked for it.

What separates the two is five questions, and none of them is technically hard.

What is flying. Who cleared it. What has it touched. What is it costing. How do I ground it. We expect most organizations could answer all five within a quarter of deciding to. The ones that stall will spend that quarter arguing about whose budget it comes from. The gap between the two futures is who picks it up.

Value accrues to whoever owns the point of access, not to whoever owns the supply.

Every component travels the same path. Invented, then custom-built, then a product, then a utility nobody discusses.

A freeze permanently ends the projects that were working.

When governance arrives as a moratorium, the things that stop are the things that were visible, which means the well-run projects with named owners and measured results. The unregistered agents nobody knew about keep running, because a moratorium cannot stop what it cannot see. That is the specific irony of arriving late. The freeze selects against exactly the behavior you were trying to encourage, and the teams who did it properly learn not to bother next time.

When a measure becomes a target, it stops being a good measure.

The honest counter-argument is that this solves itself, and we would rather you heard it from us.

It goes like this. Agent building consolidates onto two or three platforms. Those platforms ship governance that is genuinely good, because governance becomes a competitive feature. Identity providers extend to agents the way they extended to service accounts. Within three years, native coverage is sufficient for most enterprises and a separate control plane looks like a product that existed briefly between two eras. We think that is maybe a one-in-four outcome. If you believe it is more likely than that, the right move is to buy nothing, route everything through one gateway for cost, and wait. That is a defensible position and we would not argue hard against it.

Discovery by questionnaire finds the agents people remember to declare. It misses purchased software, last quarter’s project, and anything running in a development tool nobody calls production.

What closes it

• Discover automatically across clouds, platforms and repositories
• Treat an unregistered agent as an incident
• Include vendor-operated agents touching your data
• Re-run discovery on a schedule, not on request

An agent with no named owner is nobody’s responsibility at exactly the moment it matters. The builder moved on and both sides assume the other owns it.

What closes it

• A named human owner on every agent, enforced at registration
• Purpose in one sentence a non-engineer can read
• An expiry date, so dormant agents surface on their own
• Ownership transfer as a blocking step when people leave

Application logs prove something ran. They rarely let you reconstruct one decision months later: input, model, retrieved context, tool calls, the write, and the person who approved it.

What closes it

• Trace by case, not by log file
• Retain long enough to survive an examination cycle
• Make it searchable by somebody who did not build the system
• Include the human action, not only the machine’s

Spend arrives as one invoice with no breakdown by agent, team or purpose. Nobody can defend it and nobody can optimize it, so the first budget squeeze kills the good projects alongside the bad.

What closes it

• Attribute every call to an agent and an owner
• Budgets and hard limits at the gateway, not in a spreadsheet
• Alert before the overrun, with the owner named
• Route repetitive work to a cheaper model deliberately

Most stop procedures involve finding the team, the repository and somebody with access, on a Tuesday afternoon. Nobody has rehearsed it, and the one that needs stopping is the one nobody knew about.

What closes it

• One control that halts any agent, from one place
• Works out of hours, by somebody who is not the author
• Tested on a schedule, like a fire alarm
• Halting is logged, with a reason and a reinstatement path

• How many agents we run, and how that compares to last quarter.
• How many have a named owner, as a percentage, and which business units are behind.
• What they cost in total and per unit of work, trending.
• How long it took to stop one, from the last test, and who performed it.
• One decision, reconstructed, with the trace attached. The same exercise every quarter, a different agent each time.

The cost of being early is a quarter of work. The cost of being late is a freeze.

The late version has a predictable ending. Something happens, the organization cannot explain it, and the response is a moratorium rather than a control, because a moratorium is the only instrument available to somebody who cannot see what they are stopping. That freeze usually costs more than the governance would have, and it lands on the good projects as hard as the bad ones. The argument for acting now is simple. The work is small while the estate is still legible, and it stops being small very quickly.

Opencontroller finds, owns, ships, runs and improves every agent, wherever it was built.

Agents stay on the runtimes where they run today. Opencontroller registers them, observes them, and enforces policy wherever their traffic passes through its gateways. Lyzr describes ten blocks and more than 70 modules on one policy model, with production evidence feeding the next release. It works across any cloud, framework, model and runtime, with adapters for Amazon Bedrock AgentCore, Gemini Enterprise Agent Platform and Microsoft Foundry.

Control happens in the path, so a call can be held before it lands.

Most agent monitoring tells you what a call did after it did it, and a log cannot stop a model call that is already running. Opencontroller sits in the request path instead. Each call is checked for identity, spend scope and prompt injection before the model sees it, and the response is checked again before it reaches the user. The control plane and its gateways run in your own cloud account, on premises or air-gapped, and Lyzr says control-plane data, credentials and telemetry never need to reach it.

Agents inside the development process get covered too, from the laptop to the cluster.

The fourth runway was agents inside the development process. Lyzr’s Basecode controls the machines where agents are built, and brings coding agents such as Claude Code, Codex and Copilot under the same policy and spend controls. Agent Studio and Architect are where agents get built, quickly or visually. Opencontroller controls the environments where agents run. Lyzr says teams can build in Studio and govern the whole fleet in the control plane, including agents they wrote by hand.

Founded in New York in 2023. Agent Studio, Architect, Opencontroller, Open Cowork, Openfinetuner, Optimus and Madison cover building, governing, running and owning agents. Deploys in your AWS, Azure or GCP account, a dedicated tenant, SaaS, on bare metal, fully air-gapped, or on the Optimus appliance.

Backed by Rocketship.vc, BGV, Accenture Ventures, GFT, the Partnership Fund for New York City and Plug and Play.