AI Control Plane: Managing AI Agents Over Time

When a company puts an AI agent to work, it needs to decide more than the agent’s purpose and permissions. It also needs to decide who will review the agent while it is in operation, and who will retire it when it is no longer needed.

When adoption spreads department by department, it is not enough to manage each agent’s settings individually. The company should also be able to check, in one shared list, what is running and who is responsible for it.

On September 11, 2026, Salesforce announced the Trusted Enterprise AI Harness, a common architecture for enterprise AI, together with a management layer called the AI Control Plane.

This article focuses on the part of the announcement that deals with keeping track of agents and managing them over time. It does not go into how each element is technically implemented or into the details of individual product features.

By “governance” we mean setting the rules for how agents are used, checking whether those rules are being applied, and correcting course when needed.

What was announced

According to Salesforce, the Trusted Enterprise AI Harness is a common architecture that brings together what AI needs to understand a company’s information, plan and act, and operate within the company’s business rules.

Salesforce organizes it into six elements:

Element	Summary of Salesforce’s description
Trusted Context	Combines customer information, data, knowledge, and real-time signals to help AI understand business operations
Trusted Agency	Supports reasoning and planning, manages state and memory, and coordinates the sequencing of tasks and collaboration among agents
Trusted Action	Connects securely to applications, APIs, and workflows so that work actually gets carried out
Trusted Governance	Governs the data and rules AI relies on, including where data comes from, how it has been processed, and its quality
Trusted Security	Provides identity and permission controls, privacy protections, data protection, and runtime security
Trusted Models	Selects the right model for each job and routes work based on accuracy, performance, cost, and business requirements

Together, the six elements combine AI’s ability to understand, decide, and act on business tasks with the management and protection mechanisms that support it.

The AI Control Plane is a layer for tracking and managing, across the organization, where agents are, how they are configured, and whether they are running. According to Salesforce, the AI Control Plane is intended to provide a shared management layer for both Salesforce and third-party AI. It will support the discovery and registration of agents and AI capabilities, identity and policy management, and lifecycle management. It will also support performance evaluation, monitoring of behavior and outcomes, and cost management.

The announcement does not specify the scope of automatic discovery for unregistered agents. The word “discover” should not be taken as a guarantee that every AI system in the company will be detected automatically.

On availability, Salesforce says that many of the technologies forming the foundation are available today, and that new capabilities and the unified experience are planned to begin rolling out in early fiscal year 2028 — the fiscal year that starts in February 2027. Details on packaging and pricing are to be announced later.

Managing agents across teams

Agent management becomes harder when responsibility for creating and updating agents is spread across teams and changes are not reflected in a shared record.

Consider a company where several departments have each deployed agents for their own work. If there is no agreed place to register agents or to report changes, the company-wide list and what is actually running can drift apart.

Even when each owner knows their own agent’s settings well, the company needs a record it can consult when that person moves to another role, or when the agent starts working with other departments.

If no one is accountable for the whole and there is no shared record, the company cannot say what is running — however carefully each individual agent was designed.

We see the emphasis on discovery and registration as a response to this challenge.

When a company is sorting out agents that already exist, it makes sense to start by finding out what is running and where. When deploying new agents, registering them and designing their permissions can happen in parallel.

We recommend managing individual agent permissions while maintaining an up-to-date view of all agents across the company.

Lifecycle management starts with the first agent

We read Salesforce’s reference to lifecycle management as a reminder that management continues after deployment.

An agent is designed around the work and permissions that made sense when it was built. But work changes, people change roles, and access that was once necessary can become unnecessary or excessive as the business changes. An agent built for a project may keep running, permissions intact, long after the project has ended.

All of this can happen even with a single agent.

The same problems have long existed in managing human accounts: permissions that are never reviewed after an employee changes roles, accounts left in place after they stop being used. Agents need the same treatment, with management that covers review after deployment and, eventually, retirement.

The U.S. National Institute of Standards and Technology (NIST) AI Risk Management Framework Playbook also treats ongoing monitoring and periodic review, maintaining an inventory, and procedures for safely decommissioning AI systems as part of managing them.

Set a review schedule, record each agent’s last review and activity dates, and identify agents without a clearly assigned owner. These practices support handovers when staff roles change and help teams manage agent retirement.

Include model changes in ongoing management

Salesforce describes Trusted Models as selecting the right model for each job and routing work accordingly. Models will keep being updated, and the terms on which they are offered will keep changing.

Changing the model can change what an agent proposes, which actions it chooses, and the format of its output. A model change calls for re-evaluation; it does not remove existing approval requirements.

The premise is that permission for important operations should not depend solely on the model’s own judgment. If, for example, the sending function itself requires approval before anything is sent, then a new model can propose sending a message, but nothing is sent without approval. Checking permissions in the system that actually carries out the operation is also consistent with the countermeasures to “excessive agency” in OWASP’s risk guidance for LLM applications.

With that in place, when changing models, confirm that output quality, how the agent uses tools, and how it handles operations requiring approval still meet the business’s requirements. Record the model and configuration in use, the evaluation results, and who approved the change, and decide in advance how to roll back the change or stop the agent if something goes wrong.

If the requirements are not met, continuing with a different model is not the only option. Returning to the previous configuration, switching to manual work, or pausing the agent are also possible decisions.

MIF recommends applying change management to models, connected systems, and permissions. This is our operational recommendation; it does not mean that Trusted Models performs this whole process automatically.

What to record in an agent register

Define the agent register alongside each agent’s permissions so that it remains useful as adoption expands across departments.

The table below is MIF’s suggested starting point, not a list of Salesforce product fields. Adapt it to your organization’s size, operations, and applicable requirements.

Item	What to record
Identification and purpose	Name, unique identifier, purpose, and deployment environment (production or testing)
Owner	The current owner, their department and contact details, and who takes over if they change roles
Model, configuration, and connections	Model in use, version and configuration details that can be verified, and connected systems and agents
Execution account and permissions	The account used to run the agent, the permissions applied, the data it may read, and the actions it may take
Approval requirements	Actions requiring human approval, designated approvers, and references to the settings that enforce those requirements
Status	Lifecycle status (in development, in use, stopped, or retired) and most recent activity date
Review	Last review date, next scheduled review, reviewer, and changes that trigger reassessment
Stopping and retirement	Who decides to stop or retire the agent, how it is stopped, which permissions must be revoked, and confirmation that these steps were completed
Where to find settings, evaluations, and logs	References to current settings, test results, and activity logs

The register records the current owner rather than the creator because who built an agent and who is now responsible for updating, stopping, or handing it over are different questions. The review item includes the last review date, not just the next one, so that it is possible to check later whether reviews actually took place.

Not everything needs to be copied into the register. Pointing to where existing settings and records live avoids adding a second set of records to maintain.

Do not assume an agent is no longer needed simply because it has not run recently. Check its purpose and whether it is scheduled to run again.

Keep the register aligned with actual settings

A register alone cannot find agents that were never registered.

So in addition to registering new agents, record changes and retirements as well. Then, on a regular schedule, compare the register against what is actually deployed and against account and permission settings, to find unregistered use and any mismatch between the register and the settings.

A “read-only” entry in the register is not enough if the connected system still allows that agent to update data. Permissions need to be enforced by the system that actually carries out the operation.

What we recommend is running these steps as one continuous practice: build the list, compare it with the actual settings, update and review it when something changes, retire agents that are no longer needed, and revoke unnecessary permissions.

The announcement does not tell us in which environments, or to what extent, the AI Control Plane can automate this comparison. Whether or not a company uses the product, it needs to decide for itself how the comparison is done and who does it.

Summary: connect permission design with ongoing management

Managing AI agents means both defining what they may do and keeping their settings and ownership under review.

At MIF, we recommend maintaining a shared register of each agent’s purpose, owner, model, configuration, permissions, and status. Keep the register aligned with actual system settings, and ensure that changes and retirements are reflected in those settings as more teams adopt agents.

Start with the agents already in use or planned for deployment. Identify who manages each one, which changes should trigger a review, and how the agent will be retired when it is no longer needed. Use the register above as a starting point.

About the information in this article

This article was prepared as of September 26, 2026, using as its main source Salesforce’s press release “Salesforce Introduces the Trusted Enterprise AI Harness,” published on September 11, 2026.

The six elements, AI Control Plane capabilities, and planned availability are presented as described by Salesforce at the time of the announcement. Salesforce’s fiscal year ends on January 31, so fiscal year 2028 runs from February 1, 2027 to January 31, 2028.

The timing, scope, and pricing of new capabilities may change. If you are considering adoption, please check Salesforce’s official information for the latest status.

Statements about the product’s structure, functions, and planned availability are based on Salesforce’s published materials. The register items and operating practices are MIF’s analysis and recommendations; MIF has not independently verified the product’s discovery coverage or the effectiveness of its controls.

For the approach to ongoing management, we also referred to the U.S. National Institute of Standards and Technology (NIST) “AI Risk Management Framework Playbook” and OWASP’s “OWASP Top 10 for LLM Applications.”