/azure-sre-agent

HTTP Triggers Production Reference

Use HTTP triggers for event-driven SRE Agent execution from CI/CD pipelines, monitoring tools, or external automation.

Guardrails

1. Disable triggers until bearer-token authentication, payload schema, replay controls, and secret handling are tested.
2. Keep prompts bounded to the triggering service, resource scope, deployment, commit, or incident.
3. Do not send secrets or raw customer data in trigger payloads.
4. Set maxTurns well below service limits and tune after real executions.
5. Default to Review mode and use approval hooks for production write actions.
6. Record idempotency keys or calling-system correlation IDs.
7. Review execution history for prompt injection, unexpected tool use, and AAU cost.

Good Uses

• post-deployment health validation
• pipeline failure triage
• IaC drift investigation
• release readiness checks
• compliance evidence gathering

Poor Uses

• broad open-ended investigation without scope
• high-frequency alert fan-out without cooldown/noise control
• direct production remediation from untrusted payloads

Authentication

The Token Audience Conflict

The official Microsoft Learn docs contain conflicting guidance about HTTP trigger token audiences:

• The HTTP Trigger API reference section shows --resource https://management.azure.com
• The Troubleshooting section says the audience must be the SRE Agent app ID 59f0a04a-b322-4310-adc9-39ac41e9631e
• The data-plane API documentation references audience https://azuresre.dev

Working Workaround

Until this is clarified by Microsoft, use this two-step pattern for CI/CD integration:

If your trigger is from GitHub Actions / Azure DevOps:

• Use OIDC Federated Identity with the SRE Agent app ID: 59f0a04a-b322-4310-adc9-39ac41e9631e
• This is confirmed working as of 2026-06-25

If your token comes from Azure CLI or custom code:

• Request a token with scope https://management.azure.com
• If you get a 401, retry with scope https://azuresre.dev
• Log which scope worked for your environment

The caller needs Microsoft.App/agents/threads/write permission on the agent resource (service principal, managed identity, or user). A successful invocation returns HTTP 202 (Accepted) immediately with {"message", "executionTime", "threadId", "success"} and the agent processes the request asynchronously.

Debug Flowchart

Is your HTTP trigger returning 401?
├─ Check token is not expired → If expired, request new token
├─ Check token audience is correct → See "Working Workaround" above
├─ Check SRE Agent resource exists and is in your subscription → If not, provision first
└─ If still 401, file issue at https://github.com/microsoft/sre-agent/issues with your token audience value

Success Signal

Your HTTP trigger returns 202 (Accepted) — the agent processes asynchronously — and the execution appears in trigger history / the response plan is invoked.

[VERIFY]
Claim = HTTP trigger token audience requirements
WhereToCheck = https://learn.microsoft.com/en-us/azure/sre-agent/http-triggers
Status = Conflict documented; working workaround provided; awaiting official docs clarification
Action = Test your specific CI/CD platform (GitHub Actions, Azure DevOps, etc.) to confirm token scope before production cutover