*This is post 3 of 6 in Avertium's "The Trust Problem in Enterprise Security" blog series
By Sarah Clarke, Consultant - QSA and AI Architect
In February, Microsoft pushed a worldwide configuration update for Microsoft 365 Copilot after finding that the chat feature could summarize emails labeled confidential. The labels existed and the DLP policies were in place. Microsoft's statement said access controls and data protection policies remained intact. The behavior was nonetheless "not what we intended." A separate January incident, tracked internally as CW1226324, involved Copilot's work tab returning content that DLP rules had been configured to block.
Both incidents have the same shape. The labels were the scope boundary an organization had drawn, and the agent didn't honor them.
Vulnerability scanners can't catch this failure mode, and scoping diagrams don't capture it either, because the agent isn't a system, it's an identity that operates on top of every other system it touches. From the assessor side of the table, this is where the scope question gets interesting.
When a user enables Copilot in their tenant, or when a team wires an AI agent into Slack, Salesforce, or a code repository, the act looks like a checkbox or an OAuth consent screen. Underneath, the system issues a credential ( a service principal, an OAuth token, an API key) that grants the agent some scope of access on behalf of a user or service. That credential is almost always issued by the IdP. The previous post named the IdP as the attack surface; everything in that post about IdP compromise applies here too.
The agent then operates with that access continuously, at search speed, across every file, message, record, and table the credential reaches.
That last detail is the one most permission models were not designed for. Human users access data one file at a time, with context and intent. Agents work differently: in bulk, recombined, retrieved by similarity, summarized into outputs that no policy on the source data anticipated.
The January and February Copilot incidents illustrate this. The label said "confidential" and the policy said to exclude that content from automated processing. The agent's effective access didn't honor the boundary, because it was reading the data through a credential issued for a different purpose, and the label was metadata the retrieval pipeline didn't consistently enforce.
Every connector, data source, and tool you give an agent is a scope decision. Almost nobody is treating it that way.
Under PCI DSS 4.0, anything that stores, processes, or transmits cardholder data is in scope. That includes AI agents. If a Copilot tenant can read into a SharePoint library containing cardholder data, the Copilot tenant is in scope. A custom-built agent with retrieval permissions over a database holding tokenized card data pulls the retrieval pipeline in too. The model provider, the orchestration layer, and any logging that captures prompts with scoped data all land in the assessment.
HIPAA reaches similar conclusions through different language. An agent that reads ePHI is processing ePHI by HIPAA's definition. The infrastructure running it inherits the same status. And depending on the deployment, the model vendor may be a business associate. This doesn't require the agent to be doing anything exotic, just giving it access to data that's already regulated.
A word of caution: The "I just enabled it for productivity" defense doesn't survive an audit. The scope is whatever data the credential can reach, regardless of what the user thought they were enabling.
Here's a list of questions I find myself asking in engagements right now. Most environments can't answer them confidently:
The last one matters more than it looks. PCI DSS 4.0 has steadily tightened on documented access justification and approval, and the same principle is showing up in updated HIPAA proposals and in mature SOC 2 reports. An assessor's job is to verify a documented justification for every access grant. If nobody can produce one, that's the finding, even if the agent never did anything wrong.
The architecture problem here is that agents don't fit neatly into either the "user" or "system" buckets that most access models assume. They behave like users when reading and recombining data, but they hold the kind of continuous, scaled access that's usually granted only to systems. A few patterns are worth building toward:
Most of this is the same identity, classification, and audit discipline that mature programs apply to service accounts and integration users. The AI layer is just where that discipline is currently weakest, with the volume of new identities growing faster than anywhere else.
Here’s an AI-agent scope exercise. No tooling required.
1. Build a list of evert AI-agent or AI-enabled feature that has access to organizational data:2. Draw four columns
3. For each AI agent, write four things:
Most organizations will discover that the fourth column is empty for almost every entry. The agents got enabled but nobody wrote down why, and the scope of regulated data they touch grew without anyone making a deliberate decision about it.
That's the artifact an assessor will eventually ask for. Building it before someone asks is much easier than building it under audit conditions.
Stay tuned for our fourth post in the series, ”The Vendor Concentration Risk No One Models,” which will publish on June 24, 2026 at 10:00 am EST.