An AI agent with access to business applications is more than a chat interface. It can retrieve sensitive information, call tools, and take actions inside processes that matter to the organization. Microsoft's November 10, 2026 Partner Center announcement asks partners to turn that risk into a concrete customer security discussion.
The announcement highlights Microsoft's extension of Project Perception to address the “agentic insider” and describes Guardian Agents supervising agent actions as risk changes. For partners, the practical opportunity is an assessment that connects agent discovery, identity, permissions, data protection, and security operations—not simply another AI awareness presentation.
What Microsoft is announcing
Microsoft describes an approach built around deterministic controls, independent evidence, and containment boundaries surrounding non-deterministic intelligence. In practical terms, an agent's own reasoning should not be the only mechanism deciding whether its next action is acceptable.
The announcement assigns four continuous responsibilities to this security model:
- Know: Understand which agents exist, their owners, their purpose, and their activity.
- Contain: Limit what each agent can access and do before it acts.
- Protect: Secure the data, tools, runtime, infrastructure, and systems involved.
- Adapt: Adjust protection as behavior, context, and risk change.
Microsoft says Guardian Agents in Project Perception supervise agent actions and respond in real time as risk increases. That is the stated direction of the approach. The Partner Center notice does not, however, provide a deployment guide, licensing terms, or a complete availability matrix.
Why this changes the customer conversation
Traditional security discussions often begin with a compromised account or malicious actor. Agent risk also includes an authorized system taking an inappropriate action without being compromised.
Consider an agent asked to resolve a customer issue. Depending on its permissions and connected tools, it might be able to retrieve account details, change a record, issue a refund, or send a message. A legitimate task can still result in an unintended action if the agent misunderstands context or operates beyond the intended scope.
This example is illustrative, not a reported Microsoft incident. It shows why the assessment must examine both access and action. Knowing that an agent can read a dataset is useful; knowing whether it can export that data, share it externally, or change the system of record is often more important.
No automatic protection change is specified
The announcement is a partner advisory, not a notice that new controls have automatically been enabled for every customer. It does not specify a tenant-wide default change, a mandatory rollout date, or a guarantee that existing agents are now supervised by Guardian Agents.
Partners should therefore distinguish Microsoft's security direction from protection verified in a customer's environment. Do not tell customers they are covered simply because they use Microsoft technology or have begun deploying agents.
Before proposing a product-specific implementation, validate current availability, supported scenarios, prerequisites, and commercial terms. An assessment can begin immediately using the customer's existing controls, without making unverified promises about future capabilities.
Start with an agent inventory that supports decisions
A useful inventory goes beyond a list of agent names. Record an accountable owner, business purpose, execution environment, connected tools, identity model, and the systems or data the agent can reach.
Then identify the actions it can perform. Read-only retrieval, external communication, record modification, and financially significant operations create different risks. Include agents under development where they already have access to real customer or business data.
The output should help the customer prioritize. An agent with limited access to public information is not the same assessment priority as one that can change sensitive business records using broad application permissions.
Translate the four responsibilities into assessment work
Know: verify ownership and observability. Check whether the customer can identify active agents and connect their actions to a responsible team. Review what activity is logged and whether investigators can reconstruct important events.
Contain: test permissions and action boundaries. Review service identities, delegated access, credentials, and tool permissions. Recommend least privilege and appropriate approval gates for higher-impact actions. Where possible, enforce boundaries outside the agent's own instructions rather than relying on a prompt that tells it to behave safely.
Protect: examine the full execution path. Review the information sources, APIs, tools, runtime, and infrastructure an agent uses. Consider data handling, secret management, access controls, and failure behavior. A well-configured model does not compensate for an overprivileged tool connection.
Adapt: connect evidence to a response process. Agree who investigates unusual behavior, when an agent should be paused, and how access can be revoked. Changes to tools, permissions, or business purpose should trigger reassessment rather than silently expanding the original approval.
These are recommended assessment activities derived from the announced principles, not a claim that Microsoft automatically implements each control for every customer.
Give the customer a usable deliverable
An effective engagement should end with an owned inventory, a prioritized risk register, and a remediation plan. Each significant finding should identify the affected agent or integration, the business consequence, the proposed control, and the team responsible for follow-through.
Bring security, IT, data, and AI stakeholders together early. Business owners should also participate where agent actions affect customer commitments or critical operations. That prevents a technically sound control from becoming an impractical operating model.
For further context, partners can review the Official Microsoft Blog announcement and the Microsoft Security Blog discussion.
Bottom line
The immediate partner action is to identify customers whose agents can access sensitive data, business applications, tools, or critical processes, then offer a focused security assessment. Use Microsoft's four responsibilities as a structure, but ground every recommendation in verified customer access, actual agent behavior, and controls that can be enforced independently of the agent itself.