Video summary

One Compromised Agent Blueprint Can Cross Tenant Boundaries

Main summary

Key takeaways

News and Commentary

Security Research Summary: Microsoft Entra ID Agent “Blueprints” and Blast Radius

Security researcher Katie Noles (DataDse) discusses her multi-part research on Microsoft Entra ID’s “agent identity/agent ID” model, focusing on how attacker impact (blast radius) can be much larger than defenders often expect.

Origin & Motivation

  • Noles began investigating agent security after noticing evolutions in agent technologies and identity-related risks.
  • While she initially observed prompt injection/hallucination issues as a form of social engineering, she focused on the underlying identity/infrastructure model.
  • Her work expanded into a three-part blog series after an initial draft grew too large and was split for readability.

Core Concept: Agent “Blueprints” Multiply Identities

A key surprise is that the agent identity model is structurally similar to the app + service principal model, but with different object types and properties.

Most importantly: one agent blueprint can be associated with many identities.

  • A blueprint principle maps to an application-registration-like object.
  • That blueprint can spawn multiple agent identities, and optionally agent user accounts, for different environments or usage contexts.

Why this matters: defenders may assume each agent identity is its own isolation boundary, but the blueprint relationship effectively ties many identities together—creating a “future blast radius” problem.

Blast Radius Expansion: Multi-Tenant Risk

Noles emphasizes that the real danger emerges when defenders map relationships across tenants.

If a blueprint created in one tenant is used/consumed in other tenants, compromise can propagate:

  1. An attacker compromises the tenant where the blueprint lives/was created.
  2. They identify associated agents.
  3. They authenticate as an agent in a separate (target) tenant.
  4. They then use that agent’s permissions to escalate impact.

She frames this as similar in spirit to “Midnight Blizzard”-style cloud identity takeover patterns, but with the agent blueprint model multiplying the number of identities and potential paths.

Tested/Illustrated Attack Scenario (Agent Blueprint Compromise)

In her second post’s scenario, an attacker can escalate from one tenant to take over an agent identity in another tenant.

  • The demo included an example involving temporary access pass creation.
  • It used a one-time sign-in as a targeted user to reset MFA.
  • The implication: an attacker could convert agent capabilities into credential/MFA reset pathways, assuming the necessary permissions are configured.

Why Defenders May Struggle

Agent identities can be created at scale—often without obvious admin visibility—especially through Microsoft first-party agent platforms (e.g., Copilot Studio and Azure Foundry).

This creates:

  • Noise: potentially hundreds or thousands of identities to review.
  • Triage difficulty:
    • service principal logging fields differ from user logging
    • agent identities add another identity layer

Even when defenders can’t directly “take over” an agent identity (e.g., no classic credential like a traditional service principal hijack), the blueprint owner/controller still governs how authentication, token handling, and permissions play out.

Protection Guidance: What Admins Should Do

Noles’ defensive recommendations focus on containment and governance:

  1. Treat blueprint/agent identity governance as high-trust

    • Blueprint ownership/control effectively becomes the security boundary for derived identities.
    • For third-party blueprints, evaluate the provider’s scope and risk.

  2. Restrict privileged assignments / blueprint administration

    • Ensure only trusted admins can manage blueprints (blueprint administrators).
    • Limit agent permissions and consider risk tiers for different agent use cases.

  3. Apply least privilege to agent permissions

    • Some permissions can’t be assigned to agent-related identities, but some still can.
    • Defenders should actively restrict what’s assignable and what roles are possible.

  4. Use safer credential types: avoid client secrets

    • Strong guidance: don’t use client secrets for agent authentication/blueprints when possible.
    • Prefer federated/workload identity federation; fall back to certificates.
    • Client secrets increase leakage risk and have appeared in real-world compromises.
    • Noles also notes Microsoft’s push toward eliminating secrets in production over time.

  5. Visibility and auditing

    • For third-party blueprints, admins can use admin consent flows (onboarding process).
    • For first-party platforms, coordinate across Microsoft 365/Azure teams and audit created agents/permissions regularly.
    • She highlights improved portal visibility, including inspection of delegated permissions, app permissions, and role assignments for agent identities.

  6. Detection and response

    • Because blueprints build on app/service principal mechanisms, existing detections for app registrations/service principals should still help (e.g., credential additions).
    • She notes ongoing evolution toward risky sign-in/identity protection for agents to prevent compromised agents from acting—and vice versa for compromised users.

Overall Takeaways

  • The agent blueprint model is powerful but increases risk when compromised due to:
    • identity multiplication
    • multi-tenant blast radius
  • The central defender job is governance:
    • control blueprint creation/permissions
    • avoid risky credential patterns
    • maintain monitoring/audit capability for the expanded identity surface

Presenters / Contributors

  • Merryll (podcast host)
  • Katie Noles (DataDse / senior security researcher)

Original video