An agent that reads documents, calls tools, or updates records can affect far more than the quality of a response. Its identities, information sources, and permitted actions determine the real security boundary. Start with what the agent can reach and change, then decide how that access should be controlled.
Make the agent estate visible and owned.
Record each agent's purpose, business owner, technical owner, connected systems, and permitted actions. Use Agent 365 to support inventory, lifecycle management, and oversight across supported integrations. Validate what your configuration can discover and manage; an inventory is not proof that every agent or tool is covered.
Give owners a review process for new connections, permission changes, and retirement. A dormant agent with valid credentials is still an access path. Removing an agent should include revoking its access and addressing retained data, not simply hiding it from a catalog.
Separate identity from intent.
A well-written instruction does not enforce authorization. Use Entra identity and access controls to limit supported access paths. Distinguish work performed on behalf of a signed-in person from work performed under an application's own identity. Avoid broad shared credentials and ensure access is checked when a tool executes.
Keep reading, proposing, and executing separate wherever their consequences differ. Updating a customer record, sending an external message, or changing a security setting should require the authorization appropriate to that action. The agent's own recommendation must not count as independent approval.
Protect the information before connecting it.
Review source ownership, oversharing, classifications, and permitted use. Purview can support discovery, information protection, and supported data controls, but enforcement varies by workload and integration. Test what the agent can retrieve and disclose rather than assuming every connector handles protected information identically.
Treat retrieved documents and tool responses as untrusted input. Content that asks an agent to ignore instructions, reveal information, or take an unrelated action should not acquire authority because it came from a connected source.
Test the full path from request to action.
Use representative tasks alongside denied access, misleading content, unavailable tools, and failed approvals. For Model Context Protocol (MCP) servers, verify server trust, tool scope, identity handling, and input validation. MCP standardizes connections; it does not replace authorization or secure implementation.
Evaluate whether the agent stops safely and whether attempted actions leave useful evidence. Set release criteria before a pilot begins, and repeat the evaluation when models, knowledge, tools, or permissions change.
Connect oversight to a response plan.
Define who investigates unexpected access, disables a risky integration, and restores approved operation. Use relevant Defender XDR and Sentinel signals where coverage is supported. Keep necessary investigation evidence without indiscriminately storing sensitive prompts and responses.
Start with one agent and a bounded set of tools. Agree ownership, access, evaluation, and incident procedures before extending autonomy. Product availability, licensing, and integration support determine which controls can be implemented.
Further reading
Agent 365 overview
Security for AI
Define boundaries and decision rights for AI