Why Agents Need a Control Plane — Agent 365: Foundations

For years, organizations secured two familiar kinds of actors: people with accounts and applications that ran code. Artificial intelligence agents change that pattern. An agent is software that can choose tools, take steps, and act toward a goal without a human approving every move. That makes it useful, but it also makes it hard to govern with controls designed for humans or fixed applications. A control plane is the missing layer: one place to know which agents exist, what they can reach, who is responsible for them, and whether they are behaving inside policy.

The old security model had two actors

In security, an actor is anything that can do something in a system: sign in, read a file, call a service, send a message, or change a record. For most of computing history, enterprise security was built around two actor types.

The first actor was the person: an employee, contractor, or partner with an account, a password, a role, and a manager. The second was the application: a workload, service, website, database, or business system that did what its code instructed it to do.

Those two categories shaped identity systems, access reviews, audit logs, incident response, and compliance reporting. They worked because people and applications were limited in different but predictable ways. A person acts at human speed. An application runs predefined logic.

An agent is not just another application

An artificial intelligence (AI) agent is software that can decide which tools to use and which actions to take to complete a task. The important part is not that it uses AI. The important part is that it acts.

A traditional application waits for a precise instruction or follows a defined workflow. An agent may be given a goal, such as summarize these customer issues and draft responses, then choose which documents to read, which application programming interfaces (APIs) to call, and whether to create an email, ticket, or calendar entry.

That ability puts agents between the old categories. They are not people, because no human is pressing each button. They are not ordinary applications, because their exact path may vary from one task to the next. Microsoft describes this class as a non-human actor: software that can operate on behalf of users or processes without being a human identity.

📌

The key shift. The risk is not that an agent is intelligent; the risk is that it can take action across systems without step-by-step human approval.

Agents sit between the old categories: not people, not ordinary applications, but non-human actors that choose their own path.

Autonomy turns access into a larger risk

Access is not new. People have access. Applications have access. What changes with agents is the combination of broad reach, speed, and discretion.

An agent may hold access to email, files, chat, customer records, databases, workflow tools, and other agents. It can run continuously, respond in seconds, and repeat actions at a scale no person could match. It may also choose a new route through its tools because the current task is slightly different from the last one.

That is why agent access must be treated as its own governance problem. If an agent can read sensitive files, send messages, call APIs, and update systems, then the organization must know exactly why it has that reach, who approved it, and what boundaries apply.

Sprawl begins when agents become easy to create

Agents are increasingly simple to build. A business team may create one with a low-code tool. A developer may build one in a software development platform. A department may buy one from a vendor or partner. Each agent may be useful. The problem is that they often appear faster than governance can see them.

Agent sprawl is the growth of agents across an organization without a complete inventory, consistent ownership, or common controls. It is not merely a neatness problem. It means security and operations teams cannot reliably answer basic questions: which agents exist, what data they can access, what tools they can call, and whether anyone still needs them.

A shadow agent is more dangerous. It is an agent that runs without registration, approval, or visibility from the teams responsible for governance. In practical terms, it is an actor with access but no clear accountability.

⚠️

Unseen means unmanaged. An organization cannot secure, audit, limit, or retire an agent it does not know exists.

An agent that runs without registration, approval, or visibility is a shadow agent: access with no clear accountability.

Controls for people and applications only partly fit

It is tempting to govern agents by treating them as people. That fails when an agent inherits human-style permissions without human limits. A person has a workday, a manager, fatigue, context, and social accountability. An agent can run at all hours, act repeatedly, and touch many systems in a few seconds.

It is also tempting to treat agents as ordinary applications. That only partly works. Application governance assumes the workload follows known code paths. An agent may select different tools or actions depending on the goal, the prompt, the available data, and the environment around it.

The old questions still matter: what can this actor access, who owns it, what did it do, and is it allowed to do that? The new requirement is to ask those questions in a way that reflects how agents behave: autonomous, tool-using, fast, and often created outside traditional software delivery pipelines.

A human account can give an agent too much inherited privilege.
An application identity can hide the fact that the workload is making choices.
A static access review can miss behavior that changes as tasks change.
A log that records only tool calls may not show which agent goal caused them.

Point solutions leave seams attackers can use

When a new risk appears, teams often reach for the tools they already have. One system discovers some agents. Another grants access. A third monitors activity. A fourth stores audit records. This point-solution approach can help at first, but it creates seams.

A seam is a gap between tools where context is lost. The inventory may not know the current permissions. The access tool may not know the business owner. The monitoring tool may see an API call but not the agent that initiated the task. The compliance report may arrive after the risky behavior has already happened.

Attackers and accidents both benefit from seams. An over-permissioned agent can be misused. A forgotten agent can keep old access. A compromised tool can become a path into other systems. Governance works best when identity, access, behavior, ownership, and audit are connected.

⚠️

Seams matter. Separate tools are not automatically weak, but weak integration makes it harder to understand and control agent behavior end to end.

Point solutions leave seams where context is lost; a control plane connects identity, access, and audit.

A control plane gives agents a governed home

A control plane is a central layer for managing a class of systems consistently. For agents, it should not be a separate island. It should connect to the identity, security, data protection, observability, and compliance systems the organization already trusts.

At minimum, an agent control plane needs to provide inventory, identity, ownership, access control, policy enforcement, monitoring, audit, and lifecycle management. Those capabilities turn agents from scattered actors into governed resources.

The goal is not to slow every team with heavy process. The goal is to make safe creation the default. Builders should be able to register agents, request appropriate access, inherit baseline policies, and produce usable logs without inventing a governance model from scratch each time.

Discover every agent, including agents created outside central information technology processes.
Assign each agent a distinct identity rather than hiding it behind a shared user or service account.
Record an accountable owner, business purpose, and approved scope.
Limit access to the tools and data the agent needs for its purpose.
Monitor behavior so unusual actions can be investigated quickly.
Retire agents and remove access when they are no longer needed.

A control plane turns scattered agents into governed resources with inventory, identity, policy, and audit.

The real decisions leaders must make

A control plane is not only a technical architecture. It forces practical decisions about how the organization wants agents to enter, operate, and leave the environment.

Leaders need to decide whether every agent must be registered before it receives production access, what evidence is required for approval, who owns an agent after it is deployed, and which actions require stronger review. Practitioners need to decide how agent identities are created, how permissions are requested, how logs are correlated, and how policy exceptions expire.

The best test is simple: if an auditor, incident responder, or business owner asks about one agent, can the organization answer in minutes? What is it? Who owns it? What can it access? What has it done? Why is it still running? A control plane exists to make those answers routine.

✅

A useful benchmark. Good governance lets teams build agents quickly while making ownership, access, behavior, and retirement visible by default.

Key takeaways

AI agents are a third kind of actor: not human users, and not ordinary fixed applications.
The defining difference is action: agents can choose tools and steps without approval for every move.
Agent sprawl and shadow agents appear when creation is easy but inventory, ownership, and approval are inconsistent.
Existing controls for people and applications help, but they do not fully fit autonomous, tool-using software.
Point solutions can leave seams between identity, access, monitoring, and audit.
An agent control plane gives organizations one governed place to see agents, limit access, monitor behavior, and manage lifecycle.

Glossary

Actor: Anything that can perform an action in a system, such as a person, application, service, or agent.
Artificial intelligence agent: Software that can choose tools and actions to complete a goal without a human approving every individual step.
Application programming interface: A defined way for one piece of software to request data or actions from another piece of software.
Non-human actor: A system identity or software actor that can act in digital systems but is not a person.
Agent sprawl: The uncontrolled growth of agents across an organization without complete visibility, ownership, or consistent governance.
Shadow agent: An agent that operates without registration, approval, or visibility from the teams responsible for governance.
Control plane: A central management layer used to see, configure, govern, and monitor a set of systems or resources.
Point solution: A tool that solves one narrow problem but may not provide enough shared context with other tools.
Lifecycle management: The process of governing something from creation and approval through operation, review, change, and retirement.