Authorization Provenance Across Service Accounts, Bots, and AI Agents

Three kinds of non-human identity will come up in your buyer's NHI conversation: traditional service accounts, automation bots, and AI agents. The question that earns you credibility is specific: "who authorized that action?"Service accounts give you a clean answer. Bots give you a mostly-clean answer. AI agents give you an answer that was accurate at the moment of consent and gets progressively less precise from there. Name that distinction out loud, with the right specificity, and you own the room. Collapse all three into "NHIs" and you sound like the slide deck the buyer already recycled.

Service Accounts

What it is: A persistent identity object representing an application or workload, registered in a directory or cloud IAM system.

What it does: Authenticates to APIs, databases, and cloud services to execute predefined operations. Runs pipelines, queries data stores, manages infrastructure. It does what its code tells it to do. Every time. Without variation.

Who's behind it: A developer or infrastructure team created it. In Azure Entra ID, the audit log captures who provisioned the service principal, what scopes were granted, and whether it was created by a user or an external application. In AWS, role trust policies and CloudTrail log who assumed which role and when.

What makes it distinct: The authorization chain is captured once, at creation, and then the account runs on its own identity indefinitely. You can always answer "who set this up." You often cannot answer "is the person who set this up still at the company." OWASP's NHI Top 10 for 2025 flags improper offboarding as a leading risk for exactly this reason: when a human employee leaves, their corporate account gets deactivated, but the service accounts, API keys, and automation scripts they created persist. The provenance is strong. The lifecycle governance around it is where things rot.

Automation Bots

What it is: A software robot executing scripted, rule-based workflows across applications, typically built on an RPA platform like UiPath, Power Automate, or Automation Anywhere.

What it does: Replicates human interactions at the UI layer. Copies data between systems, processes invoices, fills forms, clicks buttons in a predetermined sequence. The bot follows a script designed by a human process owner. It does not improvise.

Who's behind it: A process developer built the workflow. A process owner approved it. The bot's identity and the process it executes are registered in a governance platform (UiPath Orchestrator, Power Platform Admin Center). In a well-configured deployment, every action is logged, creating audit trails that trace bot identity to registered process to human process owner. The quality of that trail varies by platform and configuration, but the mechanism exists.

What makes it distinct: The authorization chain holds at the workflow level, not the individual-action level. You can answer "who authorized this process" cleanly. You cannot always answer "who authorized this specific action" because the bot's actions are scripted decisions, not individual human approvals. In practice, the provenance gap is more mundane: bots frequently run under shared service accounts with overly broad privileges rather than per-bot, least-privilege credentials. The chain is intact in theory. Shared credentials blur it in practice.

AI Agents

What it is: An autonomous software entity that uses a large language model to interpret goals, select tools, and execute multi-step tasks with non-deterministic behavior.

What it does: Receives a goal from a human or another agent, reasons about how to accomplish it, selects tools dynamically, calls APIs, retrieves data, and chains actions across systems. Unlike a bot, the agent chooses its own path. Unlike a service account, its behavior varies between runs even with identical inputs.

Who's behind it: A user or system grants the agent permission to act. That initial authorization event is captured. After that, the agent makes decisions that no human explicitly approved for that specific action at that specific moment. If Agent A spawns Agent B which calls Agent C, the original human authorizer is several hops removed from the action taken. NIST's SP 800-53 control catalog assumes you can attribute actions to specific actors. In a multi-agent ecosystem where agents replicate and spawn new agents, that assumption stops holding.

What makes it distinct: The authorization chain degrades during execution. A user says "process this refund." The agent reads a document, interprets a policy, calls an API, and transfers funds. Each step was reasonable. No human authorized that specific API call at that specific moment. The agent decided. You can't close that gap with better tooling. The system was designed to make its own choices.

How Authorization Provenance Actually Differs

I'm using trait-led analysis here. These identity types differ by kind, and a flat three-column table would flatten that into a difference of degree. You can only see the real separation when you examine each dimension of the provenance question on its own.

The buyer's real question, "who authorized that action?", decomposes into four sub-questions. The three identity types give you different answers to each one.

Who set this up?

All three types have strong provenance at creation, in theory. Service accounts are registered in directories with full audit trails. Bots are registered in orchestration platforms with process owner attribution. Agents, when properly registered, record the human or system that instantiated them.

If your buyer's concern stops at "can we trace who created this identity," the answer is yes across the board, assuming the organization actually governs creation. That assumption is doing real work, though. Dynamically spawned agents created for a specific task run may not have a pre-existing identity record at all. They appear, act, and disappear. If nobody registered them, there is no creation record to trace. Static service accounts sitting in Active Directory since 2017 have well-worn governance playbooks. Short-lived identities that exist for ninety seconds and then vanish have none. That's the genuinely new problem.

Who authorized this specific action?

Your OAuth intuitions about scoping and consent are useful here, up to a point.

For service accounts, the question is almost irrelevant. The account executes code paths. The code was written and deployed by a known team. The action traces to the code, the code traces to the deployment, the deployment traces to a human. The chain is long but unbroken.

For bots, the chain holds at the process level. The bot executed step 14 of a 30-step workflow because the workflow was designed that way. You trace the action to the workflow design, the design to the process owner. Individual actions are deterministic. The bot did not decide to take step 14. It was told to.

For agents, the chain breaks. The agent decided to call a particular tool based on model reasoning, retrieved context, and intermediate results. No human authorized that specific tool invocation at that specific moment. The initial consent covers the goal but says nothing about the path. The NIST NCCoE concept paper explicitly identifies this gap as requiring new controls for authorization, access delegation, and logging.

OAuth scoping still matters. An agent with narrow scopes can do less damage even if its decision chain is opaque. But OAuth scopes assume the client will use them predictably. An agent with read access to a document store and write access to an email API can combine those two scopes in ways no human pre-authorized. The scope grant was fine. The composition of scoped actions is where provenance thins out. Your scoping intuition helps you frame the problem. It stops helping when you assume scoping also resolves it.

How does provenance degrade over time?

Each type decays, but the decay pattern is different enough that it changes what governance actually looks like.

Service accounts decay through lifecycle neglect. The developer who created the account leaves. The application it served gets decommissioned but the account persists. The credentials don't rotate. Provenance was strong at creation and slowly becomes orphaned. Well-understood problem with existing governance solutions. Decay timescale: months to years.

Bots decay through process drift. The workflow was designed for a business process that has since changed. The bot still runs the old version. The process owner has moved to a different team. The shared service account the bot uses has accumulated permissions from three different projects. The provenance chain is intact but points to a human who is no longer accountable for what the bot actually does. Decay timescale: weeks to months.

Agents decay during a single execution. Provenance doesn't need months to degrade. It can degrade in minutes. A multi-step agent run that chains tool calls, retrieves documents, and spawns sub-agents can move far enough from the original human intent that the authorization relationship becomes nominal. The user said "summarize these contracts and flag the ones that need renegotiation." The agent retrieved forty documents, interpreted retention clauses, ranked them by exposure, and sent calendar invites to the legal team. Reasonable at every step. The chain from the original instruction to a specific calendar invite is inferential, not explicit. Decay timescale: seconds to minutes.

What standards and tooling exist to enforce provenance?

Service accounts: Mature. OAuth 2.0, OIDC, SCIM, and platform-native IAM provide well-understood mechanisms. Governance tooling exists from multiple vendors. Your buyer's team has probably been doing this, with varying consistency, for a decade.

Bots: Mature, platform-specific. RPA platforms provide their own governance layers. The underlying authentication typically uses service account mechanisms. No special standards needed because bots are deterministic.

Agents: No adopted standard exists. Multiple IETF Internet-Drafts propose extensions to OAuth 2.0 for agent delegation, but none have been adopted by the OAuth Working Group. The MCP authorization spec standardizes OAuth 2.1 for agent-to-server auth but is intentionally silent on agent-to-agent auth. The OIDF AI community group has published a landscape assessment but no specification. NIST launched its AI Agent Standards Initiative in February 2026 and is actively soliciting input on audit and attribution mechanisms.

If your buyer asks what standard governs agent authorization provenance, the honest answer is: several are being written, none are finished, and enterprises deploying agents today are building without them. Saying so is more credible than pretending otherwise.

How to Say This in the Field

Don't say	Do say	Why it matters
"NHIs are a completely new category"	"Service accounts and bot credentials are NHIs we've managed for years. AI agents are the genuinely new problem because their authorization chain degrades during execution — sometimes within seconds."	Buyers with mature programs know service accounts aren't new.
"You need an NHI solution"	"You probably already govern service accounts. The question is whether your governance model extends to identities that are created dynamically, act autonomously, and disappear after a task run."	Frames the gap precisely instead of implying the buyer has done nothing.
"AI agents are just another type of service account"	"Agents authenticate like service accounts but behave like users. Your service account governance covers the credential. The decision-making sits outside it entirely."	Collapsing the behavioral distinction loses the sale.
"We can solve your NHI problem"	"We can register agent identities, assign human owners, enforce least-privilege, and provide audit trails. The industry is still working on tracing every autonomous decision back to the original authorization."	Honest scoping of what's shipped versus what's unsolved earns trust.
"Bots and agents are basically the same thing"	"Bots follow scripts. Agents choose their own path. That distinction changes what 'authorized' means."	Buyers who run RPA will test this claim immediately.
"There's an industry standard for agent authorization"	"Multiple IETF drafts are in progress and MCP has standardized OAuth 2.1 for agent-to-server auth. Nothing is adopted yet for the full delegation chain."	Overstating standards maturity gets caught by any buyer who has done homework.
"Non-human identities outnumber humans 100 to 1"	"Every vendor cites a different ratio depending on what they count. Whichever number you pick, most of those identities sit outside your current access review cycle."	Competing vendor statistics undermine each other.
"You need to rip and replace your IAM for agents"	"Your existing OAuth and OIDC infrastructure handles the authentication. The gap is in authorization provenance — tracking what the agent decided to do after it authenticated."	Positions the problem as extension, not replacement.
"Service accounts are a solved problem"	"Service account governance is well-understood. Whether your organization actually does it consistently is a different question."	Acknowledges the gap without insulting the buyer's current program.
"The agent just acts on behalf of the user"	"The agent acts on behalf of the user for the first hop. After that, if it spawns sub-agents or chains tool calls, the 'on behalf of' relationship gets thinner with each step."	The multi-hop problem is the sharpest technical distinction. Naming it signals depth.

The provenance question is what connects all three identity types and reveals exactly where they come apart. Service accounts give you a clear answer that slowly goes stale. Bots give you a clear answer that points to a process instead of a person. Agents give you an answer that was accurate at the moment of consent and becomes less precise with every autonomous decision after that.

Your IDAM intuitions about authentication, scoping, and audit trails all apply to agents. Your intuition that authorization is a gate you pass through once at the start of a session is where those instincts stop bearing weight. For agents, authorization is a chain that stretches. How far it can stretch before it stops meaning anything is the buyer's actual concern.

Nobody has a clean answer for that yet. Saying so is the most credible thing you can bring into the room.