Introduction

In my previous article I tried to give an introduction on agent loops in Logic Apps Standard, and how it can help with common IT problems.

To be more specific: I explained how you can get notified up front before important app registration secrets expire and manually acting on it, rather than finding out that they expired in production. The latter causes production incidents and response time to renew these secrets and resolve the downtime that comes with it.

Now that I have shown how such notification system could work with Logic Apps autonomous agent loops, I want to take this solution to the next level and show how agent loops can help with proactively acting, so that these secrets get renewed before they even expire.

Challenge: Notifying about secret expiration is nice, a mitigation would even be better

Even though getting notified in a timely manner is a good starting point to avoid issues. But after being notified, you will still need to take one or more manual actions to resolve the upcoming expiration of client secrets.

So, let’s find out how agent loops can do that for you.

Solution adjustment – Let’s add more tools to the agent loop

In part 1 of the series, we already had some tools in place to retrieve specific app registrations, let the autonomous agent determine if secrets are about to expire and send a notification e-mail for therse app registrations.

My new goal would be to see if I can automate the steps that I normally would do after such notification.

To summarize what the autonomous agent will do:

• Use Microsoft Graph as a tool to retrieve app registrations.
  
• Gather all the app registrations from Entra ID of which the secret is about to expire.
  
• Inform me via e-mail (also a tool) with name and expiry dates.
  
• Generate new secrets in Entra ID if an app registration secret expires.
  
• Create or update a Key vault with the new secret values.
  
• Send an e-mail with app registration names, new secret values and expiration dates.

The last step is not recommended, because sharing secrets over e-mail is never a good idea. But for the demo, the sky is the limit 😉

Prerequisites

To get started with there are a couple of prerequisites.

• Logic App Standard (or consumption based) should be up and running and a system assigned managed identity should be assigned to it.
  
  
• Furthermore, the Logic Apps managed identity must have Application.ReadWrite.All rights for Microsoft Graph.
  
  
• A Key vault with RBAC Key Vault Secrets Officer role assigned to the Logic Apps managed identity.
  
  
• An Office 365 connection setup (signed in with e.g. your own e-mail account). This has been explained in the previous article.
  
  
• You need to have a gpt model available that Logic Apps can use for the processing part. I have been using gpt-4.1-mini for this which is hosted in Microsoft Foundry.
  
  
• Your Logic Apps managed identity will need Cognitive Services Contributor RBAC role assigned in MS Foundry (Think I forgot to mention this in my previous article). Otherwise, you will not see MS Foundry and the models from your workflow connection.
  
  
• An autonomous agent workflow with Agent loop action that has been configured to use MS foundry and your AI model.

1. Step one – Recurrence trigger and some variables

Start by setting up a recurrence trigger for the workflow and variables for the app registration name prefix and your e-mail address. Set the recurrence interval as you like. I used a single execution per month.

2. Make sure your agent is connected to your model

As mentioned in the prerequisites, make sure you have set up the connection to your model in Microsoft Foundry and selecteyour AI model in the Agent configuration.

We’ll come back to the instructions after we have implemented the tools.

Now, let’s continue with the tools, which should do the following:

• Retrieve app registrations from Entra ID
• Send first email as notification for expiry
• Generate new app registration secrets for app registrations in Entra ID
• Create or update corresponding secret in your Key vault
• Send second email with new app registration information

3. Tool: Retrieve app registrations from Entra ID

I have explained this in the first part of the series, but let’s have a short summary. Retrieving app registrations and their secrets from Entra ID is done through Microsoft Graph API. Simply use the following HTTP GET to retrieve secrets.

https://graph.microsoft.com/v1.0/applications?$filter=startsWith(displayName,'@{variables('appregNamePrefix')}')&$select=id,displayName,appId,passwordCredentials

Your tool part in the workflow will look like this:

4. Send first email as notification for expiry

Also mentioned in the previous article, the Office 365 connector is being used to send an e-mail as notification for the secret expiry. It looks as follows:

5. Generate new app registration secrets for app registrations in Entra ID

The first addition to the flow is updating (in fact generating a new) secret for the app registration. For this we will also be using the Microsoft Graph API.

The tool settings will look like the following picture. Again, we provide a description to give the AI model context, and we specify with agent parameters are needed for the tool to work.

Next, the HTTP Request action is used to perform a POST to the following URL. Make not of the agent parameter object id, which is the object id of the app registration in Entra ID

https://graph.microsoft.com/v1.0/applications/@{agentParameters('objectId')}/addPassword

We also need to provide a body for the request, which contains a display name for the new secret, and we provide it with an expiration date 30 days from the expiration date of the previous secret (also an agent parameter).

{
  "passwordCredential": {
    "displayName": "secret-as-of-@{utcNow('yyyyMMdd')}",
    "endDateTime": "@{addDays(parseDateTime(agentParameters('endDateTime')), 30)}"
  }
}

The HTTP action then will be like this:

6. Create or update corresponding secret in your Key vault

After the model has updated all secrets, it would also be nice to create or update Key Vault secrets that contain the secret values of the app registration secrets. The out of the box connector for Key vault does not have a “Create / update secret” unfortunately

Note to self: while I’m working on the implementation, I come to realize that the possibilities are endless. If there isn’t a suitable connector but APIs are available, the possibilities seem to be endless with agent loops!

But we can use the REST APIs that are available! So let’s check that out.

https://[keyvault name].vault.azure.net/secrets/[secret name]?api-version=2025-07-01

This URL provides an easy way to create or update a secret in Key vault, simply by doing a PUT operation to the URL with a proper body. If you want to provide a value and an expiry date, it will look like this:

{
  "value": "@{agentParameters('appRegistrationClientSecret')}",
  "attributes": {
    "exp": "@{div(sub(ticks(agentParameters('expiryDate')),ticks('1970-01-01T00:00:00Z')),10000000)}"
  }
}

Expiry (exp) needs to be in ticks, instead of just passing in a UTC date. Therefore, the complex expression. Having all the necessary things sorted out, the only action that remains is setting up the tool and the action in the workflow as shown in the following pictures.

7) Send an e-mail with app registration names, new secret value and expiration dates

The final tool that we will be adding is more or less a repetition of the 4th step in this article. We need to email the new information. The tool and descriptions are a bit different, but parameters and actions remain the same.

8) Agent instructions

I have saved the instruction to be the last step. The main reason is because it is quite an instruction with 6 tools that need to be used.

During testing I also have run executions that – for some reason – did not execute all the steps. E.g. it would retrieve the app registrations, but the loop just wouldn’t send emails or do subsequent actions.

To tackle that, I explicitly mentioned the tool that needed to be used per step that the agent takes. It seems to understand it now and properly follows the plan. I also tried to keep the instructions short and concise.

You are an automated support engineer responsible for monitoring and renewing application secrets in Microsoft Entra ID.

This workflow runs on a scheduled interval.
You must strictly follow the ordered steps below and only use the provided tools.

Never skip steps. Never invent data. Never call a tool unless the step explicitly requires it.

---

## DEFINITIONS

CurrentDate = utcNow()
ThresholdDate = CurrentDate + 21 days

An application may contain multiple passwordCredentials.
The MOST RECENT secret is defined as:

The passwordCredential with the largest endDateTime value.

If an application has no passwordCredentials, ignore it completely.

All dates returned by APIs are in UTC.

---

## STEP 1 — FIND EXPIRING SECRETS

Call tool: Retrieve_app_registrations_from_Entra_ID

For each returned application:

1. Ignore the application if displayName does not start with "@{variables('appregNamePrefix')}"

2. If passwordCredentials is empty → ignore application

3. Determine the most recent secret:
   Select the credential with the maximum endDateTime

4. Compare:
   If MostRecentSecret.endDateTime <= ThresholdDate

Add to list ExpiringSecrets:

{
objectId: application id,
displayName: application display name,
expirationDateUtc: endDateTime
}

After evaluating all applications:

IF ExpiringSecrets is empty:
STOP WORKFLOW
Do NOT send emails
Do NOT rotate secrets

---

## STEP 2 — SEND WARNING EMAIL

Call tool: Send_email_when_secret_is_about_to_expire

The email must:
* Be sent to recipient: @{variables('emailAddress')}
* Be HTML formatted
* Contain a polite introduction
* Contain a HTML table with columns:
  App Registration Name
  Expiration Date

Format the expiration date as dd-MM-yyyy.

End the email with:

Best regards,
Sahin's maintenance team

---

## STEP 3 — CREATE NEW SECRETS

For each item in ExpiringSecrets:

Call tool: Update_app_registration_secret_in_Entra_ID
Provide:

* objectId
* expirationDateUtc

Store the response in list RenewedSecrets:

{
objectId,
displayName,
newSecretValue,
newExpirationDateUtc
}

Rules:

* Create exactly ONE new secret per application
* Never remove existing secrets

---

## STEP 4 — UPDATE KEY VAULT

For each item in RenewedSecrets:

Call tool: Update_secret_in_Key_Vault

Parameters:

* Secret name = displayName
* Secret value = newSecretValue
* Expiry date = newExpirationDateUtc

---

## STEP 5 — SEND RENEWAL EMAIL

Call tool: Send_an_email_with_updated_secrets_for_object_id

The email must:
* Be sent to recipient: @{variables('emailAddress')}
* Be HTML formatted
* Include a polite introduction
* Explains that the secrets have been updated in Entra ID and also have been stored in keyVault. mention the key vault name from as used in the Update_secret_in_Key_Vault
* Include a HTML table with columns:
  App Registration Name
  New Secret Value
  Expiration Date

Format expiration date as dd-MM-yyyy

End with:

Best regards,
Sahin's maintenance team

---

## GENERAL RULES

* Only operate on the most recent secret
* Never process the same application twice
* Never continue if a required tool fails
* Never fabricate secrets or dates
* Only use data returned from tools

---

9) Let’s test if it works!

So now everything is set up, let’s see if the agent does what I asked it to do. And as you can see, at least it ran 🙂

Determining app registrations secret expiration

The agent loop checked if there are app registrations with an expiring secret. It found 2, which is correct!

Sending notification email

Next it decided to send me an email notification.

Creating a new client secret for the app registration

Next, it created new secrets in Entra, great!

Creating or updating the secret in Key vault

And it also created secrets in my Key vault for both app registrations! I checked; the secrets are correct!

Send email with new secrets

And to finalize the process, it sends me an email with the new secret values and the expiration dates.

Conclusion and takeaways

Investigating if I could get this simple case to work was a fun way to get familiar with Logic Apps autonomous agents. With colleagues I have had a discussion on the matter though. Everything that the model does with the tools you give it, can also be achieved with traditional stateful workflows. But:

• By using AI, you shift from implementing (complex) logic yourself in your workflow to letting the agent do that for you with zero code.
• Less code is less development time. On the other hand, you will need to spend more time writing instructions.
• Nevertheless: as soon as your loop works, it works consistently with the same results each time you run it.

This approach saved me time in building loops to go through the app registrations and its secrets, composing variables, messages and emails. I really like to write down what I want to achieve from a functional perspective and less about the technical implementation with expressions and such.

My conclusion is that there are many IT maintenance tasks that can be automated with Logic App autonomous agents!