Use access packages for governed agent access

Microsoft Entra Agent ID governance series introduces access packages to grant approved, time-bound access to AI agents. Access packages ensure agents receive intentional, auditable permissions with approval and expiry controls, moving away from permanent ad hoc assignments. The approach requires agents to be classified, accountable, and approved before receiving durable access.

This article is part of a multi-part series on Microsoft Entra Agent ID governance. For the full sequence and recommended reading order, start from the Governing AI agents with Microsoft Entra Agent ID and Agent 365 https://dev.to/stepbysteptocloud/governing-ai-agents-with-microsoft-entra-agent-id-and-agent-365-3a7g Conditional Access helps decide whether an approved agent can access a resource under the right policy conditions . Access packages answer a different question: what access should the agent receive, who approves it, and how long should that access remain valid . This is the right next step after inventory, classification, owner/sponsor cleanup, custom security attributes, and Conditional Access policy design. At this stage, the organisation should already know which agents are approved, who is accountable for them, what access pattern they use, and what sensitivity or business criticality applies. Access packages should not be used for every discovered agent. They are most useful for approved agents that need durable access to resources such as groups, Microsoft Entra roles, or API permissions. The aim is to avoid permanent, ad hoc permission assignments and move toward access that is intentional, approved, auditable, and time-bound. Agents may need access to resources to complete business tasks. For example, a fleet of customer support agents may need access to the same set of groups, APIs, or directory roles. Without a governed access model, those permissions can become difficult to track, review, and remove. Access packages provide a structured way to grant access with governance controls around: This is especially important for agent identities because they may continue operating without day-to-day human interaction. Access should therefore be granted with clear purpose, expiry, and review expectations. Access packages should come after the agent has already passed the earlier governance checks. | Stage | Purpose | |---|---| | Inventory | Identify the agent and its source platform | | Classification | Understand identity model and access pattern | | Owner and sponsor assignment | Establish technical and business accountability | | Custom security attributes | Record governance metadata like approval status and sensitivity | | Conditional Access | Enforce access policy based on identity, risk, and attributes | | Access packages | Grant approved, time-bound access to required resources | | Lifecycle workflows and monitoring | Keep sponsorship, access, and risk posture current | The key point is simple: do not grant durable access to an agent until it is classified, accountable, and approved . Access packages are useful when approved agents need access to defined resources rather than broad standing permissions. Common examples include: This makes access packages suitable for repeatable access patterns. For example, if several approved agents need the same type of access, create a standard access package instead of assigning permissions manually to each agent. Start with a small number of meaningful access packages rather than creating many narrowly scoped packages too early. | Design area | Recommendation | |---|---| | Scope | Use access packages only for approved agents with known purpose and accountability | | Resources | Include only the resources the agent needs for the defined scenario | | Approval | Route approval to the sponsor, resource owner, application owner, or security governance team | | Expiry | Make assignments time-bound by default | | Extension | Require re-approval or extension review for continued access | | Auditability | Ensure assignments and approvals can be reviewed later | | Naming | Use names that explain the agent scenario and access purpose | Example naming pattern: The name should help an administrator quickly understand who the access is for, what it grants, and whether it is production or review-based . Access packages can support different assignment paths: | Assignment path | When it makes sense | |---|---| | Agent identity requests access | Useful for programme-driven or automated access request scenarios | | Sponsor requests access for the agent | Useful when human oversight is required before the agent receives access | | Administrator directly assigns access | Useful for controlled rollout, pilot, or emergency remediation scenarios | The sponsor-based model is especially valuable. It keeps a human accountable for why the agent needs access and whether that access should continue. Access packages should not create permanent access by default. The value comes from giving access a lifecycle. When an access package assignment has an expiry date, the organisation can review whether the agent still needs that access. If the sponsor remains accountable and the access is still valid, an extension can be requested based on policy. If no action is taken, the assignment expires and the agent loses access to the target resources. This is a clean governance pattern for agents because access does not remain forever simply because it was once approved. Access packages are powerful, but they should be used carefully. Do not use access packages as a shortcut to approve unknown agents. If the agent source, identity model, business purpose, owner, sponsor, or access pattern is unclear, keep the agent in ReviewRequired state. Also avoid reusing access packages that were originally designed for human users if the resource roles or approval model do not fit agent identities. Agent access packages should be designed with agent scenarios in mind. Key checks before using access packages: If the answer is unclear, the access package design is not ready. A practical access package operating model for agents can look like this: This keeps access aligned to business purpose and reduces long-term permission drift. | Scenario | Access package idea | |---|---| | Customer support agents | Standard access to support knowledge groups and approved APIs | | Security operations agents | Time-bound access to investigation-related resources | | Finance automation agents | Controlled access to finance processing groups or APIs | | HR assistant agents | Access only to approved HR resources with stricter review | | Test or sandbox agents | Limited non-production access with short expiry | The design should follow least privilege. Agents should receive only the access needed for their approved scenario. Once access packages are in place, the next concern is lifecycle. Agents may be approved today, but sponsors can change roles, leave the organisation, or stop being accountable for the agent. If sponsorship becomes stale, access decisions become stale too. That is why the next phase is Lifecycle Workflows for sponsor continuity . Access packages govern what the agent can access. Lifecycle workflows help ensure the people responsible for that access remain current. Access packages give agent governance a proper entitlement layer. Conditional Access controls whether the agent can access resources under policy conditions. Access packages control what access the agent receives, who approves it, how long it lasts, and how it expires. Use access packages for approved agents with clear business purpose and accountability. Keep access time-bound, auditable, and reviewable. This prevents agent permissions from becoming permanent, unmanaged, or disconnected from business ownership.