Entra Logging Advances: Agent ID and Service Principal Sign-In Logs

Microsoft has expanded Microsoft Entra’s logging toolkit with a set of targeted capabilities that give administrators far better visibility into agent activity, service-to-service authentication, and richer sign-in attributes — features designed to improve security monitoring, incident investigations, and cross-tenant correlation while introducing operational and privacy trade-offs that IT teams must manage carefully.

Background​

Microsoft Entra sits at the center of identity and access controls for Azure and Microsoft 365. Historically, sign-in and audit logs focused on human interactive sign-ins and application tokens; as software agents and autonomous tooling proliferate (Copilot agents, Security Copilot, Copilot Studio, Azure AI Foundry and third‑party agents), that telemetry model was no longer sufficient to answer basic questions like “which agent performed X action?” or “which Microsoft service requested a token on behalf of which app?” Microsoft’s recent updates address exactly that gap by adding inventory‑level identities for agents, a dedicated sign‑in resource for agent activity, a Microsoft service‑principal sign‑in stream for first‑party service-to-service tokens, and a set of enhanced attributes in sign‑in records to make cross‑tenant and cross-service correlation more reliable.

---

What changed — a short summary of the new capabilities​

• Entra Agent ID and agentSignIn telemetry: Agents created by Microsoft runtimes (Copilot Studio, Azure AI Foundry) can now be assigned an Entra Agent ID and their sign-ins show up with a new complex resource type, agentSignIn, exposed in the Microsoft Entra admin UI and Microsoft Graph APIs. Administrators can filter sign-in logs for agent activity using an is Agent UI filter.
• Microsoft service principal sign-in logs (Public Preview): A new optional log stream, MicrosoftServicePrincipalSignInLogs, captures token requests made between Microsoft-owned services (first‑party service principals) when they authenticate within a tenant (for example, Teams requesting Word to render a document). This stream is available as a diagnostic setting and is opt‑in because of its volume and complexity.
• New and improved sign‑in attributes: Sign‑in logs now include additional fields such as AppOwnerTenantId, ResourceOwnerTenantId, SessionID, SourceAppClientID, Entra TenantID in Log Analytics, UserAgent for service principal sign‑ins, and Autonomous System Number (ASN) for network attribution — all intended to give richer context for detection, forensics, and cross‑tenant analysis.

These changes were widely covered by industry outlets and summarized in vendor and community posts; early writeups emphasize the operational value for security teams while cautioning about the preview status and volume of the new Microsoft service‑principal stream.

---

Deep dive: Entra Agent ID and agentSignIn​

What is an Entra Agent ID?​

The Entra Agent ID is a directory-level construct that treats a software agent or Copilot‑style runtime as a first‑class identity object. Instead of agents being invisible automation threads, they are represented in your tenant so they can be managed with lifecycle controls, assigned owners, and subject to conditional access or entitlement reviews — much like a service principal or managed identity. The feature was announced and surfaced as part of Microsoft’s agent governance work around Copilot Studio and Azure AI Foundry.

The agentSignIn resource and the “is Agent” filter​

Microsoft added a complex sign‑in resource type, agentSignIn, which captures agent‑specific properties (for example, whether the agent is an app or an agent instance and a parentID for agenticAppInstance entries). Administrators can now filter Entra sign‑in logs in the portal with the is Agent toggle to see only agent‑originated authentication events, and the same resource appears in Microsoft Graph for programmatic queries and SIEM ingestion. This dramatically simplifies the common tasks of isolating agent activity and linking agents back to owners or provisioning flows.

Why this matters in practice​

• Investigations become faster because agent activity is surfaced as a distinct class of sign‑in.
• Asset management improves: agents can be inventoried, owners assigned, and lifecycle policies enforced.
• Governance controls (conditional access, token lifetimes) can be applied with the same rigor as for human or app identities.

---

Deep dive: Microsoft service principal sign‑in logs​

What these logs are​

The MicrosoftServicePrincipalSignInLogs stream captures service‑to‑service token requests made by Microsoft‑owned first‑party applications within your tenant. These are not user sign‑ins — they are tokens exchanged between Microsoft services to provide integrated experiences (for example, Teams requesting an embedded Word rendering). Microsoft offers these logs as an opt‑in diagnostic product because they are high‑volume and can be noisy, but they can be invaluable for transparency into internal token flows and investigating abnormal patterns that involve Microsoft service actors.

How to get them​

• Sign in to the Microsoft Entra admin center with appropriate privileges.
• Navigate to Monitoring & health → Diagnostics.
• Add a diagnostic setting and select MicrosoftServicePrincipalSignInLogs as a stream, routing it to Log Analytics, Event Hub, or a storage account for ingestion into your SIEM.

Microsoft’s caveats​

Microsoft explicitly warns that these logs are complex and not required for normal security investigations, and cautions against actions like disabling Microsoft first‑party apps based solely on the telemetry in this stream because doing so can cause misconfigurations or service disruptions. That guidance is important operationally: this stream is meant for transparency and advanced troubleshooting rather than an automated remediation signal.

---

The new sign‑in attributes — what they add and how to use them​

Microsoft expanded which fields are included in sign‑in tables and service principal reports to improve correlation and attribution.

• AppOwnerTenantId & ResourceOwnerTenantId: These tenant identifiers help identify the owning tenant of an app or resource, which is invaluable when a sign‑in or token exchange crosses tenant boundaries. Use these values to triage cross‑tenant access anomalies.
• SessionID: Attaches a session correlation token to sign‑in events so that investigators can stitch together a user or agent’s activity across multiple requests or service calls. This is particularly useful when short‑lived tokens are used and you still need to follow an execution flow end‑to‑end.
• SourceAppClientID: Exposes the client app that initiated a flow; useful for mapping which application code path led to token issuance. This can uncover supply‑chain and misconfiguration issues where a third‑party app exercises unexpected authority.
• Entra TenantID in Log Analytics: Ensures that when you export sign‑in logs to Log Analytics or Sentinel, the tenant context is preserved and searchable, which simplifies multi‑tenant correlation in MSP or cross‑tenant setups.
• UserAgent in Service Principal Sign‑In: Adds client user‑agent metadata to service principal sign‑in rows, enabling better fingerprinting of calling services and detecting unusual clients or libraries that may indicate compromised code paths.
• Autonomous System Number (ASN): Provides network‑level attribution for service principal calls so that security teams can more rapidly determine if calls originated from suspicious networks or known bad ASNs.

These attributes make Entra sign‑in telemetry more actionable for SIEM/XDR correlation, threat hunting, and compliance reporting.

---

Example operational queries and uses​

The new fields can be ingested into Azure Monitor / Log Analytics and queried with Kusto for alerts and investigations. Example (illustrative) KQL patterns:

• Find agent-originated sign‑ins:
• SigninLogs | where isnotempty(Agent) or SigninLogs | where AgentType == "agenticAppInstance"
• Find Microsoft service principal calls from a suspicious ASN:
• AADServicePrincipalSignInLogs | where AutonomousSystemNumber == "AS12345"
• Show sign‑ins where SourceAppClientID != expected client:
• SigninLogs | where SourceAppClientID != "<expected-client-id>"

These examples demonstrate the type of hunts and alerts teams can implement once the logs are routed to a workspace. Every environment will need tuning to reduce false positives given the volume of service‑to‑service traffic.

---

Practical benefits for security, compliance, and operations​

• Faster root cause analysis: Agent IDs and SessionIDs reduce the time to map events to a single accountable identity and execution path.
• Improved governance: Agents become manageable objects that can be inventoried, subjected to conditional access, and included in access reviews.
• Better telemetry for SIEM/XDR: Additional attributes like ASN, UserAgent, and tenant IDs enable higher‑fidelity detection rules and cross‑tenant correlation for MSPs and complex multitenant estates.
• Auditability for regulators and auditors: Tamper‑resistant logs that clearly show agent identity and action can satisfy evidence requirements for regulated industries.

These benefits make Entra’s identity telemetry closer to what enterprises need for modern AI-enabled automation scenarios.

---

Risks, limitations, and operational caveats​

• Volume and noise: Service‑to‑service logs, especially Microsoft’s first‑party stream, can generate large volumes of telemetry. Without focused retention policies and filters, costs and noise will rise quickly. Microsoft offers these logs as opt‑in for that reason.
• Misinterpretation risk: The presence of a token request from a Microsoft service does not by itself mean compromise or misbehavior. Microsoft specifically warns against disabling Microsoft first‑party apps based solely on these logs because doing so could cause tenant lock‑out or degrade service. Analysts must combine attributes and context before remediating.
• Preview and variability: Several elements (the agent model, how different agent runtimes represent identities — managed identity vs Agent ID object — and attribute names) have been evolving in preview. Teams should treat early observations as provisional and validate how agent identities surface in their tenants.
• Correlation overhead: Stitching traces across Copilot Studio, Azure AI Foundry, Entra, and third‑party registries requires consistent correlation keys and logging agreements. Without them, auditability will have gaps.
• Governance maturity requirement: Identity is necessary but not sufficient. Organizations must pair Entra identity controls with runtime authorization, DLP, procurement, and human‑in‑the‑loop processes to avoid “agent sprawl” and unintended data exposure.

Where claims about future support or timelines appear (for example, adding broader third‑party agent support or bringing Security Copilot/Microsoft 365 Copilot agents into the Agent ID model), treat roadmap items as aspirational until customers validate them in their tenants and official Microsoft release notes. Some vendor blog posts and coverage indicate imminent broader support, but tenants should verify behavior in their own environment.

---

Recommended rollout checklist for IT and security teams​

• Inventory and classify
• Catalog existing agents, bots, scheduled jobs, and automation flows. Classify by business impact and data sensitivity.
• Enable selective diagnostics
• Turn on SigninLogs and the new MicrosoftServicePrincipalSignInLogs only where necessary and route them to a dedicated Log Analytics workspace with controlled retention to limit costs. Set filters to reduce noise (e.g., only route events for sensitive resources).
• Enforce identity-first access controls
• Require Entra Agent IDs or equivalent directory identities for agents that access sensitive systems. Apply conditional access and short‑lived, scoped tokens.
• Instrument SIEM hunts and alerts
• Create tuned detection rules that use new attributes (Agent, SessionID, ASN, SourceAppClientID, AppOwnerTenantId) to detect anomalous agent behavior or unexpected cross‑tenant access.
• Implement least privilege and approval gates
• Map agent actions to the minimum required privileges; require approvals or human verification for sensitive actions (HR changes, payroll, finance).
• Plan for deprovisioning and emergency revocation
• Define playbooks to revoke Entra Agent IDs, rotate keys, and fail‑closed agent traffic in case of a compromise. Ensure incident response includes agent‑specific forensic steps.
• Validate vendor and runtime behavior
• Pilot to confirm how Copilot Studio, Azure AI Foundry, Security Copilot and other runtimes represent agents in your tenant — test how identities appear (service principal vs Agent ID entry) and adjust ingestion and alert rules accordingly.

---

Critical analysis: strengths and open questions​

Strengths​

• Higher fidelity telemetry: The addition of Agent IDs, SessionID, and tenant attribution fills long-standing visibility gaps that hampered investigations into automated actions and service‑to‑service flows.
• Operational transparency for Microsoft services: The Microsoft service principal sign‑in stream gives tenants explicit telemetry about internal Microsoft service behavior that was previously opaque — a notable step for transparency.
• Programmatic access: agentSignIn in Microsoft Graph allows automation engineers and SOC teams to build queries and integrations directly into their tooling and playbooks.

Risks and unanswered questions​

• Data overload vs. signal: Large orgs will need skilled telemetry engineering to avoid drowning in service‑to‑service noise. The default temptation to ingest everything will increase costs and cognitive load.
• Cross‑platform parity: Different agent runtimes sometimes surface identities as managed identities, service principals, or Agent ID entries. That inconsistency complicates universal policies and SIEM rules. Validation is required per tenant.
• Vendor lock‑in and protocol adoption: While Microsoft’s approach is powerful for customers on the Microsoft stack, enterprises with multi‑cloud or multi‑vendor architectures should ask how agent identities and logs will interoperate with non‑Microsoft tooling and whether open standards for agent metadata will emerge.
• Privacy, regulatory and retention constraints: The new logs contain network and tenant attribution data. Organizations must balance security needs with data minimization, retention policies, and privacy regulations when deciding which streams to retain and for how long.

---

Bottom line​

Microsoft Entra’s new logging capabilities materially improve the visibility and governance of autonomous agents and service‑to‑service authentication flows. For security teams, the combination of Entra Agent ID, the agentSignIn resource, Microsoft service principal sign‑in logs, and the richer sign‑in attributes represents a step‑change: you can now identify, correlate, and audit agent actions with a level of fidelity previously unavailable. These capabilities are powerful when used thoughtfully — enabling faster investigations, tighter governance, and better audit evidence — but they also require careful rollout planning to avoid cost, noise, and misinterpretation. Start with inventory and targeted diagnostic streams, validate how agent identities appear in your tenant, tune SIEM hunts around the new attributes, and ensure governance processes are in place to treat agents as first‑class, accountable identities.
The feature set is evolving in preview and Microsoft’s guidance underscores the need for cautious adoption; treat roadmap statements about future agent coverage as provisional and validate behaviors directly in tenant pilots before relying on them for policy enforcement.

---

Microsoft’s moves close an important visibility gap for modern identity ecosystems, but the work to operationalize these logs — from retention and filtering to alerting and lifecycle controls — will determine whether organizations convert visibility into measurable security posture improvements.

---

Source: Petri IT Knowledgebase Microsoft Entra Gets New Logging Capabilities