Executive summaryThe missing layer
Privileged access management was designed around a human assumption: a person requests access, a person approves it, and a person can be asked later why. That assumption no longer holds. Non-human identities (service accounts, workload tokens, and increasingly autonomous AI agents) now outnumber human identities in large enterprises by roughly ten to one, and they request, hold, and exercise privileged access at a rate no human-centered process can govern.
Enterprises are not short on tools. Identity governance platforms, PAM vaults, and integration connectors are mature, commodity, and widely deployed. What's missing is the reasoning layer between request and execution: something that understands what an access change actually grants, validates it against the live estate before it lands, routes it to scrutiny proportional to its risk, and produces a defensible audit record as a structural byproduct instead of an after-the-fact reconstruction. We call that missing layer the conductor.
The pipes exist; nobody shipped the conductor.
This paper describes what privileged access management has to become when the requesters are machines: five properties any credible solution needs. It reports what we learned building one, a working agentic credential broker whose full adversarial test suite was independently verified across multiple environments, and an access-orchestration engine evaluated blind against a practitioner-authored answer key. It closes with the questions a security leader should be asking any vendor - including us.
Section 01The quiet inversion
For thirty years, access governance scaled with headcount. Provisioning queues, approval chains, recertification campaigns - all sized to the number of people in the building. That era ended without an announcement. The identities that now dominate enterprise estates are not people: service accounts spun up per microservice, tokens minted per pipeline run, machine credentials embedded in schedulers, and the newest and fastest-growing class of all: AI agents that plan and execute multi-step work with real permissions.
Three properties make machine identities categorically harder to govern than human ones:
Volume and churn. A human joins, moves, and leaves over years. A machine identity can be created, exercised, and abandoned in a day, and abandoned is the dangerous state, because an orphaned credential with standing privilege is an attacker's favorite door. At a 10:1 ratio with faster churn, the access-change stream moves from thousands of events a day, where diligent teams almost keep up, to tens of thousands, where no human process survives contact.
Nobody to interview. When an auditor asks why a person holds an entitlement, someone can answer. When they ask why a service account holds RACF SPECIAL-adjacent authority on a production LPAR, the answer is too often archaeology: a ticket from 2019, an owner who left, a renewal rubber-stamped annually because removal might break something nobody fully maps.
Agents compound intent. Classic service accounts do the same thing every day; their risk is staleness. Agentic identities are different in kind: they compose actions toward goals, which means their effective privilege is the closure of everything their entitlements permit in combination. A human with excessive access is a risk. An autonomous system with excessive access is a risk that executes at machine speed and never gets tired, embarrassed, or suspicious of its own instructions.
The inversion is now complete: the majority identity class in the enterprise is the one your access process was never designed to see.
Section 02Why human-built PAM breaks at machine speed
The tooling most enterprises run isn't bad; it's aimed at a different problem. Four specific failure modes appear when a human-era access process meets machine-era volume:
Translation fails first. Entitlements on the platforms that matter most are machine-cryptic. A RACF permit string tells a trained administrator exactly what it grants; it tells the approving manager, the requesting application team, and the reviewing auditor almost nothing. When the approver cannot read the request, approval degrades into throughput management: the queue must move, so the stamp comes down. The organization gets the worst trade available: slow AND low-assurance.
Validation happens too late. Most estates discover a bad access change after it lands: the separation-of-duties collision surfaces in the next recertification, the malformed permit surfaces as a production abend, the toxic combination surfaces in an audit finding. The information needed to catch all three existed before execution, in the security database itself, but nothing was positioned to ask.
Routing is flat. A request to read a test dataset and a request touching payment-adjacent production authority frequently traverse the same approval path with the same single approver. Risk-proportional scrutiny (fast lane for the trivial, dual control for the dangerous) is what human experts do naturally and what ticket queues do not do at all.
Audit is reconstruction. When evidence is assembled after the fact (screenshots, ticket exports, log pulls) every audit is an archaeology project and every gap is a finding. The defensible posture is structural: the record of what was requested, validated, approved, and executed should be produced by the flow itself, sealed against tampering, because that is the only version of events that does not depend on anyone's memory.
Each failure is survivable alone at human volume. At machine volume they compound: unreadable requests, validated by nobody, routed identically, reconstructed annually. That is the estate most large organizations are actually running.
Section 03The mainframe makes it acute
It is fashionable to treat the mainframe as legacy scenery. The regulated economy disagrees: the systems of record for banking, insurance, healthcare payers, logistics, and government still run there, which means the entitlements that matter most, the ones adjacent to money movement, policy records, and regulated data, live in RACF and its siblings. Three facts make the mainframe the sharpest expression of the machine-identity problem:
First, the entitlements are the least legible in the enterprise. Distributed-estate roles are merely confusing; mainframe permits are a specialist dialect. The population fluent in it is small, senior, and retiring, while the modern IAM platforms that surround the mainframe treat it as a connector endpoint, not a domain to reason about.
Second, the blast radius is maximal. An over-permissioned cloud service account is a bad day. An over-permissioned identity on the core banking platform is a regulator conversation.
Third, modernization went around it, not through it. Two decades of IAM investment built governance for the distributed estate and left the mainframe integrated at the pipe level only: requests flow in, changes flow out, and no layer in between understands what the change means. The estate with the highest stakes has the thinnest reasoning.
The problem is the vacant seat beside it.
This isn't an argument for replacing anything. RACF isn't the problem; it's arguably the most battle-proven access control system in existence. The problem is the vacant seat beside it.
Section 04What agentic PAM requires - five properties
"Agentic PAM" means privileged access management built for a world where machines are both the requesters and the holders of privilege. Vendor labels vary; the properties do not. Any credible solution must deliver all five:
Legibility.
Every access change rendered in plain language AND mapped to the control framework at stake, before any human is asked to judge it. If the approver cannot read the request, nothing downstream is real.
Pre-flight validation against the live estate.
The proposed change tested against an offline copy of the actual security database before execution: collisions with existing entitlements, separation-of-duties violations, malformed constructs that would fail or break production. The knowledge to catch these exists in the estate itself; agentic PAM positions something to ask before, not after.
Risk-proportional routing.
Scrutiny scaled to consequence, decided by policy rather than queue topology: trivial changes clear in minutes, privileged-path changes require dual control, and the routing decision itself is recorded and explainable.
Ephemerality as the default.
For machine identities especially, standing privilege is the pathology. Credentials should be issued short-lived, scoped to task, and expired by construction, so that "forgot to remove it" stops being an attack surface. Where standing access is genuinely required, it should be the documented exception with an owner and a clock.
Audit as a byproduct, tamper-evident.
The flow itself emits the record (request, translation shown to the approver, validation result, routing rationale, execution outcome), sealed cryptographically so the sequence cannot be silently rewritten. Not because insiders are presumed malicious, but because a record that CANNOT be quietly edited is the only record a skeptical examiner should accept, and the examiner is right to be skeptical.
A test worth applying to any product claiming this space: P1 through P4 each fail loudly when absent. P5 fails silently. An audit trail looks complete right up until the moment it is challenged. Weight your diligence accordingly.
Section 05We built one: notes from a working agentic credential broker
Positions in this space are cheap; builds are not. In the course of developing our platform we built the machine-identity half end-to-end: a credential vault and an agentic broker that issues scoped, short-lived credentials to autonomous agents, with atomic issuance semantics and a hash-chained, tamper-evident audit log: properties P4 and P5 as running code, not slideware.
What we can report, stated exactly
- The broker's full adversarial test suite (109 checks covering issuance atomicity, lease expiry, revocation, replay resistance, and audit-chain integrity) passes deterministically, and that result was verified independently by reviewers who did not write the code, on multiple runtime environments, per our engineering rule that a builder's green is a claim, not a fact, until a non-builder reproduces it.
- The verification process itself caught things self-testing never would: a timeout defect that only reproduces on network stacks that can stall DNS resolution, invisible on fast-failing networks, plus the discipline finding that an environment which cannot produce a failure mode is structurally blind to that entire defect class. Both are now standing rules in our runbooks.
- The audit chain is hash-linked such that deleting or editing any entry breaks the chain visibly. We treat that not as a feature but as the minimum bar for P5.
Two lessons from the build worth stealing regardless of vendor:
An acknowledgment is not a receipt.
Lesson 1 - An acknowledgment is not a receipt. Across every seam in a machine-speed system (message delivery, credential issuance, approval recording) the pattern that survives failure is identical: confirm only after the work is done, never before, and make completion checkable by a party other than the claimant. Every silent failure we have ever chased violated this rule somewhere.
Lesson 2 - Self-report is never load-bearing. A component asserting its own success is the single most common root cause of governance theater. Our engineering doctrine (the builder never gates their own work; every claim carries an acceptance criterion a non-builder runs) exists because we watched confident green reports dissolve under independent execution. Ask your vendors who verifies their claims. Then ask who verifies the verifier.
We also learned what NOT to build: a standalone credential-broker business. The capability matters; the market told us it belongs inside a broader orchestration platform rather than as a point product. We publish the lessons anyway, because the properties are what matter and the industry converges faster when builds are documented honestly, including the commercial verdicts.
Section 06The enterprise expression: Riveriam
Riveriam is our access-orchestration platform, the conductor seat, with RACF as the anchor platform. It exists to close the loop this paper describes: request -> context assembly -> translation (P1) -> offline validation (P2) -> risk-driven routing (P3) -> execution through established integration patterns -> sealed audit (P5), with machine-identity ephemerality (P4) inherited from the broker work above.
Design posture, because posture is where enterprise trust is won or lost:
Additive, never rip-and-replace. RACF stays. SailPoint or Saviynt stays. Riveriam occupies the vacant reasoning seat between them; it does not compete for theirs.
Never inline on the critical path. Riveriam sits on the access-change path, not the transaction or runtime-authorization path. If Riveriam is down, the institution still runs, a property we consider non-negotiable for anything asking to touch a core estate.
Wedge before platform. The first deliverable is deliberately bounded: an offline-database access validator that runs in-environment, never exfiltrates security data off the LPAR, and delivers standalone value (pre-flight collision and malformation detection) before any broader orchestration conversation.
On evidence, stated with the same discipline as Section 5
- Riveriam's reasoning engine was evaluated blind against a practitioner-authored answer key across a 13-event batch on fully synthetic data. It matched the key on 12 of 13 events, correctly escalated both deliberately unanswerable trap events rather than guessing, invented zero controls, and on one event identified a separation-of-duties violation the human-authored key itself had missed. We report this as what it is: a controlled internal evaluation on synthetic data, encouraging enough to justify the next gate, which is independent validation by an outside RACF subject-matter expert against real-world constructs. That validation, by an expert we do not employ, is scheduled as our next milestone, and its results will be published whether they flatter us or not.
- Everything above was built on synthetic, clean-room data from a fictional institution. No employer work product, no customer data. That firewall has been maintained deliberately from the first line of code.
Section 07Six questions to ask any vendor in this space - including us
- Show me the translation.
Take a real entitlement from my estate and render what it grants in language my approvers and auditors can read. If the demo uses only their sample data, ask why.
- When do you validate - before or after execution?
"We detect violations" usually means after. Pre-flight validation against an offline copy of the live estate is a different capability. Make them say which one they have.
- What happens to my transactions if your product dies at 2 a.m.?
The only acceptable answer is "nothing." Anything inline on the runtime path is asking for trust it has not earned.
- What is the default credential lifetime for a machine identity?
If the answer is "configurable" rather than "short-lived unless excepted," the default will become the estate.
- Can your audit trail be edited without detection?
Ask specifically what breaks, visibly, if an entry is deleted. "Access to the log is restricted" is not an answer; it is the absence of one.
- Who verifies your claims?
Internal test suites are self-report. Ask what has been reproduced by someone who did not build it, on an environment the builder did not control, and what they found that the builder missed.
We hold ourselves to these publicly. Question 6 is why our next milestone is independent expert validation rather than a customer logo.
Section 08Where this goes
Where this goes isn't subtle. Agent workforces are moving from pilot to production across the same enterprises whose systems of record live on the mainframe. Every one of those agents is a privileged identity the moment it touches real work. Regulators have already extended scrutiny from "who has access" to "how do you know, and prove it," and the honest answer at machine volume requires the reasoning layer this paper describes. Institutions will close that gap deliberately, or they will close it in the remediation phase of a finding. The former is cheaper.
The pipes are built. The conductor's seat is open. That is the work.
Start a conversation →