Microsoft AB-100: Agent Security and Governance

Security in AB-100 extends beyond protecting a model endpoint. Enterprise agents can read sensitive data, call tools, act through connectors, collaborate with other agents, and make decisions that influence business systems. That means the architecture must govern identities, data, tools, models, prompts, environments, and operational behavior together. A secure agent is not merely one with authentication; it is one whose authority is deliberately bounded and whose actions can be traced.

Microsoft’s announced blueprint explicitly includes agent security, agent governance, model security, prompt-manipulation risks, access controls on grounding and tuning data, data residency, and audit trails. Those topics should be treated as one control system. A weakness in any layer can undermine the rest: strong user authentication does not help if an agent tool has excessive application permissions, and a well-governed connector does not help if grounding exposes information the user should never see.

Give every actor a clear identity and authority boundary

Start by identifying the actors in the architecture: end users, agents, service principals, connectors, MCP servers, downstream APIs, and administrators. Decide when an action should execute with the user’s delegated authority and when an application identity is necessary. Shared credentials make it difficult to attribute actions and often grant more permission than the business task requires.

The move to Microsoft Entra ID is useful context because enterprise agent governance increasingly depends on centrally managed identities. Apply RBAC so that both human and nonhuman actors receive only the roles they need. The design should be able to answer who performed an action, under which identity, and which policy authorized it.

Apply least privilege to tools, connectors, and actions

Tool permissions deserve the strictest review because tools can create irreversible effects. Expose narrow operations with validated schemas instead of generic administrative endpoints. If an agent only needs to submit a draft record, do not give it permission to delete records or modify unrelated fields. If an action has financial or legal impact, consider an approval or step-up control before execution.

Least privilege should be enforced by the downstream system as well as by the agent configuration. Prompt instructions such as ‘never delete data’ are not access controls. A model can misunderstand or be manipulated; the service receiving the request must reject operations outside the authorized contract.

Secure grounding and business data separately from the model

Grounding repositories, indexes, Dataverse tables, SharePoint sites, and external systems all have their own authorization models. Preserve those boundaries in retrieval. If the agent can see data that the user cannot, the model can accidentally reveal it even if the final response is filtered. The safest design prevents unauthorized content from entering model context in the first place.

Controls such as Conditional Access can strengthen user and service access in the broader identity plane. For AB-100 scenarios, translate the concept into architecture: access should depend on identity, resource sensitivity, role, device or session conditions where relevant, and the specific business operation being requested.

Use data policies and environment governance to limit sprawl

Copilot Studio and Power Platform make it easy to connect systems, which is precisely why governance is necessary. Data loss prevention policies can restrict which connectors may be combined. Environment strategy can separate experimentation from regulated production workloads. Maker permissions, publishing rights, and solution ownership should be defined before the number of agents grows.

The administrative fundamentals behind AB-900 are adjacent to this problem. AB-100 candidates should think beyond one agent and design a governance model that scales across departments, channels, and environments while keeping ownership and policy enforcement visible.

Defend against prompt manipulation and untrusted content

Prompt manipulation can arrive through a user message, retrieved document, web content, tool output, or another agent. The architecture should separate trusted instructions from untrusted data, validate tool parameters, constrain capabilities, and use content or policy controls appropriate to the scenario. The model should never be the only enforcement layer for a high-impact rule. The MCP and A2A interoperability model is relevant because protocol-level connectivity cannot give untrusted content or agents new authority.

Assume that an attacker will try to convince the agent to reveal system instructions, bypass policy, access data outside scope, or invoke a privileged action. Test those boundaries explicitly. A secure design fails closed when authorization is ambiguous and provides a safe escalation path instead of guessing.

Treat models and agent components as a supply chain

Models, connectors, custom actions, MCP servers, prompts, libraries, and knowledge sources can all change independently. Maintain inventories and owners for those dependencies. Review third-party terms, hosting, data movement, update behavior, and incident-response expectations before introducing them into a production agent path.

Model security also includes access to deployment configuration and tuning data. Limit who can replace a model, change routing, alter safety settings, or modify tuning datasets. Those changes can materially alter behavior without changing the visible agent interface, so they need approval and audit trails comparable to other production configuration changes.

Centralize audit and incident evidence

A production agent should generate evidence sufficient to investigate who used it, what action was attempted, what tool or model was involved, and whether a policy blocked or allowed the operation. Avoid storing unnecessary sensitive content in logs, but do not design a system that is impossible to reconstruct after an incident.

A structured risk register can help connect technical controls to business impact: unauthorized data exposure, excessive autonomy, compromised connectors, model misuse, and data-residency violations are different risks and need different owners and mitigations. Governance becomes practical when those risks are tracked rather than described only in policy documents.

Use governance to enable safe scaling, not to stop delivery

Good governance creates approved patterns, reusable environments, identity standards, connector policies, testing requirements, and monitoring expectations so teams can deliver faster without renegotiating every control. A center of excellence can publish reference architectures and escalation paths while business teams retain ownership of their processes.

For AB-100, prefer answers that combine preventive controls with visibility and lifecycle management. The goal is not to make agents powerless. It is to ensure that greater autonomy is matched by stronger identity, least privilege, validation, monitoring, auditability, and human oversight where consequences justify it.

Define a governance lifecycle from intake to retirement

Governance starts before development. Require a lightweight intake that records the business owner, purpose, users, data classes, tools, autonomy level, expected value, and regulatory concerns. Route high-risk designs through security or compliance review while allowing low-risk internal assistants to follow a simpler path. This risk-based model avoids treating every agent as equally sensitive while still creating visibility across the portfolio.

At retirement, disable triggers, revoke identities, remove connectors and secrets, archive required audit evidence, and delete or decommission unused knowledge stores according to policy. Abandoned agents with live credentials are a governance failure even if nobody remembers how to invoke them. Lifecycle controls should therefore cover creation, change, suspension, and retirement.

Use central policy without erasing workload accountability

Central teams can define mandatory controls such as approved regions, connector restrictions, identity standards, logging requirements, and production-release gates. Workload teams should still own the business rules, data quality, risk decisions, and operational outcomes of their agents. Governance fails when every decision is centralized so far from the process that nobody can respond quickly to changing business needs.

A useful model is guardrails plus accountability: the platform prevents prohibited patterns, while the business owner documents accepted residual risk and proves that the solution meets required controls. This lets the organization scale safely without turning the center of excellence into a bottleneck for every prompt or workflow change.

Protect privileged administration and maker paths

A secure runtime can still be compromised through weak administration. Limit who can create production connections, change environment policy, modify prompts, publish agents, rotate secrets, or alter model routing. Use separate privileged roles and review them regularly. Maker convenience in development should not translate into broad production administration.

Administrative interfaces and deployment automation should also generate audit evidence. High-impact changes need enough history to answer who changed the agent, which component changed, what validation occurred, and when the new version became active.

Plan containment for compromised or misbehaving agents

Assume that one day an agent, tool, or external dependency will behave unexpectedly. The operating model should allow teams to disable autonomous triggers, revoke credentials, block a connector or MCP server, remove a channel, or roll back a version quickly. Containment should not require rebuilding the entire platform under incident pressure.

Practice those actions before they are needed. A governance document that says ‘disable the agent’ is incomplete if nobody knows who has permission or how long the action takes. Security architecture includes the ability to reduce blast radius during a live incident.

Governance also needs periodic access recertification. Agent identities, maker roles, connector permissions, and shared environment memberships can accumulate long after the original project changes. Schedule reviews based on risk, remove stale ownership, and verify that high-privilege actions still have a business justification. The result is a security model that remains least-privileged over time instead of only on launch day. This matters especially for autonomous agents, because a dormant privilege can become consequential as soon as a trigger or workflow is reactivated.