Archive360's case: agent governance starts with enterprise data
Caviston's central claim is that executives keep asking whether agents are ready for production when the better question is whether their data is. He argues that model security and performance cannot make up for weak control over what an agent can retrieve. His example is simple: give an agent outdated customer information, duplicate records or unclassified material and it will work with what it has, making poorly informed decisions quickly across thousands of transactions.
His framework has three parts. Before production, he says, an organization needs governed inputs, appropriate access, and a reliable record of what the agent produced. He extends governance past the data an agent reads to the data it creates, including its decisions, the instructions it received and the documents it wrote. His reasoning is that as AI takes part in significant business decisions, being able to trace and defend those decisions becomes a core capability.
Two caveats belong here. First, this is a vendor CEO's opinion column in TechRadar's Pro Perspectives channel, and Archive360 sells archiving and data governance products, so the thesis lines up with the author's business. Second, the column says the "vast majority" of AI projects show zero ROI but cites no study or methodology. That figure should not be repeated as fact on the strength of this column. The recommendations themselves are conventional records-management and least-privilege practice applied to a new kind of actor, and they hold up without the ROI claim.
Legacy archives and provenance are where agent readiness breaks
Caviston admits that data governance is an old problem. Large organizations have spent years dealing with information scattered across operational platforms, file shares, archives and applications that should have been retired long ago. His point is that agentic AI makes those old weaknesses urgent, because an agent can act on them at machine speed and scale.
His pre-access checklist is specific. IT should identify sensitive and regulated information, apply classification and retention policies consistently, and decide which sources are current and reliable enough for the job. He singles out legacy data. Retired applications often hold valuable business history, but they also contain duplicate records, obsolete information, and data under legal holds or retention requirements.
Provenance may be the most useful idea in the column for anyone designing retrieval. Caviston argues that an agent should not treat a current system of record and a decades-old archive as equally authoritative. It needs to know where information came from, when it was last updated and which policies apply to it. He also warns against stripping legacy data of its surrounding context before exposing it. His recommendation is to preserve the relationships that give old records meaning and then release only selected datasets under policy control. Without that context, he says, agents either fail at their tasks or, worse, make faulty decisions and act on them.
For a Microsoft shop, this translates into concrete work. Microsoft's Copilot controls guidance recommends improving Copilot and agent responses by archiving or deleting content that is no longer needed. It points to SharePoint site lifecycle management for inactive or ownerless sites and to Microsoft Purview Data Lifecycle Management for finding and deleting files the organization doesn't need. Cleaning up stale content is the most direct way to stop an agent from treating an abandoned 2014 project site as current policy.
Least privilege for agents runs into SharePoint oversharing in Microsoft 365 Copilot
"Treat agents like employees," Caviston writes, and he applies the principle of least privilege. His example: a customer service agent probably needs current account and transaction data but not legal files or old employee records. He says access should follow the agent's defined purpose, and that being able to connect a system to an agent doesn't mean you should.
In Microsoft 365 the uncomfortable part is that many agents inherit the user's existing permissions. In a Microsoft Q&A answer on Agent Builder agents, Microsoft describes a "no new privileges" model: agents respect existing Microsoft 365 permissions. If a user does not have access to a SharePoint site, Teams channel, or mailbox, the agent cannot surface content from those sources. The reverse also applies. If years of "Everyone except external users" sharing have left sensitive sites open, an agent working as that user can find them far faster than the user would. The same answer recommends to use SharePoint Advanced Management and Microsoft Purview DSPM for AI to detect and remediate oversharing of SharePoint content before agents can surface it.
Microsoft's Copilot controls documentation, last updated September 9, 2026, splits the available tools by licence tier. Foundational controls come with A3/E3/G3 licences through the Microsoft 365 admin center, SharePoint Advanced Management and Microsoft Purview. Optimized controls need A5/E5/G5 licences and add more of Microsoft Purview plus Microsoft Defender for Cloud Apps. The foundational set covers most of what Caviston describes:
- Data access governance reports for SharePoint sites identify overshared sites, and admins can send a site access review to the owners of those sites.
- Organization-wide site access can be removed manually in SharePoint or automated with PowerShell.
- SharePoint restricted content discovery or restricted access control can limit user, Copilot and agent access to overshared sites while the underlying risk is fixed.
- Microsoft Purview Information Protection site sensitivity labels, and file-level encryption through sensitivity labels, protect content even after it is moved or downloaded.
- Purview Data Loss Prevention can alert when new oversharing occurs, and DSPM for AI reports show sensitive and unprotected files referenced in Copilot and agent interactions.
The optimized tier adds controls closer to Caviston's intent. With A5/E5/G5, Purview DLP for Microsoft Copilot and agents can stop Copilot and agents from processing certain sensitive files and using them in responses. DSPM for AI can run data risk assessments against specific SharePoint and OneDrive locations. Adaptive protection in Insider Risk Management can block high-risk users from reaching sensitive content through Copilot and agents. Tenants on E3 can do meaningful remediation, but the automated guardrails need the higher licence.
Copilot Studio data policies make "just because it can connect" enforceable
Caviston's line that connectability isn't permission is where Copilot Studio gives admins the most direct control. Microsoft says administrators can use data policies in the Power Platform admin center to govern maker and user authentication, knowledge sources, actions, connectors and skills, HTTP requests, publication to channels, and triggers for autonomous agents. Admins can also review the connector dependencies an agent uses to understand data-movement risk before it is deployed.
These policies need deliberate setup. Copilot Studio connectors are allowed by default, and admins must block any they deem inappropriate for use, as Platforms of Power, a Power Platform blog, puts it. Scope matters too. Microsoft says the policies can be applied at the environment level or tenant level. A Microsoft Copilot Studio lab notes that because policies attach to environments, the same agent definition can behave very differently depending on where it is deployed.
The connector controls are narrower than admins often assume. Blocking one connector does not block its neighbours:
- Blocking the "Chat without Microsoft Entra ID authentication" connector means makers can only use Authenticate with Microsoft or Authenticate manually, and agent users must authenticate themselves to chat with the agent.
- Blocking Knowledge source with documents in Copilot Studio only prevents local file uploads. It doesn't prevent makers from adding files from SharePoint or OneDrive. Those sources need the separate "Knowledge source with SharePoint and OneDrive in Copilot Studio" connector blocked.
- If you want to allow specific sites rather than block a source outright, Microsoft recommends endpoint filtering to allow or deny particular SharePoint or public-website endpoints.
- Blocking Power Platform connectors also blocks access to tools in connected MCP servers, which rely on Power Platform connectors for connectivity.
- Blocking the HTTP connector stops makers publishing agents that make HTTP requests through the HTTP request node.
Endpoint filtering is the closest built-in match to Caviston's provenance argument. Rather than letting an agent ground on any SharePoint site a maker picks, admins can limit knowledge sources to named, curated locations.
Configuring a Copilot Studio knowledge-source policy in Power Platform admin center
Microsoft documents the following route for restricting agent knowledge sources. Its documentation lists a tenant administrator or Environment Admin role as the prerequisite.
- Sign in to the Power Platform admin center. On the side navigation, select Security, and then select Data and privacy.
- Select Data policy, then choose New Policy or select an existing policy and choose Edit Policy.
- Assign the policy to the environments where agents are built and published.
- Search for "Knowledge source" to find the relevant connectors, including "Knowledge source with SharePoint and OneDrive in Copilot Studio" and "Knowledge source with public websites and data in Copilot Studio," and block or restrict them as needed.
- Review the policy and select Create policy or Update policy.
To confirm it worked, Microsoft suggests opening an agent in the governed environment, going to the Knowledge tab and trying to add a SharePoint knowledge source. For connector-based tools, create a topic, add a Tool node, choose a connector the policy blocks, and try to publish. A working policy stops the blocked action. Expect some friction: the Microsoft lab warns that agents built in permissive developer environments can break when moved into a governed corporate environment, and that blocked knowledge sources can cause agents to fail silently.
Purview Audit, eDiscovery and retention make agent decisions reconstructable
The second half of Caviston's argument is about records. He says AI-related data is becoming material in litigation, compliance reviews and customer complaints. An organization should be able to show what an agent was asked to do, what it accessed, which policies applied and what happened next. Prompts, retrieved content, outputs and resulting decisions should be kept as business records, so a reviewer can trace a decision back to the source data and to the person or function that authorized it.
For Microsoft 365 Copilot and agents, Microsoft maps this to several Purview features, each doing a different job. With A3/E3/G3, Microsoft Purview Audit provides detailed logs of Copilot and agent interactions. Purview eDiscovery can search and export prompt and response text along with referenced files, and can place a user's Copilot and agent prompts and responses on legal hold. Data Lifecycle Management enforces retention and deletion policies on Copilot and agent interactions. With A5/E5/G5, DSPM for AI activity explorer also shows any web queries used during grounding.
Logging, search and retention are separate controls, and turning on one does not give you the others. An audit log shows an interaction happened. A retention policy decides whether the content survives. eDiscovery is how you find and export it. None of them shows whether the agent's decision was correct. Caviston's standard, being able to reconstruct the decision, needs all three configured on purpose.
Copilot Studio adds its own layers. Microsoft says admins get maker audit logs in Microsoft Purview and can monitor and alert on agent activity through Microsoft Sentinel. It also offers GitHub-backed source control with auditable deployment history, which covers the "who authorized this" question for the agent's configuration. Microsoft Agent 365 is described as a central control plane where Copilot Studio agents can appear as identities in Microsoft Entra, governed by Conditional Access and access governance workflows.
Microsoft's documentation also flags a compliance boundary. Copilot Studio security audit telemetry, including agent invocation events, tool and action calls, policy enforcement decisions and runtime activity signals, runs through the Microsoft Purview audit logging pipeline rather than the Copilot Studio service. Customer Lockbox protections don't cover it. Certain Agent 365 governance and audit events are also outside the configured Lockbox. Organizations that rely on Lockbox as part of their support-access controls should record that exception in their risk assessments.
What this means for Microsoft 365 and Power Platform admins
The decision is straightforward. If your tenant is expanding from Copilot pilots to agents that act on business data, fix permissions and set Copilot Studio data policies before you add more agents. Tenants still running a handful of chat-only pilots have time, but the oversharing cleanup is worth doing now whatever happens with agents. Caviston's final point also applies: security, data, privacy, legal and compliance teams all have a role, but he argues a named business owner must stay accountable for each agent's outcomes, because automation can take an action but cannot take responsibility for it.
- Run SharePoint data access governance reports and send site access reviews before broadening agent deployment, because agents built with Agent Builder surface whatever the user can already reach.
- Check your licence tier before planning controls: E3-class tenants get oversharing reports, sensitivity labels, audit and retention, while DLP that stops agents processing sensitive files needs E5-class licensing.
- Block Copilot Studio connectors individually, and remember that blocking the documents knowledge connector does not block SharePoint or OneDrive sources.
- Use endpoint filtering to limit agents to curated, authoritative SharePoint sites rather than letting makers ground agents on any location they can reach.
- Configure Purview Audit, Data Lifecycle Management retention and eDiscovery holds for Copilot and agent interactions as separate controls, and test that a sample agent decision can actually be reconstructed.
- Note that Copilot Studio audit telemetry and certain Agent 365 events are outside Customer Lockbox coverage if Lockbox is part of your compliance position.
Caviston's column leaves out any platform specifics and rests on one unsupported ROI statistic, but its core claim holds up in practice: an agent's reliability depends on the data it can reach and the records it leaves behind. For Microsoft customers, the controls are built into SharePoint Advanced Management, Purview and the Power Platform admin center, and the gap is usually configuration and ownership rather than missing products. His own test for moving an agent from pilot to more autonomy is whether the organization can trust the agent's data, control access to it and explain the agent's decisions. Tenants that can't pass that test yet should keep their agents in pilot until they can.