Agentic AI can give software the ability to read information and take actions across business systems. Before an agent goes live, leaders need to decide who owns it, what it may access and when it must stop.
The risk needs a decision
An agent may begin as a useful experiment. Once it reaches business data or takes actions for a team, it needs a clear operating model. The people approving its use should understand both its purpose and the limits placed on it.
Research provides a reason to take that work seriously. In AvePoint's June 2026 study with Osterman Research, 88.4% of respondents reported an agent-related security incident in the previous year. The study covered 750 people responsible for data security, information management or AI programmes across the Americas, EMEA and Asia Pacific. Its findings describe that sample, rather than every organisation or a South African benchmark.
Technical controls also need testing. In a March 2026 report, Datadog Security Labs described gaps in audit events for certain Copilot Studio administrative actions. The report records remediation in October 2025 and subsequent inconsistent logging during retesting. It supports a practical lesson: verify the events your security team expects to receive. It does not establish the present state of your tenant.
Neither source proves that missing ownership caused every incident. Both support asking how your organisation will oversee agents and check that its controls work.
What makes an agent different
An agent can combine reasoning, information retrieval and tools to carry out a task. Depending on its design, it may draft a response, send a message, update a record or trigger another process. Some work begins with a person's request; other work can start from an event or a schedule.
The access model matters. An agent may use the signed-in user's permissions, credentials attached to a connection or a dedicated identity. Microsoft's tool authentication guidance explains the distinction between user and author credentials. Review the effective permissions of each tool rather than assuming every agent has its own account or uses the end user's access.
That is why the decision belongs to the business as well as IT. The team sponsoring an agent needs to define the outcome it wants, the actions it permits and the risk it is prepared to accept. Security and IT need those decisions to configure and test the service.
Four decisions before deployment
Ownership. Give each production agent a named business owner. That person should be accountable for its purpose, authorised use and continued value. Also identify the technical owner and the person who can suspend it. Record how ownership transfers when someone leaves or changes roles.
Data scope. Specify what the agent may read, create, change or share. Check the effective permissions behind every connection. An agent intended for one team may have access to more information than that team needs if its connection uses broader credentials. Review access whenever the task or data sources change.
Approval tier. Set review requirements according to the actions and information involved. Drafting an internal summary carries different risks from changing customer records or sending messages externally. Decide which actions require human approval, who may approve a new agent and when security, privacy or compliance review is needed.
Lifecycle. Set a review date and a retirement process. Check whether the agent is still used, whether its access remains appropriate and whether its outputs meet the agreed standard. Remove unused access and address dependencies when retiring it. Include consumption and support costs in that review.
These decisions become policies and settings. They need people who can maintain them after the initial deployment.
Connect oversight to existing controls
Microsoft Agent 365 provides a control plane for observing, securing and governing agents. It connects agent administration with Microsoft Entra, Microsoft Defender and Microsoft Purview. The security team should assess which identity, threat and data controls apply to each agent and confirm that the required licences, integrations and policies are in place.
Inventory coverage needs checking too. Microsoft's Agent 365 product FAQ identifies automatic registration conditions and notes that agents outside those environments need additional steps. A dashboard should be checked against the agents actually in use.
Microsoft's own implementation offers a useful example. Its IT team reported visibility into more than 500,000 agents in August 2026. The same account stresses that central oversight complements existing security practices. It also describes work still under way. Treat it as an implementation example, rather than a promise that buying the product completes the work.
Who should make the decisions?
The business sponsor, IT, security and information governance teams should agree the operating model together. The CIO or COO may coordinate that work. Escalation to an executive committee or board should follow the organisation's risk policy and the significance of the proposed use.
Business owners define the purpose and approve the use. IT implements and maintains the service. Security verifies access, monitoring and incident procedures. Information governance teams assess the data obligations. Make these responsibilities explicit so that an incident does not become a search for whoever last opened the console.
What the first weeks can cover
Start with an inventory of the agents you know about. Record each agent's owner, purpose, users, data connections, authentication model and actions. Reconcile that list with the relevant administration tools and department owners to identify gaps.
Next, document the approval rules. A short policy can be a starting point, but the work required will depend on the estate and its risks. Assign dates and owners for unresolved issues. For agents that reach customer or financial information, require the appropriate security and information governance review before deployment.
Test a limited use case against explicit acceptance criteria. Check the output, the permissions it uses, the audit events it generates and the procedure for stopping it. Track usage, operating cost, errors and the time people spend reviewing its work. Those measures give the business evidence for deciding whether to extend the use case.
Where South Africa's rules come in
POPIA continues to apply when agents process personal information. The responsible party may be a person or an organisation; naming an agent owner does not transfer the organisation's statutory duties to that employee. A lawful basis for processing and appropriate safeguards still need to be assessed. The Protection of Personal Information Act sets out these requirements.
Bring the Information Officer and relevant governance teams into the discussion. They need a clear account of what the agent will do and how personal information will be protected.
Questions to settle before deployment
Who should own a business agent?
Name a business owner who can approve the purpose, authorised use and continued need. Record a technical owner and the person authorised to suspend the service as well. Define the handover process so that accountability and access reviews continue when an employee leaves or changes roles.
Does every agent have its own identity?
Check the design and authentication model. Access may rely on the signed-in user, a connection's credentials or a dedicated identity. Review the effective permissions for each tool and data source. The approval should reflect the access the agent can actually exercise when it runs.
What should a pilot demonstrate?
Set acceptance criteria for the task and its controls. Check output quality, permissions, required audit events and the stop procedure. Measure usage, cost, errors and human review effort. Use that evidence to decide whether to expand, change or retire the use case rather than assuming a benefit.
What changes when an agent's role expands?
Review the purpose, data scope and permitted actions again. New connections or actions can change the risk and operating cost. Confirm the approval tier, retest the relevant controls and update the owner record before expanding the deployment. Keep the decision and supporting evidence available to the responsible teams.
Start before you scale
Ownership, data scope, approval tiers and lifecycle give the business a practical starting point. Settle them while the estate is still small enough to review, then keep testing and updating the controls as it grows.
Explore Braintree's Modern Workplace services to start the conversation.
Let's grow.
