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
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.
Why access packages matter for agents
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:
- Who can request access
- Who approves access
- What resources are included
- How long access lasts
- Whether access can be extended
- What happens when access expires
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.
Where access packages fit in the governance sequence
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.
What agents can receive through access packages
Access packages are useful when approved agents need access to defined resources rather than broad standing permissions.
Common examples include:
- Security group memberships
- Microsoft Entra directory roles
- OAuth application permissions
- API permissions such as Microsoft Graph application permissions
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.
Recommended access package design
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:
- AP-Agent-CustomerSupport-GraphRead-Prod
- AP-Agent-FinanceAutomation-GroupAccess-Prod
- AP-Agent-SOCInvestigation-Privileged-ReviewRequired
The name should help an administrator quickly understand who the access is for, what it grants, and whether it is production or review-based.
Request and approval model
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.
Expiry and extension behaviour
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.
Design caveats
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:
- Is the agent approved?
- Does the agent have a valid owner and sponsor?
- Is the access pattern understood?
- Is the business purpose documented?
- Are the required resources clearly defined?
- Is access time-bound?
- Is there a clear approver?
- Is there a review or expiry model?
If the answer is unclear, the access package design is not ready.
Recommended operating model
A practical access package operating model for agents can look like this:
- Approved agents are identified from the inventory.
- Required resource access is mapped to a business scenario.
- Access package is created for that scenario.
- Sponsor or approver validates the need.
- Access is granted with expiry.
- Access is reviewed or extended only when justified.
- Expired or unused access is removed automatically through the lifecycle process.
This keeps access aligned to business purpose and reduces long-term permission drift.
Example access package patterns
| 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.
How this connects to the next phase
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.
Wrap-up
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.
SOCIAL SHARE CARD GENERATOR