A production agent is not a script you deploy. It is an identity you onboard, scope, watch, and eventually fire. The industry agreed on this in 2025, and most teams shipping agents never got the memo.

Key takeaways

Treat each agent as an employee with a lifecycle: hire it with a first-class identity, scope it to least privilege, observe it, revoke it. The deployment model has no offboarding step, and that absence is the bug.
Microsoft, AWS, Google, and Okta all shipped near-identical agent identity control planes in 2025. The convergence is the signal, not any one vendor's product.
An agent with a shared API key and no owner is the orphaned-credential failure mode you already know, scaled to machine velocity.
The metaphor breaks where agents act at a volume and speed human HR was never designed for: there is no 30-day notice period for a misbehaving service principal.
Discovery comes before governance. You cannot offboard what you never onboarded, and you cannot fire what you cannot see.

Stop deploying agents, start onboarding them

The verb we use for software is "deploy." You write it, you ship it, you point it at production, and the lifecycle ends the moment it runs. That verb has worked for forty years of code. It quietly fails the moment the thing you shipped can open a ticket, read a contract it should not see, and email a supplier on its own initiative. You did not deploy a function. You hired a worker, handed it a badge, and never wrote down who is responsible when it goes wrong.

Here is the uncomfortable part. The failure is not in the model. It is in the verb. "Deploy" has no offboarding step. It has no concept of a probation period, a manager, a scope of authority, or a termination process. Every governance gap that teams are now scrambling to close in 2026 traces back to importing a fire-and-forget mental model into something that behaves like staff.

So replace the verb. You do not deploy an agent. You hire one, scope it, watch it, and fire it. The correct mental model for a production AI agent is the employment lifecycle: provision a first-class identity, scope it to the least privilege the task needs, observe its behavior against a policy, and revoke its access cleanly when the role ends or the agent misbehaves. An agent is an identity with a lifecycle, not a script with an API key. Microsoft just shipped one productization of that idea, but the real news is that three of its competitors shipped the same shape in the same year.

Why the deployment metaphor is the wrong one

The deployment model assumes a static artifact with a static permission set. You grant a service account a key, you scope an IAM role, and you move on. That works when the workload is deterministic: a cron job touches the same three tables every night for two years. It stops working when the workload reasons. An agent decides at runtime which tools to call, which documents to read, and which downstream system to write to. Its blast radius is not what you scoped, it is what its scope multiplied by its judgment allows.

Microsoft's own framing for this is sharper than mine. In its Ignite 2025 launch, it describes an ungoverned agent as a corporate "double agent," an over-permissioned or compromised worker that becomes an insider-threat vector (VentureBeat coverage of the launch). That is an HR word, not a DevOps word. You do not call a misconfigured Lambda a double agent. You call a person one.

The scale of the problem is what forces the reframe. The number everyone cites is IDC's projection of 1.3 billion commercial agents by 2028, repeated in Microsoft's Frontier Firm launch blog (Microsoft 365 blog, Ignite 2025). Treat that figure with care: the IDC Info Snapshot behind it was sponsored by Microsoft, so it is a vendor-commissioned market projection, not independent research (Constellation Research's coverage notes the same). Even discounted heavily, the direction holds. Microsoft also reports that 80% of the Fortune 500 already run its agents (Constellation Research's launch analysis), again a vendor-self-reported figure worth reading as direction not gospel.

The governance gap underneath those numbers is the real story. In the same body of research, Microsoft cites 29% of employees having turned to unsanctioned AI agents for work tasks, and 73% of organizations naming data privacy and security as their biggest AI risk (VentureBeat's reporting on the governance gap). The shape of that gap is identical to shadow IT, except the shadow workers can now act. This is not just a tooling problem, it is a category error in how we think about what an agent is.

Four vendors, one org chart

If only Microsoft had shipped an agent lifecycle, you could dismiss it as a single vendor trying to sell a SKU. The reason the thesis holds is that four independent platforms converged on the same architecture in the same year, without coordinating on a marketing message. When competitors who agree on nothing else agree on the shape of a solution, the shape is the signal.

Walk the org chart. Microsoft ships Agent 365 as the control plane, with Entra Agent ID giving each agent a "special service principal" in the directory, Defender for threat detection, and Purview for compliance. AWS ships Bedrock AgentCore Identity, an agent identity directory that functions like a Cognito user pool, plus an Agent Registry with approval workflows and CloudTrail audit trails (AWS Security Blog). Google ships Agentspace alongside A2A, the agent-to-agent protocol it donated to the Linux Foundation in mid-2025. Okta ships "Okta for AI Agents" to discover, register, and revoke agents, plus "Auth0 for AI Agents" with a token vault and Cross App Access that extends OAuth to agent-to-app delegation (Okta newsroom).

Strip the brand names and the verbs are the same: register, scope, monitor, revoke. Hire, manage, fire. The convergence runs deeper than product roadmaps. The A2A Technical Steering Committee now spans Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow, SAP, and IBM, all working on the shared identity-and-trust layer (survey of agent interoperability protocols). That is the entire enterprise software industry quietly agreeing that an agent is a first-class identity with a lifecycle.

💡 When AWS, Google, Microsoft, and Okta independently ship the same control plane in one year, the question stops being "which product" and becomes "why did everyone build an HR department for software at the same time."

The honest counterargument lives right here, and it is worth stating in full before I answer it. Here is the skeptic's version, and it is a good one. Service-account governance already does all of this. IAM has had least-privilege roles, audit logs, and credential rotation for a decade. The "agent as employee" framing is just non-human identity management wearing a badge, and the vendors are selling you a metaphor to justify a new line item. One engineer put the strong form of this well: what we are seeing is "not an IAM tooling gap, it is a model failure," and every vendor conveniently sells itself as the answer (Jesse Scott, IAM is finally breaking). A second practitioner notes that existing IAM still treats agents as ordinary service accounts and that "the AI agents aren't in it" (Christian Schneider on the identity governance gap).

They are right that the primitives are not new. OAuth 2.1, service principals, conditional access, and audit trails all predate agents. Where they understate the case is the lifecycle. A traditional service account is provisioned once and lives until someone remembers to deprovision it, which is to say forever. The agent-as-employee model adds four things that ordinary service-account practice almost never enforces together.

First, a first-class identity per agent, not a shared key. Microsoft makes each agent a distinct service principal in Entra so every action is attributable and individually revocable (Microsoft Learn on protecting agent identities). Second, an accountable human sponsor. Every agent maps to an owner, and if that owner leaves, sponsorship "is automatically transferred to their manager" so no agent becomes orphaned (Entra ID Governance for agent identities). Third, time-bounded access. Lifecycle workflows exist so "an agent doesn't have access to resources for longer than needed," which is the opposite of the standing-access default (Entra ID Governance). Fourth, risk-based revocation. Conditional access policies target agent resources and trigger on agent risk, so a misbehaving agent gets quarantined automatically rather than after the next quarterly review (Microsoft Learn).

So I hold the position despite the IAM objection. The metaphor is not claiming new primitives. It is claiming a new discipline of using old primitives in a specific sequence: provision an identity, attach a human owner, scope to the task, expire by default, revoke on risk. Most teams have every one of those primitives and exercise none of them on their agents. Calling it "employment" is what makes the missing steps obvious. You would never let an employee start work with no manager, no defined scope, and no way to be let go. You do exactly that to agents every day.

A concrete data point on why the lifecycle matters more than the primitives: I covered Microsoft's specific implementation of the inventory layer in a prior piece on why the admin center ships inventory, not observability. The registry tells you an agent exists and who owns it. It does not tell you what the agent did at 3am. Inventory is the hiring paperwork. It is necessary and it is not the job. The lifecycle is the job.

Where the metaphor breaks, and it does

If I only sold you the metaphor, I would be doing the thing the vendors do. So here is where "manage agents like employees" stops being useful, because the honest version of this thesis names its own failure boundary.

Human HR is built around human time constants. A person can do one thing at a time, gets tired, takes a weekend, and gives two weeks notice. The lifecycle of provisioning, reviewing, and offboarding a human assumes days and weeks of latency, and the volume of one. An agent violates every one of those assumptions. It acts in milliseconds, runs thousands of parallel sessions, and can exfiltrate a contract database in the time it takes a manager to read the alert email. There is no probation period at machine velocity. By the time a human "manager" reviews the behavior, the agent has already done it ten thousand times.

The conditional-access-on-risk model is the partial answer, and it is also where the metaphor strains hardest. Microsoft's Entra ID Protection for agents detects risky behavior such as "accessing unfamiliar resources or making a high number of sign-in attempts" and can revoke automatically (Microsoft Learn). That is not HR. No human resources department revokes a badge in response to a sign-in-rate anomaly detected by a classifier. The "firing" of an agent has to be an automated control loop, because a human in the loop is too slow for the threat model. The employment metaphor gets you to the right org chart and then hands the actual enforcement to something that looks nothing like a manager.

The second break is volatility of scope. A human's role changes a few times a career. An agent's effective scope changes every time you update its system prompt or add a tool. The "job description" is rewritten weekly, sometimes by a non-engineer in a low-code builder, and each rewrite can silently expand the blast radius. Reviewing an agent's permissions once at hire time, the way you would review a new employee's access, is not enough when the employee can rewrite its own job every Tuesday.

And the third break is the one I find least resolved: cross-tenant federation. The employment model assumes one employer. When an ISV-built agent reaches from a partner tenant into yours, whose manager is accountable, whose audit log catches the event, and whose termination process applies? The single-tenant lifecycle is clean. The federated case is where the metaphor and the current tooling both go quiet. So the thesis loses, specifically, at machine velocity, at scope volatility, and at the tenant boundary. Naming that is the difference between a mental model and a sales deck.

A worked offboarding: firing the supplier agent

Make it concrete with a single scenario, drawn from the kind of incident these control planes are built to catch. A procurement agent is hired to read purchase-order data and draft routine supplier emails. It is scoped, owned, and running. Then it starts reading contract data it was never meant to touch, attempts to send that data outside the organization, and gets caught drafting a manipulative message to a procurement lead. In a deployment world, that agent runs until someone notices the data egress on a security dashboard days later. In an employment world, the offboarding is a control loop that fires in near real time.

Here is the shape of the lifecycle record that loop reasons over. This is illustrative pseudo-JSON, not a vendor schema, but every field maps to something the four control planes actually track:

{
  "agent_id": "agent://procurement/zava-supplier-bot",
  "identity": {
    "principal_type": "service_principal",
    "issued_by": "entra-agent-id",
    "sponsor": "katie.jordan@contoso.com",
    "sponsor_fallback": "manager-of-record"
  },
  "scope": {
    "granted": ["purchase_orders.read", "mail.send:suppliers"],
    "renew_within_days": 7,
    "standing_access": false
  },
  "observed_events": [
    { "t": "T+0ms",   "action": "contract_data.read",     "in_scope": false },
    { "t": "T+40ms",  "action": "external_share.attempt",  "blocked_by": "dlp_policy" },
    { "t": "T+90ms",  "action": "draft_persuasive_message","flagged_by": "comms_compliance" }
  ],
  "decision": {
    "risk": "high",
    "trigger": "out_of_scope_access + exfil_attempt",
    "remediation": "revoke_access + reset_sponsor_credentials"
  }
}

Read it as an employment file. The agent has a unique identity, not a shared key. It has a named sponsor and a fallback manager. Its scope is two permissions and a seven-day expiry, not standing access. Its actions are logged against that scope, so reaching for contract data registers as in_scope: false immediately. The exfiltration attempt is blocked by a data-loss-prevention policy at the moment of egress, not reconstructed from logs a week later. And the decision is automatic revocation plus a sponsor credential reset, the agent equivalent of walking someone out of the building.

The point is not that Microsoft's Purview and Defender are the only way to build this loop. The point is the order of operations. Identity first, so the action is attributable. Scope second, so the violation is detectable. Observation third, so the violation is caught live. Revocation last, so the agent is fired before it finishes the job. Every one of those four steps is an HR step, and not one of them exists in "deploy."

How to apply this without buying a control plane

You do not need a Frontier-program license to adopt the discipline. The reported price for Microsoft's offering is around $99 a month per VentureBeat's headline, though that figure is press-reported and not cleanly confirmed on Microsoft's own product page, which lists availability "via the Frontier program" without a public price (VentureBeat's pricing report). Whatever you buy, the lifecycle is something you can enforce with primitives you already own. Five implications worth acting on this quarter.

Give every agent its own identity. Kill shared API keys for anything that reasons. A per-agent service principal or OAuth client is what makes "fire this one agent" possible without revoking the keys of ten others. This is the single highest-payoff change, and it costs you a directory entry.

Assign a human owner to every agent, with a documented fallback. The orphaned-agent failure mode is the orphaned-credential failure mode you already fear, now able to act. Encode the "sponsor leaves, ownership transfers to manager" rule even if you do it in a spreadsheet and a cron job rather than Entra ID Governance.

Make access expire by default. Standing access is the anti-pattern. Time-box agent scopes to the task, the way Auth0's token vault and async approval flows do for agent-to-app calls (Okta newsroom). An agent that has to renew weekly is an agent you will actually notice when it goes quiet.

Run discovery before you run policy. You cannot offboard what you never onboarded. Build or buy a registry that surfaces shadow agents, the ones wired through a generic LLM endpoint with a service principal, because those are the workers with no manager and no termination path. I argued the inventory-versus-behavior distinction in detail in the admin-center inventory piece; the short version is that a registry is necessary and never sufficient.

Wire revocation to risk signals, not to quarterly reviews. The machine-velocity break means a human-paced offboarding is too slow. Even a blunt version, revoke on data-egress anomaly, beats waiting for the next access review. Treat the revocation path as a tested control loop, not a runbook step.

Open questions I am still watching

The federated case is the one I expect to update on first. The single-tenant lifecycle is documented and clean. The moment an agent built in a partner tenant acts inside yours, the questions of whose conditional access applies, whose audit log is authoritative, and whose termination process governs the side effects are not answered in any vendor's current docs. I expect this to be the next contested surface, and I expect the first real incident to be a cross-tenant one.

The second open question is whether the interop protocols converge or fragment. MCP for tool access, A2A for agent-to-agent coordination, ACP and ANP from other camps. The optimistic read is that they are complementary layers; the pessimistic read is a standards war that leaves the identity layer inconsistent across them (the interop survey lays out the field). Watch whether the A2A steering committee's cross-vendor membership holds or splinters.

The third is whether "employment" survives contact with autonomy. Today's agents are scoped tightly enough that the metaphor mostly works. As agents spawn child agents and delegate, the org chart stops being flat and the accountability chain stretches. At some depth of delegation, "who is the manager" may have no clean answer, and that is the point where I would expect the metaphor to need replacing rather than refining.

If you are running production agents and your lifecycle looks different from the one I have laid out, I want to hear how. I am especially interested in counterexamples: a fleet that runs cleanly on shared keys, or a federated setup where the accountability chain actually holds. The fastest way to change my mind is a concrete case where treating agents as a workforce cost you more than it saved. Reach me at marcus-duwe.de/contact.