Security

Who's Governing Your AI Agents?

In the first week of May 2026, three vendors shipped products to solve the same problem. WSO2 released Agent Manager, billed as an open control plane for AI agents. Cognizant launched Secure AI Services. Netskope expanded its One AI Security suite for agent oversight. When that many companies build the same category in one week, it usually means their customers hit the same wall at the same time. The wall is governance: a fleet of agents holding real credentials, acting on real systems, with no central place to see or control what they do.

The demand is real and the readiness is not. In a 2026 MIT Technology Review survey, 85% of organizations said they want to operate agentically within three years, while 76% admitted their current operations and infrastructure cannot support that yet. Governance is a large part of that gap.

An agent is an employee with a password

Look at how access usually works today. A developer wires up an agent, hands it an API key to the CRM and a service account for the file store, and ships it. The key works. The agent does its job. Six months later there are forty agents, and nobody can answer a basic question: which agent can touch the payments system, and who approved that?

Treat agents the way you treat staff. Every agent gets its own identity, not a shared key passed around in environment variables. It gets the narrowest set of permissions that lets it do its one job and nothing adjacent. When it is retired, its access is revoked that day, the way you would close out a departing employee’s accounts. This is ordinary identity and access management, applied to software that acts on its own. WSO2’s pitch for Agent Manager is exactly that: a system of record for every agent, with identity and policy attached.

If you cannot replay it, you cannot trust it

An agent took an action at 2:14 a.m. A customer is now asking why. Can you reconstruct what the agent saw, what it decided, and which tool call it made? If the answer is “we’d have to dig through application logs and guess,” the agent is running without a flight recorder.

Audit and observability are not reporting features you add later. They are what lets you leave an agent running unattended at all. Every tool call, every input, every external action should land in a log you can query, attributed to a specific agent identity. Cognizant built its Secure AI Services around this for regulated industries, where “show me the audit trail” is a condition of operating, not a nice-to-have.

The cheapest agent to govern is one that can only reach what its job requires. Scope the access tightly on day one and a confused or compromised agent can do little damage. Bolt the controls on after an incident and you are writing the policy in the worst possible week.

Why a control plane beats per-agent bolt-ons

The tempting path is to handle governance one agent at a time. This one logs to a file, that one has a hardcoded allow-list, the new one inherits whatever the last developer copied. It holds up until you have a dozen of them and a security review wants one consistent answer about all of them.

A control plane is a single layer that every agent registers with. Identity, permissions, logging, and the kill switch live in one place, applied the same way to every agent regardless of which framework built it. A new agent inherits the controls instead of reinventing them. When you need to cut off access fast, there is one switch to flip, not forty code changes to ship. That is why WSO2 shipped Agent Manager as a control plane rather than a library. The value sits in the central enforcement point.

The on-prem version of this question

For a law firm or a manufacturer with sensitive process data, governance carries a question the SaaS vendors tend to skip: where does the data go, and whose model gets to learn from it? An agent that reads privileged documents to do its work cannot quietly hand that content to a third party that keeps it for training.

This is where we part ways with the bolt-on crowd. We run agents on infrastructure the client controls, with no-train and no-retain guarantees and data residency that holds up to a compliance review. The control plane and the privacy posture are one project. You cannot claim least-privilege access while shipping the underlying data somewhere you do not govern.

Most teams skip all of this until they are past a handful of agents and a security review forces the question. The better time is while the fleet is still small enough to retrofit cheaply. If you are moving from one working agent to a real fleet and want governance built in from day one, start a conversation. We would rather wire up the control plane now than help you reconstruct an audit trail later.