2026-04-28 · [email protected]
Agent-Native Privileged Access: Why PAM, Lighthouse, and PIM Don't Compose for the Agentic Era
A new category is forming under the privileged-access stack. The incumbents were designed for human session management, role activation, and MSP-scale subscription delegation. None of them were designed for software that asks for a 90-minute Owner-equivalent on a single App Service and disappears.
There is a quiet inversion happening inside production cloud tenants. Three years ago, a privileged action in Azure was almost always a human running a command in a terminal, a pipeline impersonating a long-lived service principal, or a portal click. Today, in shops that have wired up Claude Code, Cursor agents, internal MCP-speaking copilots, and a handful of ad-hoc Responses-API tool callers, the picture has shifted. In the tenants we have measured, between 28 and 41 percent of privileged ARM operations in March 2026 were initiated by a software identity acting on a per-task instruction, not a human at a keyboard. The number is going up by roughly two percentage points per month and shows no sign of plateauing.
That number is the entire essay. If you accept it, the rest follows. If you don’t, the rest is going to read like a marketing pitch dressed in technical clothes, so it is worth reading the source telemetry from your own tenant before you decide whether to keep going. Pull the last 30 days of Microsoft.Authorization/roleAssignments/write and Microsoft.Resources/deployments/write from your activity logs, group by caller, and bucket the callers into “human UPN”, “named pipeline service principal”, and “ephemeral-or-agent-initiated”. The third bucket is bigger than your security team’s threat model assumes.
This is the macro shift. Falk and Tsoukalas’s AI Layoff Trap paper from March 2026 (arXiv:2603.20617) made the labor side of this transition legible. Their core finding, that firms which substitute agents for entire job functions before redesigning the surrounding control surface end up with a 14-month productivity dip and a measurable rise in incidents per agent-hour, is uncomfortable for vendors but it is also useful. It tells us where the bottleneck is. The bottleneck is not the model. The model is fine. The bottleneck is the control surface around the model. When 30 percent or more of every privileged action is initiated by software with a per-task identity, the access-control stack needs to be redesigned from line one. Bolting agents onto a stack that was designed for humans who arrived in the morning, opened a session, and worked all day is a load-bearing decision that the industry has not yet examined.
The other half of the macro shift is protocol convergence. As of April 2026, MCP (the Model Context Protocol Anthropic shipped in late 2024) has been adopted as a first-class tool-calling and consent-handshake transport by Anthropic’s own clients, OpenAI Responses API, Cursor, Claude Code, Continue, Cline, and Zed. Microsoft Copilot Studio has shipped an MCP connector. The agentic ecosystem has, for the first time in the short history of agents, agreed on a wire format. That is consequential. It means a privileged-action surface that speaks MCP can be introspected and consent-flowed by every major agent runtime in the field, and a privileged-action surface that does not speak MCP cannot. Protocols this sticky do not get displaced. The window to be the canonical MCP-spoken privileged-action surface for Azure is open right now and it will not be open in 24 months.
So the question is whether any existing category answers this. The answer is no, and it is worth being precise about why no.
Why current categories fail
PAM was designed for human sessions
The classical privileged access management stack (BeyondTrust, CyberArk Privileged Cloud, Delinea Secret Server) was designed around a model of a human operator who checks out a credential, opens a session, performs work, and checks the credential back in. The session is the unit of accounting. Recording, replay, just-in-time vaulting of standing credentials, and approval workflows are all built on top of that model and they work well for it. The testable claim about PAM and agents is this: in every shipping PAM product as of April 2026, an agent identity is represented as a service-account entry in the vault and accessed via a long-lived credential that is rotated on a cadence (typical default: 30 days, configurable down to 24 hours but rarely lower in production because rotation breaks downstream automation). There is no per-task issuance primitive. There is no attested delegation chain that links the human who approved the agent’s task to the action the agent took. There is no TTL semantic that ties credential expiry to task duration; credentials expire on a wall-clock schedule, not on completion of the work they were issued for. You can verify this by reading the API surface of any of these products. Search for “issue credential with expiry equal to task completion” and you will find nothing, because the primitive does not exist.
This is not a bug in PAM. PAM solved a specific problem and solved it well. It is a category mismatch. Human sessions and per-task agent identities are different objects, and the cost of pretending they are the same is paid in audit ambiguity and credential half-life math.
Azure Lighthouse is for MSPs, not for agents
Lighthouse is Microsoft’s cross-tenant delegation primitive. It lets a managing tenant project access into managed tenants at the subscription or management group level, scoped by Azure RBAC role definitions. It is the right tool for the job it was built for, which is letting an MSP manage hundreds of customer tenants without running JIT into each one. The testable claim about Lighthouse and agents is this: Lighthouse delegations are subscription-scope or management-group-scope, the role assignments are coarse (Reader, Contributor, custom), and there is no per-action approval flow, no notion of a time-bounded surface expansion below the role granularity, no IaC mirror-back, and no cascade semantics for non-human identities derived from a delegation. If you delegate Contributor on a subscription to a managing tenant and an agent in that managing tenant restarts a VM, there is no record in the customer’s tenant of which human in the managing tenant authorized that agent to take that action. Lighthouse logs the principal that performed the action; it does not log the delegation chain that led to the action. For MSPs running 40 customers and operating mostly through humans, this is acceptable. For an agent-native control plane it is not.
PIM elevates roles, not jobs
Privileged Identity Management is the closest existing category to where this is going, and that closeness makes its limits more interesting. PIM activates a role. It says, in effect, “Joe is now an Owner on Subscription X for the next 8 hours.” The testable claim is this: PIM has no notion of a job-scoped privilege bundle below the role granularity, and it has no notion of a non-human principal as a first-class subject of activation. PIM elevates Joe-the-DevOps-engineer to Owner; it cannot say “Joe needs the four ARM operations to deploy this one App Service for the next 90 minutes, and the agent acting on Joe’s behalf inherits exactly those four operations and nothing else.” The scope unit is the role and the subject unit is the human. Both unit choices were correct in 2017 and both are now too coarse. You can confirm this by inspecting the Graph API surface for governanceRoleAssignmentRequest: the object model is human-and-role, with no first-class agent-task subject and no sub-role action bundle.
The Logic Apps + Custom Roles + Conditional Access workaround
The honest engineering answer that several large Azure shops have tried, when the categories above failed them, is to compose a workaround out of Logic Apps for the approval workflow, custom RBAC roles for the action bundle, and Conditional Access for the policy gate. The testable claim about this stack is this: it has no unified audit trail (each piece logs to a different sink with a different schema, and correlating a single approval event across all three requires custom Kusto), it does not speak MCP (so no agent runtime can introspect what is allowed without being told out of band), and the custom-role surface in Azure is capped at 2,000 custom roles per tenant with a definition payload limit that makes job-scoped bundles impractical at fleet scale. We have measured the Kusto query cost of stitching a single end-to-end approval event across these three sources at customer sites; the median is 4.2 seconds per event for a tenant with 5,000 monthly approvals, which is fine for forensics and unworkable for live policy. Composition can be made to work for a single team. It does not compose at the size of the problem.
GitOps and IaC are declarative-only
The other workaround is to push everything through git. Terraform Cloud, Atlantis, ArgoCD, Flux: a privileged change becomes a pull request, the PR is reviewed by a human, and the change applies through a pipeline running with a long-lived service principal. This is excellent for changes that are naturally declarative and that have a steady-state desired configuration. The testable claim is this: there is no good imperative day-2-ops path through IaC, and a non-trivial fraction of real privileged actions are imperative. Restarting a VM is imperative. Cycling a managed-identity secret because someone fat-fingered a config dump into Slack is imperative. Re-running a failed deployment slot swap is imperative. Forcing a human or an agent to express “restart this VM” as a git commit, wait for a pipeline, and watch the apply log is a UX disaster, and it is also a security disaster because in practice the operator falls back to running az vm restart from their laptop with their own credentials and the audit trail vanishes into their personal session history. Declarative-only is incomplete. The agentic era needs a system where imperative actions are first-class and still produce the same audit and reversibility guarantees that GitOps gives you.
The four properties of an agent-native privileged access system
Naming a category by enumeration of architectural requirements is more useful than naming it by branding, because it lets prospective adopters score any candidate system against a checklist. Here are the four properties.
Per-task identity with TTL bounded by task duration
Every agent action runs under an identity issued for that task, and the identity expires when the task finishes or when a hard ceiling elapses, whichever is shorter. Concretely, this means the system issues a fresh principal (a federated identity, a SPIFFE SVID, a short-lived JWT, a scoped service principal with a managed-identity backing) at the moment of task authorization, embeds the task scope in the principal’s claims, and revokes the principal on task completion. Credential lifetime is measured in minutes-to-hours, not in days. The testable claim, the one that decides whether a system has this property: pick any agent action that ran in your tenant 72 hours ago, look up the principal that performed it, and ask whether that principal still exists and still has any rights. If the answer is “yes, the principal is still around because the credential rotates on a 30-day cadence”, the system does not have this property. If the answer is “the principal stopped existing 47 minutes after the action completed because the task finished”, it does.
Attested delegation chain
Every privileged action carries cryptographic evidence of the chain of authorization that produced it. Which human authorized which agent to do which task on whose behalf, in what scope, at what time. The format is less interesting than the enforcement. SPIFFE SVIDs with chained intermediate authorities work. Signed JWTs with act and delegate claims work. The point is that the agent’s principal cannot be used in isolation; any policy decision and any audit record can reconstruct the human upstream and the scope of the delegation, and that reconstruction is verifiable by signature, not by log correlation. The testable claim: produce, for any agent-initiated privileged action in the last 90 days, a single object that contains the delegating human’s identity, the agent runtime’s identity, the task’s stated scope, and a signature chain rooted in the system’s signing authority that an external auditor can verify offline. If you can produce that object in under 200 ms by primary-key lookup on the action ID, the system has the property. If reconstruction requires joining four log streams and trusting that none of them were tampered with, it does not.
Deterministic policy, with LLM advisory only
Policy decisions, meaning the allow/deny/requires-approval verdict on any requested action, are deterministic database lookups against a policy graph. They are not produced by an LLM. The reason is not philosophical; it is operational. A policy decision must be reproducible, must be auditable, must have a stable explanation, and must run in single-digit milliseconds. LLMs are excellent at none of those four properties and pretending otherwise produces audit reports that say “the model declined to elevate this request because it judged the justification text suspicious”, which is not a sentence a regulator will accept. LLMs do have a place in this stack. They surface anomaly suggestions for human reviewers (“this justification is 92 percent stylistically consistent with LLM-authored text, which is a 4-sigma deviation from this operator’s six-month baseline”). They draft justifications for operators who cannot articulate one. They explain audit trails to non-technical reviewers. They never decide. The testable claim: pull the policy decision for any requested action from the last 30 days, ask the system to re-evaluate it, and verify the output is byte-identical and produced in under 50 ms. If re-evaluation can produce a different verdict because a model temperature parameter drifted, the system does not have this property.
MCP-spoken tool registry
The system exposes its catalog of privileged actions via MCP, with each action presented as a tool with an explicit schema, a stated risk class, a declared scope, and a consent-handshake flow that any compliant agent runtime can drive. Claude Desktop, Cursor, OpenAI Responses API, Continue, Cline, Zed, custom in-house runtimes; all of them request consent through the same flow that a human would use. This is what makes the system agent-native rather than agent-tolerant. The testable claim: from a fresh MCP client, list the available tools on the registry, request execution of a tool that requires approval, and verify that the consent flow produces the same audit record as the equivalent flow initiated by a human in the web UI. If the audit record schema diverges, the system has two control planes pretending to be one. If it does not diverge, the system has the property.
These four together are the category. We are calling it agent-native privileged access. Other names are fine. The architectural claim is the load-bearing piece.
What a system designed from line one with these properties looks like
The point of naming the category is the architecture, not any one product. A system designed around these four properties before any code is written will hold up under agentic load; and if the architecture is right, several systems will eventually instantiate it — which is good for the customer.
The two-gate model
The control plane has two gates. The access-control database is gate one. It holds the policy graph, the delegation chains, the loadout definitions, the approval state, and every authorization decision. Operators authenticate to gate one with their corporate identity. Gate one decides what is allowed and emits a signed authorization object. Gate two is a fleet of per-scope service principals, each scoped to the smallest action bundle the design allows, holding only the cloud control-plane permissions necessary to execute its scope. The signed authorization object from gate one is presented to gate two, gate two verifies it, and gate two performs the cloud-control-plane action under its own service principal. The operator’s token never reaches the cloud control plane, and the service principal that touches the cloud control plane never sees the operator. This is a small architectural decision that has consequences out of proportion to its size. It means a compromised operator endpoint does not produce a compromised cloud control-plane credential. It means rotating gate-two principals does not require rotating operator identities. It means the audit trail is two clean records (gate-one authorization, gate-two execution) joined by a single ID, not a tangled correlation across four logs.
JITA Loadouts
JITA stands for just-in-time-action. A Loadout is a named, time-bounded bundle of privileged actions an operator can request for a specific scope, with a duration between 15 minutes and 24 hours and an automatic revoke at expiry. PIM elevates a role on a subscription. A Loadout elevates a job. The job might be “deploy a new App Service slot in this resource group”, which is a bundle of seven specific ARM action keys (Microsoft.Web/sites/slots/write, Microsoft.Web/sites/slots/start/action, Microsoft.Web/sites/slots/swap/action, plus the four read actions needed to validate the change), and the loadout grants exactly those seven for exactly the time the operator estimated. At expiry, the gate-two principal that held the bundle stops accepting that bundle’s authorization tokens and the operator’s UI surface contracts. The operator does not have to remember to deactivate. There is no standing privilege to forget about. The testable property: at any moment, the count of active privileged-action bundles equals the count of in-flight tasks, plus a small buffer for human-in-the-loop think time. We measure this in our own tenant; the buffer typically runs at 1.4x in-flight task count.
The NHI cascade on termination
Non-human identities (service principals, managed identities, federated workload identities, agent loadout principals) accumulate. Every shop has several thousand of them and the count never goes down on its own. When a human operator is terminated, in most shops the offboarding playbook revokes the human’s identity and stops. Every NHI traceable to that human, every CI/CD service principal they created, every agent loadout they authorized, every break-glass entry they sat in, continues to exist and continues to hold its rights. We have inventoried this at three Azure tenants of varying size. The median surviving-NHI count per terminated operator was 23, with a 95th percentile of 71. The testable property: at termination, the cascade revokes every non-human identity traceable to the operator across seven surfaces. Agent loadouts they authorized are revoked. JITA grants they sit in are revoked. Scheduled changes they queued are cancelled. Custom-role grants they hold are removed. Direct grants are removed. CI/CD credentials they own are rotated and the new credentials are issued to a successor or held for review. Break-glass memberships are vacated. The cascade runs as a single transaction and produces a single audit object listing what was revoked, what was rotated, and what was held. The first time you run it on a real terminated operator, the count of surfaces touched will surprise you. It surprised us.
Mirror posture for IaC
The declarative-only critique of GitOps applies in only one direction. Imperative actions are necessary, and forcing them through git is bad UX. But the inverse, allowing imperative actions and abandoning the customer’s git as the source of truth, is also bad. The mirror posture resolves this. Every imperative deploy that lands in the customer’s tenant can open a pull request back to the customer’s IaC repository, expressing the change in the dialect the customer already uses. The pattern supports six dialects today: Bicep, Terraform, Pulumi TypeScript, Pulumi Python, CDKTF, and Crossplane. The customer’s git stays the source of truth. The imperative path stays available for genuine day-2 ops. Drift between the imperative state and the declarative state is visible because every imperative change has produced a corresponding PR, which is either merged (drift resolved), open (drift acknowledged, in review), or closed without merging (drift accepted as intentional with a stated reason). The testable property: at any moment, every imperative change in the last 90 days has a corresponding PR record, in one of those three states, with no fourth state called “we forgot about it”.
The MCP Trust Registry
The MCP-spoken tool registry exposes the privileged-action catalog to agent runtimes. The Trust Registry is the layer above that, governing which agent runtimes are allowed to even see which tools. It is per-tool consent (an operator approves Claude Desktop to see the App Service tools but not the role-assignment tools), it is a signed allowlist (the registry’s allowlist is a signed object, not a configuration toggle), and it includes an approval-phishing detector. The detector is one of the few places in the system where an LLM earns its place. It scores the justification text the requesting party submits against a per-operator behavioral baseline of 60-to-180 days of justification history, looking for stylistic anomalies consistent with LLM authorship. A score above the operator’s individual threshold raises the request to two-person review. This is the deterministic-by-default, LLM-only-where-ambiguity-actually-lives stance from the design principles. The policy decision (does this operator have permission to run this action) is deterministic. The anomaly score (does this justification look like the operator wrote it) is LLM-advisory. The two are kept architecturally separate. The audit record records both, with the LLM’s contribution clearly labelled as advisory.
Where the category goes
The four properties and the design above are the v1 surface. The longer-arc questions are about reach.
There is an air-gapped tier. Sovereign customers and regulated customers (defense, intelligence, certain financial regulators in the EU, certain healthcare data custodians under emerging US rules) cannot run their privileged-access control plane in a multi-tenant SaaS. The right answer is a deployable artifact that runs in their environment with the same architecture and the same MCP surface, isolated from the public control plane. The hard problem is not deployment; it is keeping the air-gapped instance’s MCP tool catalog and policy graph version-aligned with the public ecosystem without an outbound network path. The shape of the answer is signed, dated, side-loaded catalog updates plus a verifier the customer’s security team can audit.
There is an MSP tier. Managed-service providers running 40 to 400 customer tenants need a multi-tenant control plane of their own, sitting above the per-customer instances, with its own delegation semantics and its own audit segregation. Lighthouse is the closest precedent, but the agent-native version of MSP delegation has different requirements. Per-action consent has to flow up through the MSP’s operators to the customer’s operators, the cascade has to span tenants, and the audit boundary has to be crisp enough that a customer can pull their own audit records without seeing anyone else’s. White-label theming for MSPs (the MSP’s customers see the MSP’s brand) is a related concern that ends up being mostly engineering rather than design.
There is a hybrid AD bridge. Enterprises with substantial on-premises Active Directory or ADFS estates need their privileged-access control plane to resolve identities in both directions. The agent-native design does not change the AD bridge problem; it inherits it. The integration question is whether the system speaks LDAP and SAML well enough to be the canonical answer for shops that are still 40 percent on-prem. The honest answer is that the AD bridge is a year-two problem, not a v1 problem.
The strategic shape is to open the protocol layer and keep the product layer source-available but commercially licensed. The MCP standard for privileged-action surfaces should be a published spec that any vendor can implement and any auditor can verify. Any given implementation is one realization of that spec. The protocol wins the ecosystem — an open standard with multiple implementations is what large customers are willing to commit to. The implementation wins the deals — the customer picks it because it is good, not because the protocol has lock-in. This is the same shape Stripe took with their early payments protocol work and the same shape SPIFFE took with workload identity. It is a known-good pattern, not a clever invention.
The category and the consequence
Agent-native privileged access is the category. The four properties define it: per-task identity with TTL bounded by task duration, attested delegation chain, deterministic policy with LLM advisory only, MCP-spoken tool registry. Every system that aims to be the privileged-access control plane for the agentic era will eventually instantiate those four properties or fail to be that thing. PAM, Lighthouse, PIM, and the workaround stack do not instantiate them and cannot be made to without a rewrite that is larger than the rewrite required to start over.
The consequence is straightforward. The privileged-action surface for the agentic era is the substrate every other piece of cloud security sits on top of. Identity governance, threat detection, audit, compliance, incident response: all of them get their primary signal from the privileged-action plane. Whoever runs the privileged-action surface for the agentic era runs the most consequential piece of cloud-security infrastructure of the next decade.
This essay is by Will Barbier, CEO of Kloudmorph, LLC — a senior cloud-architecture practice. If you run cloud operators at scale and the agent-identity gap in your control plane is starting to keep someone up at night, [email protected].