The Invisible Grant: How Workflow Platforms Became Identity Systems Without Saying So

The Move

In April 2026, ServiceNow expanded its AI Agent Orchestrator with what the company described as "scoped credential assignments" — a capability allowing AI agents to be provisioned with role-based access inside Now platform workflows. The announcement landed in a product blog post, got picked up by a few enterprise software newsletters, and was largely framed as a governance feature: responsible AI, auditability, the kind of thing you add when enterprise customers start asking hard questions about what their agents are actually doing.

That framing isn't wrong. It's just not the interesting part.

The interesting part is what the feature reveals about something that was already happening, not what it introduces. ServiceNow surfaced identity functionality that was already embedded in workflow logic, running at scale, largely unexamined. The scoped credential assignment is the label on a door that was already open.

The Puzzle

Here's the question I keep returning to: if every agent task assignment is structurally an access grant, why has no one in the workflow governance conversation been auditing them as such?

That's not rhetorical. I mean it as a diagnostic question. When a ServiceNow workflow assigns an AI agent to process an IT service request, that assignment carries with it a set of permissions — what systems the agent can query, what records it can read or write, what actions it can take downstream. The assignment is the access decision. The task and the credential are the same thing, just described in different vocabularies.

Workflow teams don't use the word "grant." They use words like "scope," "role," "assignment," "task." Identity teams use words like "entitlement," "certification," "access review," "privileged account." The underlying operation is identical. The institutional separation is almost total.

ServiceNow's April move made this legible by giving it a name. But the governance gap it exposed didn't start in April. It's been accumulating for years, one workflow at a time, in every enterprise running agents on the Now platform. What matters isn't what ServiceNow added. What matters is that the function was already there, unnamed, and no one was watching it.

The Chain

Start with ServiceNow's structural position, because that's where the logic originates.

ServiceNow's business model is built on being the system of record for process state. Process state: who approved what, in what sequence, under what conditions, with what outcome. The platform's stickiness comes from the fact that once enterprise workflows are modeled inside Now, the institutional knowledge of how work actually moves through an organization lives there. Ripping it out isn't a software migration; it's an organizational archaeology project.

That position was durable when the principals in those workflows were humans. A human approves a change request. A human escalates an incident. A human certifies a vendor. The workflow is a record of human decisions, and the identity of the human doing the deciding is tracked through the HR system, the directory, the access management layer. Those systems talk to each other, imperfectly but recognizably.

AI agents break the model. They're workflow constructs, neither human nor traditional service account. They exist inside the orchestration layer, they're provisioned by workflow logic, and their "identity" is defined by what the workflow assigns them to do. When ServiceNow's orchestrator spins up an agent to handle a procurement approval, that agent needs to read supplier records, query the contract database, potentially write to the ERP. Those are access decisions. They happen at the moment of task assignment, inside workflow logic, without touching the access review cycle that a human employee's equivalent permissions would require.

This is the structural fact that the April feature makes visible: the orchestrator is the provisioning system. It always was. For human workers, the workflow was downstream of the identity decision — you granted access first, then the person did the work. For agents, the workflow is the identity decision. The task assignment and the credential assignment are the same event.

ServiceNow didn't design this to be subversive. The logic of orchestration forced it there. If you're going to orchestrate agents, you need to tell them what they can touch. If you're telling them what they can touch, you're making access decisions. There's no version of agent orchestration that avoids this; the only question is whether the decisions are visible and auditable or invisible and assumed.

Now consider the incentive structure. ServiceNow's platform revenue — which grew to roughly $12.4 billion in fiscal 2025, according to the company's most recent annual filing, with workflow automation and AI capabilities driving the fastest-growing segment — depends on being embedded in more operational decisions, not fewer. Every governance function the platform absorbs increases switching costs. Every audit trail it generates increases the argument for keeping it. The scoped credential feature doesn't just solve a customer problem; it deepens ServiceNow's position as the authoritative record of what agents were allowed to do and when. The natural logic of a platform that profits from being indispensable runs exactly this way.

The governance gap, meanwhile, persists because it falls between two institutional functions that don't share a vocabulary. Workflow governance teams — the people who own ServiceNow deployments, manage process models, and run change advisory boards — think about efficiency, SLA compliance, and approval chains. They are not, by training or mandate, thinking about access entitlements. Identity governance teams — the people who run access certifications, manage privileged accounts, and respond to audit findings — think about human principals, role assignments, and access review cycles. AI agents don't fit their mental model of a "principal." They're not in the directory. They don't have a manager to certify their access. They're workflow constructs, and workflow constructs belong to the workflow team.

The result is a class of access decisions that is being made continuously, at scale, by a system that neither team fully owns. The April feature doesn't close that gap. It illuminates it. Whether anyone acts on that illumination is a different question.

The Load-Bearing Digression

I want to spend a moment on a parallel that clarifies what's actually happening here, because the ServiceNow situation isn't unprecedented. The mechanism has run before, in a different layer of the stack.

When Amazon Web Services introduced IAM — Identity and Access Management — in 2011, the framing was operational: you needed a way to control which EC2 instances could call which S3 buckets. It was a plumbing feature. The people who cared about it were infrastructure engineers, not identity architects. The security teams at most enterprises were still thinking about identity in terms of Active Directory, LDAP, and on-premises privileged access management. Cloud compute was a separate domain, governed separately, if it was governed at all.

By 2016 or so, something had shifted. AWS IAM had become, for many enterprises, the most consequential identity system they operated — not because Amazon had announced an identity strategy, but because every cloud workload provisioning decision was an access decision, and those decisions lived in IAM. The access control layer grew out of operational necessity. Enterprises that had mature on-premises identity programs discovered they had a parallel identity estate in the cloud that had been accumulating for years, largely outside the access review cycle, because no one had classified IAM policies as "identity" in the institutional sense.

The reckoning, when it came, was expensive. IAM is actually quite good as a system; the problem was that governance processes hadn't kept pace with the operational reality. Access certifications didn't cover IAM roles. Privileged access reviews didn't include Lambda execution roles. The audit findings that started appearing in federal cloud environments around 2018 and 2019 were about enterprises failing to recognize that their operational platform had become their identity platform, and treating the two as separate things.

ServiceNow is in the same position AWS was in 2013. The platform has been making access decisions for years. The decisions are embedded in workflow logic rather than explicit policy files, but the structural function is identical: the system decides what a principal can do, and those decisions accumulate faster than governance processes can review them. The April feature is the moment when ServiceNow, like AWS before it, starts building the audit infrastructure for a governance function it already owns. Probably because customers started asking questions that revealed they'd noticed the gap.

The ERP parallel is worth a brief mention too. When SAP and Oracle became the systems of record for HR processes in the 1990s, they absorbed a set of governance decisions that organizations hadn't fully recognized as governance decisions. What counts as a promotion? What triggers a compensation review? What approval chain governs a role change? These were policy questions, but they got encoded as workflow configurations. The ERP became the de facto policy engine, and the HR policy team often didn't know it. Auditors started finding this in the mid-2000s, when Sarbanes-Oxley compliance forced a reckoning with who actually controlled the rules that governed financial processes. The answer, frequently, was: the ERP configuration, maintained by IT, reviewed by no one with policy authority.

The pattern is consistent enough to name. Operational platforms absorb governance functions when the operational decision and the governance decision are structurally identical, when the platform has better state than the governance system, and when the institutional vocabulary of the two functions is different enough that no one notices the overlap. That's the mechanism. ServiceNow's agent orchestration is running it right now.

The Framework

The value of a framework is its portability, so I want to name this carefully. The specific ServiceNow feature will evolve; the underlying dynamic will recur.

Call it the invisible grant problem. An operational platform makes access decisions as a byproduct of its core function. Those decisions are not classified as access decisions by the teams that make them, because the vocabulary is operational rather than governance-oriented. The decisions accumulate outside the access review cycle. The platform develops better state about what access exists than the identity governance system does. At some point — usually triggered by an audit finding, a breach, or a regulatory requirement — the gap becomes visible. The platform then either builds governance tooling to address it (as ServiceNow is doing now) or the enterprise discovers it has two identity systems, one of which it has been ignoring.

Three markers tell you when an operational platform has crossed into invisible grant territory:

First: The platform decides who can do what, at the moment of operational assignment, without a separate access request or approval workflow. The decision is implicit in the task, not explicit in a grant.

Second: Those decisions are not reviewed by the team responsible for access governance. The workflow team owns the platform; the identity team owns the review cycle; neither team has mapped the overlap.

Third: The platform has more current and accurate state about what access exists than the identity governance system does. The identity system thinks it knows who has access to what. The operational platform has been granting and revoking access with every workflow execution, and none of that is reflected in the identity system's records.

When all three are true, you have an invisible grant problem. The governance gap isn't a failure of either team; it's a structural consequence of the platform absorbing a function that neither team claimed.

This lens applies well beyond ServiceNow. Any workflow automation platform that provisions agents, bots, or automated processes is making access decisions. Any RPA platform that runs attended or unattended bots is making access decisions. Any low-code platform that lets business users build integrations is making access decisions. When one of these platforms announces a "governance feature," the more useful question is whether the feature is surfacing a function the platform already had, and if so, how long the function was running before anyone looked at it.

The answer, in my experience, is almost always: longer than anyone is comfortable admitting.

The Prediction

Here's where I'll put something on the record, because a framework without a prediction is just a description.

My bet: within 18 months — by the end of calendar year 2027 — at least one federal civilian agency will receive an OIG finding or a GAO observation that specifically cites workflow-orchestrated agent credentials as an unreviewed access pathway. The finding will be about the agency's access certification process failing to cover a class of access decisions that were being made by the workflow orchestrator, outside the standard review cycle, because no one had classified them as access decisions.

I might be wrong about the timeline. Federal audit cycles are slow, and the AI agent deployments that would generate this kind of finding are still relatively new. It's possible the reckoning comes in 2028 rather than 2027. But I'm fairly confident about the structure of the finding, because the pattern is well-established. The AWS IAM findings I mentioned earlier followed a predictable arc: deployment outpaced governance, audit caught the gap, remediation required retroactive review of access that had been accumulating for years. The ServiceNow situation has the same shape.

What I'm less certain about is how ServiceNow will respond to that reckoning when it arrives. The scoped credential feature suggests the company is already positioning for it — building audit logging and access visibility into the orchestrator before the audit findings force the issue. That's smart. It's also the kind of move you make when your enterprise customers, particularly in regulated industries, start asking questions that reveal they've noticed the gap.

The deeper question is definitional, and this is where I think the real stakes are. If a workflow orchestrator that provisions agent credentials is functionally an identity system, is it subject to the same governance requirements as an identity system? In the federal context, that means FICAM compliance, access certification requirements under OMB Memorandum M-22-09, and the zero-trust architecture mandates that agencies have been working toward since 2022. Those requirements were written with human principals and traditional service accounts in mind. They don't have a clean answer for workflow-provisioned agent credentials.

ServiceNow knows this. The April feature, read carefully, is not just a product capability. It's a positioning move for the compliance conversation that's coming. The company is building the audit trail that will let it say, when the question arrives: we have records of every credential assignment, every scope, every agent action. We are the system of record for agent access. That's a governance claim, not just an operational one.

Whether the identity governance community accepts that claim — whether workflow orchestrators get folded into the access certification perimeter, or whether a new governance category gets created for agent credentials, or whether the gap persists and gets papered over with compensating controls — remains genuinely open. My read is that the pressure will come from audit findings before it comes from policy, which means the enterprises that figure out how to bridge the workflow-identity gap proactively will have a meaningful head start on the ones that wait for the OIG letter.

The invisible grant problem doesn't go away because you name it. But naming it is where the work starts.

Adrian Vos covers technology business strategy and platform economics for On Signal. The Outer Ring focuses on moves at the edge of established markets — the adjacent decisions that reveal where leverage is actually shifting.