AI Agents Are Now Part Of The Attack Surface

Consider a procurement agent asked to summarize an approved supplier contract and email the account contact a delivery update. It can read contracts in SharePoint and send messages through a connector. During retrieval, it encounters a document an attacker has altered to include instructions to find internal pricing assumptions and include them in the email. If the agent follows those instructions, its next message could disclose the company’s negotiating position to the supplier. 

The user requested a delivery update. The agent used its authorized access to produce something else. This is a hypothetical incident, but it exposes a concrete weakness in reviewing agent permissions one at a time: permission to read a file and permission to send an email can combine into a disclosure nobody approved. 

That combination should be the center of the security review. An agent’s risk depends on what its identity, data access, tools, and autonomy allow it to do together. A legitimate sign-in and a permitted tool call do not establish that the resulting action serves the user’s intent. 

Small Permissions Can Combine Into A Large Outcome 

In this scenario, identity determines whose authority the agent uses. Data access determines whether it can retrieve the pricing assumptions. The email connector supplies a route to the supplier, while autonomy determines whether the agent can send the message without review. Restricting any of those elements can change the outcome, which is why approving each in isolation leaves an important part of the risk unexamined. 

An agent acting on behalf of a user may stay within that user’s access and still retrieve information irrelevant to the request. An agent using application permissions or a separately authenticated connector may have a different reach. Follow the identity through each connection before assuming the requesting user’s permissions define the boundary. 

I would review each agent as if it were a privileged workload, especially where it can read sensitive data and take action. That doesn’t mean granting it elevated rights or assuming every agent has its own identity. It means evaluating its possible consequences and requiring an accountable owner before expanding its authority. 

Oversharing Gives The Agent More To Work With 

The pricing document does not have to be newly exposed for this incident to work. It may already be available through an inherited SharePoint permission or a group that grew beyond its original purpose. The agent makes that access easier to use by finding and combining information the requester may never have opened manually. 

A salary spreadsheet accessible to an overly broad SharePoint group illustrates the same problem. An agent might retrieve salary information while answering an unrelated staffing question without bypassing any permission check. The access was already wrong; retrieval makes the consequences more immediate. Add a connector that posts the answer to a wider audience and the exposure moves beyond the original repository. 

Prompt instructions cannot repair those permissions. Review the sources an agent can reach and the audiences its outputs can reach together. A repository may be appropriate for internal analysis and inappropriate as source material for an automated external message. 

Work Backward From The Unintended Email 

Start with the last step in the procurement incident: sending the message. If the business need is drafting, remove autonomous send permission. If sending is required, constrain recipients and require approval for sensitive content or consequential changes. The reviewer needs to see the destination, proposed message, and relevant source material. An approval button without that context invites routine acceptance. 

Then examine retrieval. The agent should have access to the contract and delivery information needed for its job, with internal negotiating material excluded unless the use case justifies it. Enforce that boundary through source permissions and tool authorization where possible. A request to “use only the approved library” is not equivalent to preventing access elsewhere. 

Finally, examine the instruction that changed the task. Retrieved documents and tool responses are untrusted content. Test whether instructions embedded in them can redirect the agent, broaden a search, or trigger an unauthorized business outcome. Use synthetic sensitive values in an isolated test environment and capture both the attempted action and the control that stopped it. Passing one prompt-injection test does not establish that the boundary will hold across different documents and tool responses. 

These restrictions have costs. Narrower retrieval may omit useful context, and human approval adds delay. Choose those costs against the consequence of failure. A delivery draft and a message disclosing contract terms warrant different levels of autonomy, even when they use the same connector. 

Make The Microsoft Controls Answer To This Incident 

In a Microsoft environment, Agent 365 can help connect agent visibility and governance with Entra, Purview, and Defender. Apply that stack to the procurement workflow with a specific question at each point: what would stop the pricing document from becoming an external email? 

Use Microsoft Entra to examine the identity and permissions behind retrieval and the connector. Confirm whether each action uses delegated access or application authority, then narrow unnecessary grants. Agent 365 provides a place to establish agent visibility and ownership, but the review still needs a person who can explain why this agent may send externally and coordinate access removal when the use case ends. 

Use Microsoft Purview to assess sensitive information exposure and apply labeling, data loss prevention, and audit controls where the workflow supports them. For this incident, test the actual path from the SharePoint document to the outbound message. A label or policy existing in the tenant does not prove that a particular connector will enforce the desired restriction. 

Use Microsoft Defender to bring supported agent posture findings and suspicious activity into the security operations center. If the email is sent, investigators need to connect the originating request with the agent identity, retrieved documents, connector call, recipient, and result. Combine the available identity, data, and runtime records; do not assume one alert or audit event contains the entire chain. 

Product coverage depends on licensing, agent type, integration, and configuration. Establish the required control first, then verify that the deployed workflow enforces it. Where coverage is incomplete, reduce the agent’s permitted actions or add an enforceable control in the application. Central visibility alone does not close the gap. 

Five Questions To Ask About The Combined Access  

Use the incident above as a short review with the business owner, identity team, data owner, and security operations team. Ask for evidence from the deployed agent: 

1. What sensitive information can this agent retrieve that its usual task does not require? 
   
2. Which tool could move that information to another audience or use it to change a business record? 
   
3. What prevents that action if a retrieved document redirects the agent? 
   
4. Can we reconstruct one completed request from retrieval through its final action? 
   
5. Who can stop the agent and its connected access, and when was that shutdown path last tested? 

Trace One Agent Before Expanding Its Authority 

Pick one agent that can both retrieve sensitive information and act through a connector. Have its owner and the security team trace a normal request, identify the data and destinations it can reach, and run a controlled test that attempts to redirect the workflow. Record which control blocks the unintended action and what evidence remains. Include credentials held by connectors in the shutdown test, since disabling the agent may not revoke every downstream session. 

If the team cannot demonstrate the boundary, keep the agent at a narrower scope, such as drafting with human review, until it can. That gives the next deployment decision a concrete basis: the organization has tested what this agent can do with its permissions combined. 

Secure AI Agents Before You Scale

Understand how your agents’ permissions, data access, and connected tools create risk. eGroup’s AI Operational Framework helps you establish the governance, ownership, and security controls needed to scale AI responsibly.