Artificer Digital The Artificer's Grimoire

Scout: First-Class Agent Identity — the Directory/IAM Layer Emerges

Summary

The identity question for agents has split into two layers over recent weeks, and the second one is now productizing fast. The commercial-identity layer surfaced first — payment tokens and provisioned billing relationships that let an agent transact. This is the other half: the directory and access-control layer, where an agent gets a first-class identity in the same system that governs human and workload access, carries scoped permissions, and leaves an attributable audit trail. Microsoft’s Scout, its first “Autopilot” agent, assigns every instance its own governed Microsoft Entra identity rather than a shared service account. Cloudflare shipped temporary, scoped accounts that let an agent deploy infrastructure before any human authentication, claimable within a 60-minute window, the same week the Scout analysis surfaced — an adjacent provision-then-claim pattern that sits beside the directory layer rather than inside it. Underneath the directory products, the three hyperscalers have all shipped workload-identity primitives for agents — Entra Agent ID (GA April 2026), AWS Bedrock AgentCore Identity, and Google’s SPIFFE-based Agent Identity — that issue each agent a distinct, attributable identity object. They converge on the same architecture but not on the same maturity: Entra Agent ID and AgentCore Identity are GA, while Google’s is GA only for its own agent runtimes with the programmatic API still in preview. The through-line is that agent identity is an IAM problem with IAM primitives, not a borrowed-credential workaround. A recurring argument across the identity-security literature reviewed here is that identity issuance is now the easier part and runtime authorization the harder one — proving who an agent is doesn’t govern what it does once it acts at machine speed, and the first managed runtime-authorization products (AWS AgentCore Policy) are only just arriving.

Key Findings

1. Two identity layers, and this is the access-control one

There are two distinct things people mean when they say “agent identity,” and conflating them muddies every architectural decision. One is commercial identity: can the agent pay, can it provision a billing relationship, who gets the invoice. The other is directory/access-control identity: does the agent exist as a governed principal in the system that authenticates and authorizes access to corporate data and infrastructure, and is its behavior attributable in an audit log.

The commercial layer is the one that shipped first and loudly — payment-token brokers and provisioned accounts that let an agent buy and deploy, with the billing relationship anchored to a human. The directory layer is the subject here, and it is a different problem with different primitives: directory objects, scoped permission grants, conditional-access policies, lifecycle workflows, and audit trails. A team can adopt one without the other, and most of the access-control questions a security team actually asks — who is this agent, what may it touch, who is accountable, where is it logged — live in the directory layer, not the commercial one.

The reason both layers are productizing now is the same: the default until recently was a borrowed credential. An agent ran under a shared service account, or worse, under a human’s OAuth grant or a copy-pasted API key. Both patterns fail the same way — the agent’s actions aren’t attributable to the agent, least-privilege gets coarse because every agent on the shared principal inherits the same broad grant, and revocation is all-or-nothing. The directory-layer primitives below exist to replace that.

2. Microsoft Scout: per-instance Entra identity as the headline primitive

Scout is Microsoft’s first agent in a category it calls Autopilots — per the Microsoft 365 announcement, “always-on agents that work autonomously, with their own identity, and act on your behalf.” The detail that matters for infrastructure teams is the identity model: “Every agent operates under its own governed Entra identity, not a shared, anonymous service account, so the work it does is attributable to a known actor your directory already understands” (Microsoft 365 blog).

That sentence compresses the directory layer’s thesis: a per-deployed-agent identity (each governed agent object gets its own, rather than a fleet sharing one — not necessarily a fresh identity per process, task, or session), governed (subject to directory policy), and attributable (the audit trail names a known actor). Three controls attach to it, per the same announcement:

  • Scoped credentials. “The credentials behind that identity are protected end to end: scoped to the task at hand, redacted from logs or diagnostics, and managed with the same rigor you expect from any first-party Microsoft service.” The agent’s credentials are task-scoped rather than standing, and redacted from diagnostic output so they don’t leak through logging.
  • Approved-resource boundaries with human sign-off. “Agents can only reach the resources and destinations you’ve approved. Sensitive actions can require a human to sign off before they proceed.” This is the human-in-the-loop gate on the access-control side, parallel to the human gates the commercial layer puts on financial actions.
  • Purview-bound data handling. InfoQ’s analysis adds that Scout’s actions are bound by Microsoft Purview sensitivity labels and Data Loss Prevention policies, and that highly sensitive operations require human sign-off as “a final safeguard against unauthorized system modifications” (InfoQ).

Scout is built on the open-source OpenClaw framework — which grants the agent privileged local operations (file management, shell execution, code patches, browser automation) — extended with Model Context Protocol (MCP) server support and Microsoft’s “Work IQ” layer for scoped permissions, policy enforcement, and runtime observability. What matters here isn’t that Microsoft built an autonomous coding-capable agent; it’s that the agent’s reach into the corporate environment is mediated by a directory identity the organization already knows how to govern, rather than a service principal nobody owns.

3. The primitive underneath Scout: Microsoft Entra Agent ID

Scout is a consumer of a more general primitive that reached GA in April 2026: Microsoft Entra Agent ID. The mechanics are worth understanding because they define the shape of “agent as directory principal” more precisely than the Scout marketing does, and they expose a real tradeoff.

An Entra agent identity is, per Microsoft’s documentation, “a special service principal in Microsoft Entra ID.” Critically, “it doesn’t have credentials on its own” — instead it relies on an agent identity blueprint, a reusable template that “holds credentials” and acquires tokens on the agent identity’s behalf via federated identity credentials, certificates, or client secrets. Each agent identity carries a sponsor field, which “records the human user or group that’s accountable for an agent” and is “used for various purposes, such as contacting a human in case a security incident happens.” Autonomous agents acquire app tokens; interactive agents acquire user tokens where “the subject of the token is a user, while the actor is the agent identity.”

The blueprint is the scaling unit. A “Sales Assistant Agent” blueprint can spawn many agent identities (North America sales, enterprise sales, and so on), and because they share a blueprint the administrator can “apply a conditional access policy to all Sales Assistant Agents,” “disable all Sales Assistant agents,” or “revoke a permission grant for all Sales Assistant agents.” That is fleet-level governance over per-deployed-agent identities — something a shared service account cannot provide.

On the governance side, Microsoft’s Entra ID Governance documentation describes the access-attachment model: agent identities receive permissions through access packages (security-group memberships, OAuth/Graph API permissions, Entra role assignments) with three request pathways — the agent can programmatically request its own access package, its sponsor can request on its behalf, or an admin can assign directly. Access can carry an expiry; as it approaches, the sponsor is notified and either requests an extension (re-triggering approval) or lets it lapse, at which point “the agent identity loses access to the target resources.” Conditional Access for agents evaluates agent context and risk — including agent identity risk from Entra ID Protection — before granting access, and policies apply at the blueprint level so all derived identities inherit them. If a sponsor leaves, sponsorship “is automatically transferred to their manager,” so there is always an accountable human.

This is the most complete directory-layer governance story among the three hyperscalers — lifecycle, access reviews, conditional access, sponsor accountability, and expiring grants, all the machinery enterprises already run for humans, pointed at agents. The cost is that it is gated behind specific licensing — Microsoft Entra ID Governance for agent identities requires Microsoft 365 E7 (which includes Agent 365) or a Microsoft Agent 365 license paired with Entra P1 or Microsoft 365 E3 (Entra ID Governance docs). Agent 365 is generally available at $15 per user per month, paid yearly on an annual commitment. The governance is real; it is also a paid tier of the Microsoft estate.

A cautionary data point on how new this is: a vulnerability in the Entra “Agent ID Administrator” role — meant to manage only agent objects — let the role “take ownership of unrelated service principals across the tenant” because “the boundary between ‘agent’ and ‘non-agent’ objects was not properly defined,” a privilege-escalation path Microsoft patched by April 9, 2026 (CSO Online). The root cause is structural: agent identities are built on the same service-principal primitives as ordinary applications, so a scoping bug in the agent layer can escalate well past it. Silverfort’s original disclosure scopes the impact conditionally — it “depends on the privileges assigned to the targeted service principal,” reaching tenant-wide where that principal holds elevated rights, which Silverfort notes is the common case since most tenants run at least one privileged service principal. Treating the agent-identity control plane as battle-tested would be premature.

4. Cloudflare temporary accounts: the ephemeral, no-account-yet primitive

Cloudflare’s contribution sits at the opposite end of the lifecycle from Entra’s durable directory objects. The problem it solves, in Cloudflare’s framing, is that the moment an agent needs to deploy something it “slams face-first into a wall built for humans: a browser-based OAuth flow, a dashboard to click through, an API token to copy-paste, a multi-factor authentication prompt.” Temporary Accounts remove that wall: an agent runs wrangler deploy --temporary, Cloudflare “provisions a temporary account for the agent to use, gives Wrangler an API token,” and the Worker deploys to a workers.dev URL with “no copy-pasting tokens or entering credit card details.”

The deployment “stays live for 60 minutes, during which time you can claim the temporary account, making it permanently your own. If you don’t, it expires on its own.” The agent returns a claim URL; a human visits it to sign in and convert the ephemeral account into a permanent one. Supported resources span “Workers, Workers Static Assets, Workers KV, D1, Durable Objects, Hyperdrive, Queues, and SSL/TLS certificates,” and it requires Wrangler 4.102.0 or later (Cloudflare changelog).

Two things are worth separating from the marketing. First, as Simon Willison observes, the “for AI agents” framing is somewhat optional — “the AI hook isn’t really necessary, this is an interesting feature for everyone else as well” (Willison). The primitive is an ephemeral, claim-later account; agents are a motivating use case, not a hard dependency. Second, and more important for the identity discussion: this is an access/deployment primitive, not a directory-identity one. Cloudflare does not document a persistent, independently governed agent principal here — no per-agent attribution, no admin-attached policy or lifecycle ownership, nothing comparable to an Entra agent object or an AgentCore workload identity. The agent gets a scoped API token to deploy, the account is disposable, and a human claims it (and assumes the billing relationship) only if the work is worth keeping. Its place in this survey is therefore adjacent to the directory layer rather than inside it: a provision-then-claim lifecycle in which resources created autonomously start disposable and acquire durable human ownership only through an explicit claim step.

The abuse surface is obvious — unauthenticated deployment is a spam/abuse magnet — and Cloudflare’s CLI now prompts unauthenticated users about the flag and (per secondary coverage of the rollout) gates it behind an anti-abuse challenge; the precise mechanism isn’t spelled out in the primary changelog, so treat the specifics as lightly reported. The point holds regardless: ephemeral-by-default, claim-to-persist is a genuinely different lifecycle than the durable directory object, and the two compose — Cloudflare for the disposable edge of a project, a durable directory identity for anything that outlives the experiment.

5. The hyperscaler workload-identity layer: three roads to the same principal

Beneath the consumer-facing products, all three major clouds now issue agents a distinct, attributable identity object. They differ in the underlying standard, which matters for portability and attestation strength.

  • Microsoft Entra Agent ID (covered above): a service-principal-derived directory object with no credentials of its own, governed through blueprints, access packages, and conditional access. Strongest enterprise-governance story; deepest Microsoft-estate lock-in.
  • AWS Bedrock AgentCore Identity: per AWS’s documentation, agent identities are implemented as workload identities — explicitly “not an AWS IAM role or Amazon Cognito user, but a new identity primitive that is agent-specific with its own ARN that says who the agent is, separate from who the user is.” It supports SigV4, standardized OAuth 2.0 flows (including 3-legged authorization-code grant with session binding and scoped tokens), and API keys for reaching AWS and third-party services. The agent holds its own access tokens; the deployment still lives inside an AWS account someone owns.
  • Google Agent Identity: per Google Cloud IAM documentation, a SPIFFE-based identity tied to the agent’s lifecycle and mapped to the resource URI where the agent runs. Unlike service accounts, these “are not shared by multiple workloads by default, can’t be impersonated, and don’t allow developers to generate long-lived service account keys,” with access tokens cryptographically bound to the agent’s X.509 certificates to prevent token theft. Google documents the clearest certificate-bound attestation model of the three reviewed — but it is also the least broadly available: the core feature reached GA in April 2026 only for Google’s own agent runtimes (Gemini Enterprise and its Agent Platform Runtime), not arbitrary Google Cloud workloads, and the programmatic Agent Identity API plus its outbound auth manager are still in preview. So the convergence across the three is architectural; the product maturity and scope are not yet level.

There is also an interoperability seam: Entra can govern non-Microsoft agents. Microsoft’s documentation describes integrating third-party agents “from platforms such as AWS Bedrock and n8n” via the Entra Auth SDK sidecar or workload-identity federation, “giving every agent a governed identity regardless of where it was built” (Entra Agent ID overview). For a heterogeneous estate, that points toward a federation pattern — agents authenticated where they run (SPIFFE on Google, workload identity on AWS), governed centrally in the directory you already operate.

There is also an OS-level primitive worth situating here so it isn’t mistaken for the directory layer. Microsoft’s Execution Containers (MXC) SDK puts containment and identity into Windows itself — “session isolation for separate desktops and identities,” administered via Entra ID and Intune, with Defender and Purview providing “protection, observability and audit trail of agent behaviour.” MXC is the sandboxing layer (where an agent runs and what it can touch on the host), distinct from the directory layer (who the agent is to the rest of the estate). They complement each other; conflating them leads to assuming a sandboxed agent is also an attributable one, which it is not unless a directory identity is attached. Notably, Microsoft’s own MXC guidance cautions that “profiles should not yet be treated as security boundaries” — another signal that the agent-platform stack is early.

6. The recurring argument: issuance is maturing faster than runtime authorization

A recurring argument in the identity-security literature reviewed here — concentrated in a non-human-identity-community analysis and Identiverse conference reporting, not a standards-body or survey consensus — deflates the identity-issuance story. As that NHI analysis (drawing on a Cerbos argument) frames it, “authentication is no longer the hard part, authorization is.” SPIFFE and the hyperscaler primitives issue cryptographic, attestable, ephemeral identities cleanly — short-lived, auto-rotated, no long-lived secrets to steal. What they don’t do is govern what an identity does after it authenticates — and “access controls built for human-paced judgment do not hold when non-human actors act at machine speed and pursue goals without restraint,” because “AI agents can choose actions dynamically, combine tools, and alter execution paths based on context.” That breaks the provisioning-time assumption that an identity’s behavior is predictable from its grant.

The same source names a failure mode to watch — “ephemeral credential trust debt,” where “credentials are easy to issue but hard to explain,” and short-lived identities proliferate faster than review cycles can govern them. The Identiverse 2026 reporting adds texture on the sprawl, though the figures are conference-anecdote-grade, not market measurements: a panelist described one customer environment with “70,000 NHIs, most of which lacked clear ownership”; and figures GitGuardian attributes to Gartner (without a direct citation) put internal AI adoption near 90% against only ~8% of leaders able to confirm agents in production (GitGuardian). The prescriptions in these sources converge: “Zero Standing Privilege” firing before the first API call (“No power without proof. No access without purpose. No privilege without expiry. Everything logged”), task-scoped access with centralized runtime decisioning, and the audit bar set above mere logging — “a reconstructible chain from intent to action to verifiable proof,” because most organizations can show what happened but not who authorized each step.

The directory-layer products map onto this unevenly, and the runtime-authorization layer is no longer entirely unproductized. Entra Agent ID’s expiring access packages and conditional access govern the identity and token-grant path — “no privilege without expiry,” enforced where the grant is issued. AWS goes further at the action boundary: Policy in Amazon Bedrock AgentCore (GA March 3, 2026) runs outside agent code, intercepts agent-to-tool traffic at the AgentCore Gateway, and evaluates each request against centrally managed Cedar policies before allowing or denying the tool call — the closest managed product yet to a runtime policy-decision point for agent actions. Google combines IAM, Principal Access Boundaries, and Context-Aware Access around its identities. None of these is a complete, vendor-neutral model for authorizing an agent’s dynamically chosen actions at machine speed — that integration layer is still largely the practitioner’s to assemble — but “runtime authorization is wholly unsolved” now overstates it: managed enforcement points exist, they are just early and cloud-specific.

Practical Implications

Stop running agents under shared service accounts or borrowed human credentials. This is the clearest move on the list. A shared service account makes the agent’s actions unattributable, forces it to inherit broad permissions, and turns revocation into a blunt instrument. Every primitive surveyed here exists to replace that pattern. If you run agents against corporate data today and they authenticate as a copied API key or a generic service principal, that is now technical debt with a named replacement.

Pick the identity primitive by where the agent already lives, then govern centrally. If your agents run in the Microsoft estate and touch Microsoft 365 data, Entra Agent ID is the most complete directory-layer governance available and the path of least resistance — budget for the Agent 365 / E7 licensing it requires. If agents run on AWS or Google, use the native workload-identity primitive (AgentCore Identity’s ARN-per-agent, or Google’s SPIFFE-attested identity) for issuance and attestation, and consider federating those into a central directory for governance rather than running parallel control planes. For a heterogeneous fleet, the federation pattern — authenticate where the agent runs, govern in one directory — is usually preferable to running parallel per-cloud governance planes, though it brings its own costs: federation-trust dependencies, mappings between cloud-native and directory identities, and a central control plane whose compromise or outage now matters more. It’s a default to evaluate, not an unconditional win.

Treat the directory identity and the sandbox as two separate requirements. An agent needs both: a directory identity so the rest of the estate knows who it is and can audit it, and a containment boundary (MXC, a micro-VM, a scoped runtime) so a compromised agent can’t reach the host. They are not substitutes. A sandboxed agent with a borrowed credential is still unattributable; an attributable agent with no sandbox is still a host-level risk.

Use ephemeral-by-default for disposable work, durable identity for anything that persists. Cloudflare’s temporary-account model is the right shape for short-lived, agent-provisioned resources — demos, prototype deploys, throwaway edge functions — where claim-to-persist gives a human a deliberate moment to assume ownership and billing. Reserve durable directory identities for agents that touch production data or long-lived infrastructure. Don’t issue a permanent governed identity for work that should expire in an hour, and don’t run durable production access off a disposable account.

Build (or buy) the runtime-authorization layer above identity — don’t assume the identity primitive covers it. The recurring finding in these sources is that issuing a scoped, ephemeral, attested identity is now the easier part. What identity issuance doesn’t do is decide, at action time, whether this specific dynamically-chosen action is in policy. Managed enforcement points are beginning to appear — AWS AgentCore Policy evaluates each agent-to-tool call at the gateway against Cedar policies, and Entra’s expiring access packages and conditional access govern the grant path — but they are early and cloud-specific, and no product yet decides this vendor-neutrally across a heterogeneous fleet. A team deploying agents that compose tools and alter execution paths at machine speed should still plan for a policy-decision point that evaluates actions at runtime, plus an audit trail that reconstructs who authorized each step, not just what happened.

Don’t over-trust the agent-identity control plane yet. The Entra “Agent ID Administrator” scoping flaw and Microsoft’s own “profiles should not yet be treated as security boundaries” caveat on MXC are both signals that this stack is new. Agent identities sit on the same primitives as ordinary service principals, so a bug in the agent layer can have a tenant-wide blast radius. Apply the same scrutiny to the agent-IAM control plane that you’d apply to any newly GA’d privileged-access feature — least-privilege on the admin roles, monitoring on the agent-identity objects themselves.

Open Questions

  1. Does a vendor-neutral agent-identity standard emerge, or does the directory layer stay per-cloud? SPIFFE is the closest thing to a common substrate — Google builds on it, and the workload-identity community treats it as the issuance standard — but Entra Agent ID and AgentCore Identity layer proprietary governance on top. Whether federation (authenticate via SPIFFE, govern via a directory) becomes the dominant pattern, or whether each cloud’s governance plane wins its own estate, is unresolved.

  2. Where does the runtime-authorization layer get standardized? The sources here converge on runtime authorization being the harder, less-settled part, and managed enforcement points are only just appearing (AWS AgentCore Policy at the tool gateway, Entra conditional access on the grant path) — but there’s no consensus, vendor-neutral primitive for “evaluate this dynamically-chosen agent action against policy at machine speed.” Whether this lands as an extension of conditional access, a cross-cloud policy-decision-point category, or something tied to the MCP/tool-call boundary is the most consequential open question for practitioners.

  3. How do the commercial-identity and directory-identity layers compose? A production agent will plausibly need both — a governed directory identity for access to corporate data and a commercial identity for the resources it provisions. Whether these stay separate stacks (Entra for access, a payments broker for commerce) or converge into a single agent-identity surface, and who owns the seam, is not yet clear from any vendor roadmap.

  4. Does the per-instance identity model survive agent fleets and swarms? The blueprint-and-instance model assumes a manageable number of agent kinds. Multi-agent systems that spawn ephemeral sub-agents per task could produce identity sprawl on the scale the Identiverse reporting already flags (70,000 NHIs with no clear ownership). Whether the directory layer’s lifecycle automation keeps pace with swarm-scale agent creation is an open scaling question.

  5. How quickly does the control plane harden? The Entra agent-role scoping flaw was patched within weeks of GA, but it shipped. The structural fact that agent identities ride on service-principal primitives means the agent-IAM layer inherits that entire attack surface. How fast vendors isolate the agent control plane from the general application-identity plane will shape how much trust the directory layer earns.

Sources

  1. Introducing Microsoft Scout: your always-on personal agent — Microsoft 365 Blog, 2026-06-02
  2. Microsoft Scout, New Enterprise Autopilot Built on OpenClaw, Announced at Build 2026 — InfoQ, 2026-06-18
  3. Temporary Cloudflare Accounts for AI agents — Cloudflare Blog, 2026-06-19
  4. Temporary accounts for AI agent deployments (Changelog) — Cloudflare Developers Changelog, 2026-06-19
  5. Temporary Cloudflare Accounts for AI agents — Simon Willison, 2026-06-21
  6. Overview of agent identities in Microsoft Entra — Microsoft Learn
  7. Governing Agent Identities — Microsoft Entra ID Governance — Microsoft Learn
  8. What is Microsoft Entra Agent ID? — Microsoft Learn
  9. Microsoft Agent 365 — official product and pricing page — Microsoft
  10. Microsoft patched an ‘agent-only’ role that was not — CSO Online
  11. Agent ID Administrator scope overreach: service principal takeover in Entra ID — Silverfort (original disclosure)
  12. Provide identity and credential management for agent applications with Amazon Bedrock AgentCore Identity — AWS Documentation
  13. Policy in Amazon Bedrock AgentCore is now generally available — AWS What’s New, 2026-03-03
  14. Agent Identity overview — Google Cloud IAM — Google Cloud Documentation
  15. IAM release notes (Agent Identity GA and Agent Identity API preview) — Google Cloud Documentation
  16. SPIFFE and AI agent identity expose the next authorization gap — Non-Human Identity Management Group
  17. Identiverse 2026: The Challenges Of Solving Identity For AI Agents At Scale — GitGuardian Blog
  18. Windows platform security for AI agents — the MXC SDK — InfoQ, 2026-06-19