The Runtime Mints the Identity. That Does Not Make It the Authority.

The major platforms that can run agents are minting identities or identity evidence for them, and whoever operates your agents is positioned, by default, to govern them. Microsoft Entra Agent ID is generally available, with agent identity blueprints, tenant-local agent identities, sponsors, governance, and agent-aware OAuth flows. Google’s Agent Identity is generally available for Agent Runtime and gives supported deployments SPIFFE-based, key-bound identities integrated with Google Cloud IAM. Its outbound authentication broker remains in preview. Model-provider harnesses can enroll local instances as part of deployment and hold the account of the human behind them, while some agent providers are making the identity-provider claim for themselves. These are live market positions, not settled control points.

The stakes are higher than ordinary workload identity. An agent is goal-seeking software that can assemble new context, discover tools, and choose an execution path its designer did not enumerate. That open-world capability is much of the value. It also means proof of the instance does not predict the next action. Identity has to anchor a larger control chain; it cannot stand in for the approved work or the decision at the resource.

These systems are not architecturally identical, and they do not mint the same object: Google begins with an identity tied to the deployed runtime, Entra begins with enterprise directory objects and says Microsoft and third-party agent platforms can integrate with its identity plane, and a harness can begin with its own local instance record. All three converge on the same control point, the step where evidence about a running instance becomes an identity that policy and resources recognize, and the runtime has the advantage there because the execution environment starts the instance, creates or protects its key, and observes the facts needed to describe what is running. An identity platform may pre-provision the logical agent record, but it still needs evidence from execution before it can trust a particular instance, and turning that evidence into a credential is the shortest path to a working product. Convenience has a way of becoming architecture: whoever controls that binding gets the first chance to govern what the agent can do.

The mistake is treating that first chance as a law of architecture.

A runtime can establish facts about an instance. An enterprise still has to decide whose agent it is, which approved deployment it belongs to, and what authority its resources will honor. Those are different decisions with different owners and lifecycles. A vendor wins the control point when its product makes runtime proof, enterprise identity, and usable authority look like one indivisible act.

The runtime gets the first word about an agent instance. It does not automatically get the last word about the agent’s authority.

This is the second of three essays on who controls the agent stack. The first named the provider seam that hides credential mechanisms and custody from agent logic. This essay is about the binding layer that turns runtime evidence into an enterprise-governed Agent and Agent Deployment. The third takes up the approved-work record. A resource remains authoritative for the final action throughout. None of the three control points can command it to permit.

“Identity” Is Hiding Five Different Jobs

The phrase agent identity is doing too much work. Five mechanisms are routinely compressed into it, including one decision that is not an identity function at all:

The boundaries matter: an attestation only means something to a verifier that trusts the issuer and accepts its claims, and a token projects some subset of that decision to a resource, which still applies its own policy.

None of those facts, by itself, answers why an agent has authority for a particular task. In a mission-based system, the Agent, approved Agent Deployment, and approved Mission remain three objects with three lifecycles. The runtime supplies evidence to the binding layer. It may also host the harness that requests work, but observation is not ownership: the runtime does not approve its own deployment, create legitimate task authority, or decide resource policy.

This is the real market boundary. The runtime necessarily participates in the first two jobs. Whether it also owns enterprise binding or credential projection is a product and trust decision, not a technical inevitability. Resource policy remains the resource owner’s decision even when one vendor operates every layer.

The Join Won the LAN. Federation Reopened the Market.

Active Directory won the LAN because identity arrived with infrastructure the enterprise already had to operate. Joining a machine created its account. Deploying a Windows service put it inside the domain’s administrative and Kerberos boundaries. The directory, credential issuer, policy system, and installed base reinforced one another.

I explored that distribution advantage in Kerberos Won Because Nobody Had to Implement It: the winning identity system was attached to the event that created the thing needing an identity.

Cloud computing did not make domain join disappear. It made join insufficient as the universal control point. Enterprises accumulated SaaS applications, multiple clouds, contractors, partners, and devices outside a single administrative domain. A federation layer could delegate authentication to existing directories and project enterprise decisions into applications the enterprise did not operate.

Okta and Microsoft each built a federation layer on that gap, with SAML and then OpenID Connect as the seams. Owning the directory no longer guaranteed owning every relying-party relationship.

Workload identity took a parallel route. Cloud service accounts and managed identities began replacing shared application secrets with credentials issued to workloads by their execution platforms. SPIFFE gave workloads a common identifier and a workload-facing API for obtaining short-lived identity documents. Then workload identity federation made the layer explicit. An external workload presents evidence from its own environment, and a target trust domain maps the accepted claims into local principals and permissions. Both Microsoft Entra workload identity federation and Google Cloud Workload Identity Federation use this pattern to give external workloads short-lived access without distributing a target-cloud service-account secret.

That history is closer to the agent problem than workforce SSO is. The source environment says which workload presented which credential. The target cloud decides how that assertion maps into its own IAM and what the resulting principal may access. Workload identity has already shown that the party closest to execution can supply identity evidence without owning every authorization decision downstream.

The analogy has a limit, and the limit changes the conclusion below. Conventional workloads never became trustworthy merely because their code identity was known: runtime inputs, configuration, dependencies, and vulnerabilities always mattered. But their expected behavior was usually narrower and more change-controlled, which made identity-anchored least-privilege policy tractable. An agent widens the gap. Its execution path is chosen at runtime by a model reasoning over prompts, context, and tools it may discover, so identity proves what is running without predicting what it will do next. That is why the enterprise binding has to capture an approved deployment, including the code, model, system prompt, tool set, and security-relevant configuration, and why even that deployment is not the last word.

The useful historical lesson is narrower than “the layer always wins”:

Distribution determines the default. Standard seams determine whether the default can be challenged.

Agents inherit both sides of that lesson. Runtime vendors have the distribution advantage because their deployment event creates the instance. A separate binding layer has a market only if it can consume runtime evidence and supply governed identity context that issuers and resources will accept.

The Runtime Owns the First Proof, Not Every Conclusion

An employee generally exists before an identity system records them. A source such as HR establishes the employment relationship, and a directory turns that relationship into accounts and credentials. A workload instance is different: it comes into existence when a scheduler, serverless platform, device, or agent harness starts it, and its initial key and the evidence about its execution environment originate there.

That makes the runtime, or a trusted attester in its control plane, an unavoidable evidence source. It does not make the runtime a sovereign authority. Attestation is a signed claim evaluated under a verifier’s policy. Depending on the system, it may establish that a key is held by a particular workload, that the workload was launched under a particular service account, or that measured software and hardware satisfy a profile. It does not inherently establish:

• who inside the enterprise is accountable for the logical agent.
• whether this code, model, system prompt, tool set, and configuration form an approved deployment.
• whether the agent is eligible to act for a particular user or organization.
• which task justifies the requested authority.
• whether a particular resource should accept the resulting credential.

Consider an enterprise running the same logical research agent in Azure, Google Cloud, and a third-party harness. At 2 a.m. a data-loss alert fires on a document store, and the trace ends at an agent credential. The first three questions are not cryptographic. Whose agent is it? Which approved deployment is it running? Is the task it was doing still approved? In a bundled world each runtime answers with its own console, its own identifier scheme, and its own fragment of the story, and the on-call engineer is doing entity resolution across three vendors while the agent keeps running. Each platform produced the best local evidence about the instance it ran. Nobody owned the binding that turns three local identities into one accountable agent.

The layered system does not pretend the three runtime identities are identical. It verifies each one, binds each to the same enterprise-governed agent and deployment where policy permits, and preserves that relationship in audit. Portability is not carrying one private key or one opaque identifier between runtimes. It is being able to change the runtime without rebuilding ownership, policy, and accountability from zero.

That control point above attestation is the binding layer, the system that accepts evidence from supported runtimes and maps an instance to an enterprise-owned Agent and approved Agent Deployment. It supplies that governed binding as an input to credential issuers, policy systems, and resources. It may be co-located with an issuer, but it does not manufacture task authority or replace resource policy. The first essay left this role open. Now it has a job description.

Three Ways the Market Can Close

There are three plausible plays for that control point. They fail under different conditions.

Google Agent Identity is the clearest bundled play, with runtime-bound identity, Google IAM, policy, credentials, and audit in one platform. Entra Agent ID can span the first two plays. Paired with Microsoft agent runtimes and resources, it can operate as a bundle. Integrated with third-party agent platforms through its sidecar or workload-federation patterns, it is a bid for the enterprise binding layer above them. An agent provider claiming to be the IdP is attempting the third play.

The layered strategy also gained a narrower foothold in mid-2026. Okta’s Cross App Access and MCP’s stable Enterprise-Managed Authorization extension put an enterprise IdP into the credential path between requesting and resource applications. A companion note separates what actually shipped: a stable MCP extension, a live Claude and Okta beta, and a broader early-adopter coalition still rolling out. ID-JAG identifies the enterprise user and the OAuth client, while the resource authorization server retains token issuance and local policy. That is credential projection arriving with distribution. It does not yet verify runtime evidence or mint portable Agent and Agent Deployment records, so it demonstrates the layered play’s delivery strategy rather than completion of the binding layer.

The bundled play should not be dismissed as lock-in wearing a product label. It starts with the strongest distribution and can deliver the simplest operating model. The layered play has to earn its place by solving a real heterogeneity problem better than native IAM does. The provider play has to make its external trust and accountability model legible enough that an enterprise can adopt it deliberately. The layered play also has to be as invisible as the bundle, because if enterprise binding is a per-team integration project, friction alone decides the market. The layer has to arrive as a property of the paved road, with enrollment and binding as side effects of the deployment pipeline and platform base image. The layer that wins is the one nobody has to implement.

Where the returns accumulate decides more than the taxonomy does. The runtime and harness observe instance creation, configuration, task context, tool calls, and behavior over time, and that observation feeds the policy, detection, and audit products that make a bundle sticky. A binding layer sees only what is exposed to it unless it becomes the point where identity and deployment evidence aggregate. The decisive integration is not only between runtime and binding layer but also between issuer and resource, because portable evidence means little if every important resource accepts only the incumbent issuer’s credentials.

The layer’s answer to both is durable state. If the runtime remains the system of record for the Agent, Agent Deployment, eligibility policy, and identity audit history, an external verifier is not a control plane. It is an adapter. The binding layer becomes defensible when those enterprise records, deployment approvals, runtime mappings, and incident relationships survive changing runtimes. Task approvals do not belong in that record. They are the third control point.

The likeliest near-term outcome is none of the plays and all of them. Different teams adopt different runtimes for different agents, and the enterprise arrives at the hybrid mess by default, three notions of what an agent is and three audit trails that do not join. That is the 2 a.m. scene as a steady state, and nobody chooses it. A growing class of enterprise does choose the spread itself, multi-sourcing inference and routing work across model suppliers by cost and capability, which makes heterogeneity a procurement strategy rather than an accident, and the binding layer a design input rather than a cleanup.

The architecture determines which plays are possible. The market still determines which one wins.

The Harness Owns Execution Continuity. It Can Still Reach for More.

So far, runtime has mostly meant infrastructure, the platform that starts the instance and protects its key. The harness is a different kind of runtime: it is where the task is expressed, where the loop executes, where the agent discovers what it needs mid-flight, and where credentials may be acquired and presented so that agent logic never touches them. It owns execution continuity: sessions, queues, retries, tool connections, and sub-agent handles. That makes it an evidence source for facts a cloud platform may not see, including which model and harness build ran. It does not make the harness the authority for whether the task is legitimate or still approved.

Measured against the five jobs, that position is broader than the infrastructure runtime’s. The execution platform can vouch for an instance and key. A model-provider harness may also see the requested work, tools in play, and connections the agent attempts, and it may authenticate the human directly because the account holder is its customer. In an enterprise estate, those observations still feed enterprise binding and task-authority decisions rather than replacing them. In the open world, the harness can plausibly integrate provider seam, local identity, approval UX, and credential issuance in one product, which is why a model provider does not fit neatly into one row of the plays table.

The enterprise is where that ambition meets a counterweight. There is a buyer with its own Agent records, its own policy, and a requirement that governance span vendors, which is the demand the binding layer exists to serve. Authority follows governance, not execution. The open world has no equivalent buyer. When a consumer’s agent books travel, or two companies’ agents meet without a pre-negotiated trust relationship, no enterprise control plane mediates the connection. The parties present are the resource and harness, and the natural identity issuer and approval host is whichever provider has distribution on both sides of the connection. Today that is a short list of model providers.

The last generation split along exactly this line. Enterprise identity went to the layer. Consumer identity went to the platforms, and Sign in with Google or Apple became the de facto issuers of the open web even though OpenID Connect was an open standard anyone could implement. Open seams did not prevent consolidation where no buyer demanded a layer. They lowered the cost of integrating with the winners.

Enterprise federation shows when a layer can emerge. Consumer identity shows when it will not. Workload federation supplies the technical pattern agents can reuse.

Agents span both worlds, and the market may split the same way. The binding layer is contestable in the enterprise because the buyer wants it to exist. In the open world the default is more likely to be harness-issued identity and approval, with resources accepting the handful of issuers they already recognize, because verifying an unknown issuer is work and trusting a familiar one is cheap. That is the consolidation an open agent ecosystem has to beat, and it is the strongest reason the seams in the next section matter beyond the enterprise. They are what can make trusting an unfamiliar issuer tractable.

Standards Make the Layer Possible, Not Inevitable

A layer cannot be built from positioning slides. It needs a sequence of technical seams:

1. the instance obtains a key-bound identity or evidence from its execution environment.
2. a verifier outside that environment can validate the evidence under an explicit trust policy.
3. an enterprise system can bind the verified instance to a logical agent, owner, and approved deployment.
4. an authorization server can project that binding into a short-lived, sender-constrained credential.
5. the target resource can understand and accept the projected authority.

Parts of that sequence exist today. Others are still being designed:

Read together, these mechanisms could support a layered flow: runtime evidence in, enterprise policy applied, resource-specific credential out. A standard wire format does not create an accepted attester. Cryptographic verification does not create organizational accountability. Token exchange does not make the target resource trust the issuer.

Standards make binding and issuance contestable by preventing one runtime from being the only party technically capable of interpreting its evidence. They do not guarantee a neutral layer a customer, a viable business model, or acceptance at the resource.

They also have a clock, the same one the MCP companion turns into an adoption test. The seams in the table above face the same clock. The ones whose first useful deployment fits inside one buyer’s control, on rails already deployed, can ship inside products and consolidate afterward. The ones whose first useful result requires the ecosystem to move together risk ratifying whatever default hardened in the meantime. That is not an argument against the drafts. It is an argument about the vehicle. The shapes come from the specifications. The seams come from whoever ships the first complete loop.

Test Whether the Binding Layer Is Real

Binding captivity is less visible than a proprietary API. A platform can claim standards support while keeping the consequential identity decisions inside its own boundary. An enterprise evaluating an agent platform should ask:

1. Can an independent verifier validate the runtime evidence? A signed blob that only the vendor’s service can interpret is a vendor API, not a trust seam.
2. Can we keep our own agent and deployment records? Runtime enrollment should bind to enterprise ownership, approved configuration, and lifecycle state rather than replace them.
3. Can an issuer we choose mint a credential bound to the instance’s key? Verification that cannot feed an external issuer leaves the runtime vendor in control of usable identity.
4. Will our resources accept that credential? Portability at the attestation layer is irrelevant if every important resource requires a vendor-native principal.
5. What survives a runtime change? Ownership, policy, deployment history, incident evidence, and audit relationships should remain intelligible even when the local instance identifiers and keys change.

These questions reveal whether the runtime supplies evidence to a larger control plane or quietly is the whole control plane.

The Binding Layer Is Not the Approved-Work Layer

Pass all five tests and one of the 2 a.m. questions is still open. The binding layer can say whose agent it is and which approved deployment it is running. It cannot say whether the task the agent was doing is still approved, because that is not an identity fact. It is an authority fact with its own lifecycle, and it needs its own control plane.

Autonomous execution strains identity-anchored authority in a specific way. Workforce authorization often anchors authority to who someone is through roles, group memberships, and standing grants. A logical agent can also be durable, but its instances are created rapidly, it can pursue many tasks at once, and each task can end long before the Agent record does. Anchor all authority to the logical Agent and every grant risks becoming standing privilege shared across tasks and instances. Give the research agent from the 2 a.m. scene a standing role and the compromise that fired the alert hands the attacker everything the role can reach for as long as the credentials live. Bind projected authority to approved work instead and the intended blast-radius ceiling becomes the task boundary. The durable object is the approved task itself, a governed record with its own owner, state, and expiry: the third of the three objects with three lifecycles named above.

Today the approved-work control plane exists mostly by accident, absorbed by the same actors this post has been mapping. Harness session state and permission prompts approximate approval state. The OAuth grant supplies reusable delegated authority. Neither is a portable record of the undertaking, its lifecycle, and its authority ceiling. So the market question repeats one layer up, with the same distribution dynamics and thinner seams, because the artifact that would carry task authority across vendors has no general form yet. The binding layer decides who can say what your agents are. The approved-work layer decides who governs why their authority exists and when it ends. An enterprise that wins the first and defaults on the second has an accountable inventory of agents whose task authority still lives in vendor consoles and scope strings.

The two planes compose rather than compete, and the resource retains the last word:

Permit = valid runtime evidence AND eligible Agent and Agent Deployment AND live approved task AND valid credential AND resource policy permits.

The registry gates on Agent and deployment state. The approved-work layer gates on task state. Credentials gate on their own validity. Resource policy evaluates the concrete action. Much of that state can be projected into short-lived, sender-constrained credentials and checked locally. Consequential actions can require a current decision. The third essay defines those assurance choices without pretending every tool call needs a central network hop.

The Bundled Play May Still Win

The historical analogy is a hypothesis, not a prophecy. Three developments would weaken it.

First, enterprises may standardize on one agent runtime deeply enough that cross-runtime governance never becomes a high-priority problem. Second, runtime vendors may expose excellent portable attestations while customers still prefer native IAM because its integration and economics are better. Third, downstream resources may anchor authorization to runtime-specific principals, leaving an independent binding layer with nowhere useful to project its decisions.

In any of those worlds, the bundle can win even with open standards. That would not erase the distinction between attestation, enterprise binding, approved work, and resource policy. It would show that customers chose one vendor to operate several roles. The same test applies one layer up. A single-vendor estate may decide the vendor’s approval system is where approved-work state lives and make that choice deliberately rather than by default.

The stronger claim is conditional, and the condition is the couplet this series keeps returning to. Distribution determines the default, and runtimes have the distribution at instance creation. Seams determine whether that default can be challenged, and the seams are being drawn now in working groups and early products. Whoever mints the first runtime proof has the first word. It does not have a natural right to the Agent record, approved deployment, approved task, or every credential the agent will ever use. Those stay separate only if buyers demand it and the seams make demanding it cheap. The demand has an engine the identity market did not have to build. Enterprises are already decoupling the harness to keep their memory, context, and model choices their own, and identity portability rides the same procurement motion.

The runtime gets the first word about every agent it runs. The seams decide who gets the last one.