Plan identity, governance, security, and responsible AI
With interaction patterns assigned and channels selected, the solution design has a clear picture of how each agent engages and where its authority ends. What it doesn’t yet have is a clear picture of who each agent is and what it’s permitted to do: choosing an identity model, placing guardrails, building governance into the lifecycle, and documenting responsible AI posture at design time rather than after the first incident.
Choose an identity model for each agent
On Microsoft's platform, agents are given a dedicated identity through Microsoft Entra Agent ID — the identity framework agents use to authenticate and access resources across the tenant. At design time, your first decision is whether the agent operates interactively on behalf of a signed-in user, or autonomously using its own identity.
The interactive pattern applies when the agent acts on behalf of a signed-in user. The agent uses delegated permissions scoped to what that user is authorized to see and do. A customer-facing front-door agent uses this pattern: it operates within the context of the user’s session, accessing only that user’s records and account data.
The autonomous pattern applies when no user is present. The agent uses its own identity with admin-consented application permissions, appropriate for background tasks or system-to-system operations. A backend specialist agent invoked via A2A (never directly by a human user) uses this pattern. A workflow automation agent that processes records on a schedule, categorizes requests, and routes outcomes independently of any user session also uses the autonomous pattern.
Some agents need both patterns. The design decision is which pattern applies to which operation, not which single pattern defines the entire agent.
Once the operation pattern is decided, three additional planning decisions follow before any agent is created:
Agent's user account: Some systems require a user object to authenticate — shared mailboxes, meeting scheduling, and file sharing on behalf of a team are common examples. For those scenarios, an autonomous agent needs an agent's user account paired with its identity. Add one only when the scenario genuinely requires it, because agent's user accounts introduce licensing and user-level policy complexity.
Identity blueprint: An agent identity blueprint is a template that specifies the permissions, metadata, credential model, and sponsorship structure for every agent of a given type. Define the blueprint up front and you make identity decisions once — at the design level, not repeated for each new deployment. Every blueprint requires a sponsor — the person accountable for the agent's purpose — assigned at creation.
Least privilege: Assign only the permissions each agent needs for the tasks it actually performs. Several high-privilege directory roles are blocked for agent identities by platform policy. Apply the same principle to every permission decision, not just the ones the platform enforces.
Secure inputs, outputs, and tool calls
The most effective guardrails aren't applied everywhere. Place them where this specific agent can actually go wrong. There are four intervention points in an agent's processing pipeline where controls can be applied. The planning question isn't which controls exist. It's where the risk lives for this agent.
| Intervention point | Failure mode | Highest exposure |
|---|---|---|
| User input | Jailbreak: input crafted to make the agent ignore its instructions and take actions outside its defined scope | Agents receiving unfiltered input from external users: customer channels, public web portals, open API endpoints |
| Tool call | Prompt injection in outbound arguments: steering the agent into harmful content or unintended endpoint calls | Agents constructing outbound messages, triggering external workflows, or writing records to business systems |
| Tool response | Indirect prompt injection: malicious instructions embedded in retrieved documents or search results that redirect agent behavior | Agents retrieving content from knowledge bases, document stores, or web sources |
| Output | Harmful content, personally identifiable information, and protected material in responses | All agents, with highest exposure for external-facing agents and those processing sensitive data |
Not every agent needs every control at every intervention point. An agent reachable only via authenticated A2A calls carries a different input-risk profile than one exposed directly to external users. Size guardrail coverage to the agent's actual exposure. Each active control adds processing time to every interaction, so over-configuring costs performance without proportionally improving safety.
Plan governance into the agent lifecycle
Governance isn't only about what an agent can do in a given moment. It's about who reviews its access, what triggers its retirement, and how the organization stays in control as the agent fleet grows.
Microsoft Entra Conditional Access applies to agent identities similarly to how it applies to user identities, with some key differences: policies are configured at the blueprint level (affecting all agent identities created from it), and the conditions evaluated reflect service identity behavior rather than interactive user sign-in. Plan for policies that target agent identity categories and include agent-risk conditions: if an agent's identity is flagged as high or medium risk by identity protection signals, a block policy stops authentication until the risk is resolved. Design these policies before the agent reaches production, not after a suspicious event prompts the question.
Access reviews are the mechanism for lifecycle accountability. Define a review cadence at design time: for example, a quarterly attestation by the agent's sponsor confirming that the agent's permissions and scope remain appropriate. Define deprovisioning triggers as well: what happens when the use case ends, when the sponsoring team changes, or when the agent's performance falls below the metrics established in Unit 2? An agent without a deprovisioning trigger doesn't get retired. It gets forgotten. When you register agents in Microsoft Agent 365, they appear in the tenant's agent catalog and inherit org-wide governance policies — making the catalog the natural home for the lifecycle metadata you're defining here.
Document your responsible AI posture at design time
Responsible AI planning converts Microsoft's six principles into design questions specific to this agent. The principles are fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability. For each one, the question isn't "are we compliant?" It's "what does this agent do that could create a problem here, and what does the design do about it?"
- Fairness: Could the agent's categorization logic or escalation routing systematically disadvantage certain user groups? If the model reflects patterns from historical data that embed bias, those patterns play out across every interaction at scale.
- Reliability and safety: What are the failure modes, and how does the design contain them? An agent that miscategorizes a safety complaint as a routine request has a safety failure, not a quality gap. Define failure modes before building.
- Privacy and security: What personal data does the agent handle, and how is it protected in transit and at rest? An agent processing customer names, account details, health information, or financial data carries privacy obligations that shape its architecture, not just its compliance documentation.
- Inclusiveness: Can all intended users interact with the agent effectively? Channel, language, and accessibility decisions from the previous unit directly affect whether the agent serves its full intended population.
- Transparency: Do users know they're interacting with an agent? Can a reviewer understand why the agent took a specific action? Transparency isn't a statement in a compliance document — it's a design requirement. Plan how users learn they're interacting with an agent, and what audit trail exists when something goes wrong. Conversation transcripts and activity logs are built into the platform, but deeper visibility into the agent's reasoning — which knowledge sources it considered, why it routed a case a certain way — requires deliberate choices about telemetry and logging at design time.
- Accountability: Who is responsible when the agent produces an incorrect output or routes a sensitive case to the wrong queue? Document the remediation process and accountable person before the first incident.
Responsible AI and governance belong in the same design artifact. The solution design that stakeholders review and sign off on should include responsible AI posture alongside identity decisions, guardrail placements, and lifecycle triggers. Capturing these answers at design time means they don't surface for the first time in a post-incident review.
Apply it: Think of an agent you're designing. Which operation pattern does it use, and where is its highest-risk intervention point — the place where a guardrail would matter most?