The previous post covered five questions to ask before rolling out an enterprise agent. This post takes a closer look at one of them: How long should an agent keep the access it has been given?
I'll use the same meeting-preparation agent built by Geeker on the sales team. It runs in Microsoft Foundry and reads customer records to help prepare for meetings. Suppose the team wants to try it for 30 days. Who should approve read access to those records? Should the agent keep that access after the trial?
Managing the access lifecycle means assigning responsibility and an expiration date when access is granted, then deciding whether it is still needed when that date arrives.
1. Which identity actually has access?
After finding the meeting-preparation agent in Foundry, Geeker first needs to identify the credentials its customer-records tool uses. This example assumes the tool accesses the resource as the agent's own Microsoft Entra Agent Identity. If the tool instead uses delegated user authorization or another credential, that authorization path needs its own controls. Checking only the Agent Identity would miss it. Foundry agent identity and tool authentication
In the new Foundry agent model, an agent gets its own identity and a stable endpoint when it is created. In the legacy model, agents under development may share a project identity and receive a distinct identity only when published as an Agent Application. Both models may exist in an organization, so publication status alone does not tell you which identity has access. Foundry migration guide
This example uses a new-model agent with a distinct identity. The agent can continue to exist after the trial, while its permission to read customer records lasts only 30 days. Revoking that permission does not require deleting the agent.
2. Who is responsible, and who approves access?
The first post introduced the Owner and Sponsor roles. For the meeting-preparation agent, their responsibilities could look like this:
| Role | Responsibility in this example |
|---|---|
| Technical Owner, such as Geeker or a platform engineer | Confirm which identity the tool uses, configure the tool, and investigate access failures |
| Business Sponsor, such as the head of sales operations | Explain why customer records are needed and decide whether to continue the trial |
This division follows the Microsoft Entra Agent ID model for Owners and Sponsors. If either person changes roles or leaves, someone else needs to take over the responsibility.
The Sponsor can explain the business need, but being a Sponsor does not automatically give that person authority to approve access to customer data. In this example, a customer-data owner is the designated approver: sales operations states the purpose, and the data owner decides whether to grant access.
3. Put the 30-day read access in an access package
An access package brings together resource permissions and the rules for requesting, approving, and expiring them. An assignment records a particular grant: which identity received the package and how long it remains valid. Access package basics
The configuration starts in the Microsoft Entra admin center under ID Governance > Entitlement management > Access packages. Foundry runs the agent; Entra governs the approval and duration of this access.
For the example, create a package called Meeting Preparation - Read:
| Setting | Choice for this example |
|---|---|
| Resource | Membership in a security group for read-only customer-record access |
| Identity receiving access | The Agent Identity actually used by the meeting-preparation agent |
| Requestor | The head of sales operations, requesting on behalf of the agent as its Sponsor |
| Approver | The customer-data owner |
| Duration | 30 days |
| Extension | Allowed, with a fresh approval required |
This design assumes that the customer-records API already uses the security group to determine what the agent may read. Adding a group to an access package does not create authorization rules in the CRM. The target system must enforce and verify which records can be read and whether writes are blocked.
Access packages for agent identities can include security group membership, permitted Microsoft Entra roles, and OAuth API permissions. They cannot assign application roles, SAP roles, or SharePoint Online site roles. An existing employee access package containing those resource types cannot simply be reused for the agent. Access packages for agent identities
The general Microsoft Learn configuration screen shows approval and request-justification settings. Source: Microsoft Learn.
This read-access package does not include permission to send email. Even if email access is approved later, deciding whether to send a particular message is a separate runtime approval. The application or downstream API must actually block a send that has not been approved. Microsoft's shared responsibility model for AI agents
4. What happens after 30 days?
Before the assignment expires, the configured Sponsor receives a notification. If the policy allows extensions, the Sponsor can explain the continuing need and request one. This example requires another approval: the customer-data owner must agree before access continues.
If no extension is requested, the assignment expires and the access it managed is removed. The Agent Identity still exists. Agent access expiration and extensions
The general configuration screen shows expiration measured in days. The screenshot's 365 days is the documentation example; this scenario calls for 30 days. Source: Microsoft Learn.
5. How do you verify that the policy works?
Geeker can run a small test in a nonproduction environment:
- Before approval: Request customer records using the identity the tool will actually use. Confirm that access is denied.
- After approval: Confirm that records within the approved scope can be read, while out-of-scope records and write operations are still denied.
- After expiration: Let the assignment expire without an extension. Call the API again and check the assignment status, group membership, and actual access result.
If the request returns 403, check the current identity, permission assignment, and target system's authorization rules before granting a broader role just to make the demo work.
For troubleshooting, connect the Foundry project to Application Insights and use traces to inspect tool calls and their results. Then use Microsoft Entra sign-in logs to examine authentication activity for the identity. They provide different evidence; a trace does not revoke access. Limit who can view the logs so customer information is not exposed. Set up Foundry tracing · Microsoft Entra Agent ID logs
For this agent, a single 30-day read grant is a useful starting point. The team can identify the acting identity, the approver, the expiration date, and whether the agent can still read customer records after access is removed.
The next post will examine Agent Identity and Blueprint: which settings belong to one agent, and which affect identities under the same Blueprint.
You can outsource your thinking, but you cannot outsource your understanding.
Top comments (0)