Microsoft AB-620: Security and Governance for Agents

An enterprise AI agent can retrieve information, call tools, coordinate other agents, and perform actions across business systems. Each capability creates value, but each also expands the security and governance surface. AB-620 therefore expects advanced builders to plan identity, responsible AI, security, governance, deployment, and testing as part of the solution architecture rather than as tasks delegated entirely to administrators after development.

Microsoft’s AB-620 blueprint expects candidates to plan identity strategy, evaluate security and governance constraints, consider internal and external audiences, and manage agents through solutions and Power Platform Pipelines. Deployment architecture must therefore address environments, permissions, version management, rollback, test evidence, and responsibility for production changes. A solution that runs correctly in a maker’s development environment is not automatically ready for enterprise users.

Model the agent as an application identity boundary

An agent may act on behalf of a user, through a service identity, or through a connection owned by another account. Those patterns have different security implications. The builder needs to know whose authority is applied at each integration boundary and whether that authority is narrower, equal to, or broader than the user’s own permissions.

Unclear identity design is dangerous because the conversational interface can hide privilege escalation. A user may ask a harmless-sounding question that triggers an action through a highly privileged connection. Explicit identity architecture makes those paths visible before production.

Document the identity path for every sensitive tool. If one action runs with the user’s permissions and another uses a shared service connection, that difference should be explicit in the architecture. Hidden changes of security context are difficult to review and can produce surprising authorization outcomes.

Apply least privilege to tools and data

Every knowledge source and tool should be scoped to the minimum capability the use case needs. A read-only agent should not inherit update or delete operations simply because the connector exposes them. An HR agent should not gain access to every employee dataset when its task only requires public policy information.

This is the same principle behind role-based access control. Permission should follow responsibility. The agent architecture should make it possible to explain exactly why each privilege exists and which business requirement would fail without it.

Least privilege should be revisited after launch. Teams often grant broad permissions during early development to remove blockers, then forget to narrow them before production. A release checklist that compares actual required operations with granted permissions can catch this common source of excess access.

Separate maker, administrator, and business-owner responsibilities

Advanced agent solutions involve several forms of ownership. Makers implement the solution. Platform administrators govern environments and connections. Security teams define policy. Business owners decide whether the capability remains appropriate. A production design should not assume that one person can responsibly own every decision.

Separation of responsibilities also improves change control. A maker can propose a new connector while an administrator evaluates policy impact and a business owner confirms the need. That review path is stronger than allowing technical capability alone to determine what enters production.

Use environments and DLP policy as governance boundaries

Power Platform environments separate development, testing, and production concerns and can isolate business units or risk levels. Data loss prevention policies can constrain how connectors are combined, helping prevent sensitive organizational data from flowing into inappropriate services.

These controls are important because Copilot Studio builds on the Power Platform ecosystem. Agent governance is therefore not a parallel system; it inherits many of the same environment, connector, solution, and policy concepts used for other low-code applications.

Environment strategy can reflect lifecycle and business sensitivity at the same time. A regulated workload may deserve a more restricted production environment with a narrower set of approved connectors than a low-risk internal prototype. Governance should be proportional rather than identical everywhere.

Plan responsible AI around consequences

Responsible AI planning should consider fairness, reliability, privacy, security, transparency, and human oversight in the context of the actual task. A low-impact drafting assistant and an agent that changes customer entitlements do not require identical controls because the consequences of error are different.

Human-in-the-loop flows can be valuable when an action has significant business impact or when policy requires approval. The goal is not to insert humans into every step. It is to place review where autonomous failure would be costly, difficult to reverse, or hard to explain.

Protect against unsafe action chaining

Agents can combine multiple tools in ways that create outcomes no individual integration was designed to produce. A retrieval tool might reveal data that another action then sends outside the system. A multi-agent solution can also pass context between specialized components. Governance therefore needs to consider compositions, not only isolated tools.

Builders should map data movement and action paths across the whole solution. If sensitive content can leave its original boundary, identify which policy, permission, validation, or human checkpoint prevents misuse. This systems view is more robust than approving connectors one at a time.

Action chaining also makes confirmation design important. If one request could cause several downstream changes, the user may need a summary of the intended effects before execution. Confirming only the first step can be misleading when later tools perform additional consequential work.

Use test sets to evaluate security-sensitive behavior

A test set should include more than ideal user requests. Include attempts to access unauthorized data, ambiguous instructions, malformed inputs, requests for disallowed actions, and prompts that try to redirect the agent outside its intended scope. Evaluation then becomes a way to validate security assumptions, not only answer quality.

The team should record expected behavior for those cases. If the agent should refuse, escalate, or request confirmation, make that outcome testable. Repeating the same evaluation after changes helps prevent regressions as instructions, knowledge, or tools evolve.

Use ALM to make governance repeatable

Solutions, environment variables, and Power Platform Pipelines support controlled movement between environments. They reduce hard-coded configuration and make deployment more repeatable. Governance becomes stronger when promotion to production follows a known process rather than a sequence of manual edits performed by one maker.

ALM also creates natural checkpoints for review. A new version can be tested, approved, and promoted with evidence attached to the release decision. That process is especially important when an agent has external integrations or action-taking capabilities.

Versioning helps incident response as well. When a new release introduces unexpected behavior, a team that knows exactly what changed can roll back or isolate the regression. Manual, undocumented edits in production make both security review and recovery slower.

Monitor and retire capabilities that no longer fit

Security posture changes over time. A connector that was appropriate last year may expose data that is now regulated. An agent owner may leave the organization. A business process may be replaced. Governance therefore needs monitoring, periodic review, and a retirement path rather than assuming that approval is permanent.

For AB-620 scenarios, choose controls that follow the lifecycle of the solution. Identity, policy, testing, deployment, monitoring, and retirement are connected. The strongest answer usually protects the capability at the layer where the risk is introduced while preserving legitimate value for the intended users and the broader Microsoft agent administration model.

Periodic review should look for dormant connections, unused tools, stale knowledge sources, and owners who no longer hold the relevant role. Removing unnecessary capability shrinks the attack surface and simplifies future audits. Governance is strongest when the deployed system reflects current need rather than historical accumulation.

Governance should also address secrets and connection material. API keys, tokens, and other credentials should not be embedded in prompts, topic text, or hard-coded configuration that makers can copy casually between environments. Use platform-supported connection and secret-management patterns, restrict who can update them, and make rotation possible without rebuilding the agent. A solution that protects user data but exposes its own credentials is not secure.

External audiences require an especially careful threat model. An internal agent can often assume organizational identity and established policy, while a customer-facing agent may receive untrusted input from anyone. Input validation, rate controls, restricted tools, clear authentication, and narrow data access become more important as the trust boundary expands. The design should state which threats are expected and which layer mitigates each one rather than relying on a generic instruction to behave safely.

A mature governance review asks whether controls still match capability. If a later release adds computer use, a new API, or multi-agent delegation, the previous approval may no longer cover the expanded risk. Changes that increase autonomy, broaden data access, or add external effects should trigger targeted reassessment. This keeps governance connected to what the agent can actually do instead of treating certification or approval as a permanent property of the original version.

Security documentation should be understandable to people beyond the original builder. Record the agent’s audience, data sources, tools, identities, environment, privileged operations, approval requirements, and monitoring plan in a form that administrators and risk owners can review. Clear documentation turns governance from a verbal promise into an inspectable design and makes future changes easier to compare with the controls that were originally approved. Include an explicit process for revoking access when an agent changes owner, connector, environment, or approved business purpose.