[Feature] Per-User Daily Cost Breakdown for Azure SRE Agent Consumption

Feature description
Introduce a “Per-User Daily Cost Breakdown for Azure SRE Agent Consumption” capability that provides granular visibility into how much Azure SRE Agent usage cost is generated by each user (including service principals and managed identities) on a daily basis.
This feature would enable:

Tracking Azure SRE Agent consumption cost per user per day
Identifying which users are driving agent-related costs
Providing fine-grained cost attribution tied specifically to SRE Agent usage
Enabling visibility into agent-triggered operations (analysis, remediation, diagnostics) and their cost impact

Use case
Azure SRE Agent introduces operational intelligence and automation, but organizations need clear accountability for its consumption costs, especially in shared environments.
Key problems solved:

Lack of visibility into who is using the SRE Agent and generating cost
Difficulty controlling budgets when multiple users trigger:

Diagnostics
Remediation workflows
Investigations

No way to track daily consumption patterns per user

This feature enables:

Daily budgeting and cost control for SRE Agent usage
Chargeback/showback models per developer, team, or service
Identification of:

Heavy users of the SRE Agent
Inefficient or excessive usage patterns

Better governance of:

Automated investigations
Self-service troubleshooting by developers

Example scenarios:

A developer repeatedly triggers diagnostic workflows that increase SRE Agent consumption — identify their daily cost impact
A team’s automated pipelines invoke SRE Agent frequently — track daily cost trends per service principal
Finance teams analyze daily user-level SRE Agent spend to enforce budgets

Current workaround
Currently, there is no direct way to break down Azure SRE Agent consumption cost per user. Teams rely on indirect approaches:

Azure Cost Management

Shows aggregated service-level cost (SRE Agent), but not per user

Activity Logs

Identify who triggered actions, but do not link to cost

Manual correlation

Combine:

Logs (user activity)
Usage metrics
Cost exports

Requires custom scripts and data pipelines

Tagging strategies

Not applicable or insufficient for agent-triggered operations

Limitations:

No native user-level attribution
No daily breakdown
High operational overhead
Not usable in real-time SRE workflows

Proposed approach
Implement a native consumption attribution layer within Azure SRE Agent focused on user-level cost tracking:
1. User-level consumption tracking

Capture identity for every SRE Agent interaction:

User (Entra ID)
Service principal
Managed identity

Track usage events such as:

Diagnostics execution
Incident analysis
Automated remediation
Queries and insights generation

2. Daily cost aggregation

Map SRE Agent usage to internal billing metrics
Aggregate cost at:

User level
Per day granularity

Generate records like:
Date | User | Operation Type | Usage Volume | Cost

3. Attribution model (agent-specific)

Attribute cost based on:

Initiating identity (who triggered the action)
Associated workflow or session

Handle edge cases:

Automated runs → attributed to service principal
Scheduled workflows → attributed to owner or system identity

4. Built-in reporting and dashboards
Provide native views such as:

Daily SRE Agent cost per user
Top users by consumption (daily / weekly)
Cost by operation type (per user)
Trends:

Cost per user over time
Usage vs. cost correlation

5. Alerts and governance

Enable alerts such as:

“User X exceeded daily SRE Agent budget”
“Unusual spike in agent usage for user Y”

Support budget policies:

Per-user daily limits
Team-level thresholds

6. API and export capabilities

Expose APIs for:

Querying per-user daily cost
Historical trend analysis

Integrate with:

Power BI
FinOps platforms
Internal reporting systems

7. Lightweight tagging (optional enhancement)

Allow mapping users to:

Cost centers
Teams

Enable aggregated reporting by business dimension

The issue names no files, tests, or entry points. Start by reviewing the repository architecture and existing consumption, identity, and reporting paths, then define the supported attribution and aggregation scope. Done should include an agreed design for daily per-identity cost records, reporting and API surfaces, and governance behavior.

Written by the indexing model from the issue text.