Identity After Dark Mailbag: The Questions We Didn't Reach

On June 17, about 30 senior identity practitioners joined us to record a live episode of the Identity at the Center podcast. Jim McDonald and Jeff Steadman hosted. No slides, no pitch, no script.

The room submitted more questions than one live recording could hold. We talked through five on the night. The rest were too good to leave unanswered. This page is the result: twenty questions, answered the way we would have answered them in the room. Here we have more room to share the detail the format did not allow.

The answers sit in four groups. Read them in order, or jump straight to the one most relevant to your program.

• The identity stack is consolidating, and AI changes the calculation
• Non-human identities and the 50 to 1 problem
• Audit reality: the conversation that actually happens
• The questions that stood alone

Where a question came from a named submitter, we credit their initials, role, and industry. Cameras faced the panel that night, not the room, so full names stay out unless their owners ask for them. Where a question invites a product answer, we give the practitioner answer first. Where we have a specific point of view, we say so plainly.

Terms used on this page. Identity and access management (IAM). Privileged access management (PAM). Identity governance and administration (IGA). Non-human identity (NHI). Just-in-time (JIT) access. Multi-factor authentication (MFA). Shared Signals Framework (SSF). OpenID Connect (OIDC). One-time passcode (OTP).

Key takeaway

The hardest questions in identity right now share one root cause. Machine-speed access has outgrown human-paced governance. Inventory, named ownership, and short-lived credentials close more of that gap than any AI feature on a vendor roadmap.

The short version

• Consolidation reduces sprawl risk, but it concentrates dependency. Standards-based portability is the safeguard.
• Every non-human identity needs a human owner of record before an incident, not after.
• AI agent credentials should be just in time, scoped to the task, and revoked when the task ends.
• Auditors now ask for non-human identity inventories and decision evidence, not just completed access reviews.
• A termination-to-deprovisioning timeline you cannot produce on demand turns a routine audit into a finding.
• Decentralized identity is progressing, but it is not ready to carry enterprise federation yet.

What the episode already covers

These are the five main questions we answered during the episode.

• Why identity and access management teams feel stretched thin securing AI identities, and why a healthy amount of concern is reasonable.
• Whether identity is a business asset or a cost center.
• How AI can ease the load of identity governance and administration and large-scale access reviews.
• Whether agentic AI needs a new standard, and it does not. Extending the Shared Signals Framework, OAuth, and OpenID Connect correctly gets you there.
• How agentic authentication should work: delegation, not impersonation.

You can hear those answers in full on the Identity After Dark event page, or read our field notes from the room. The audio and video sit together on the event page. What follows is everything we did not reach.

The identity stack is consolidating, and AI changes the calculation

Is consolidation reducing risk, or concentrating it in fewer places?

Our view is that it does both, and pretending otherwise helps no one. Consolidation closes the gaps between disconnected tools and reduces sprawl. That is real risk reduction. It also concentrates dependency. One misconfiguration, one vendor vulnerability, or one failed upgrade now touches everything.

The useful question is why you are consolidating. Clean consolidation gives you one authoritative source of truth for identity data, consistent policy enforcement, and better visibility. Risky consolidation collapses privileged access management, identity governance, and authentication into one product before the organization has the process maturity to govern it. A commercial discount is not an architecture.

Our take: consolidation is the right direction, but the risk profile changes. You trade breadth of exposure for depth of dependency. The answer is not to avoid consolidation. It is to choose a platform with standards-based portability, so you keep the option to move. Practically, ask whether your consolidated platform participates in the Shared Signals Framework and AuthZEN. If it does not, you are building a new silo.

When an AI agent needs access across IAM, PAM, and governance at once, which system owns that decision?

None of the three should own that decision alone, and it should not default to the system that spawned the agent. The room touched this question on the night but did not resolve it, so we will take a position.

A policy decision point that can weigh context makes a better call than one identity, privilege, or governance tool alone. Context here means who issued the agent, what its declared intent is, and what its peers are entitled to do. The broker model follows from that. An intermediary queries the identity layer for who issued the agent, and the privileged access layer for which privileged resources are in scope. It asks the governance layer whether the pattern sits within policy. Then it makes the call, and enforcement stays with the resource the agent is touching.

We will be honest about the state of the art: this does not exist cleanly yet. Organizations are stitching it together from existing tools. The near-term answer is to put the governance control on the issuing identity. Govern the delegator, not just the delegate. Longer term, access decision governance will mature as a category. The tools demoed at Identiverse this year are early versions of it.

What breaks first when you bolt AI onto a stack built for human-paced access requests?

Provisioning breaks first. Logging breaks next, and most visibly. Here is the failure order we would expect.

• Provisioning pipelines were built for human-speed joiner, mover, and leaver events, not machine-speed agent instantiation.
• Logging and audit infrastructure expects human-readable transactions. Agent activity arrives in a different shape, at a different volume.
• Access reviews that work for humans reviewing humans cannot absorb the volume or velocity of agent credentials.
• Role models built for job functions do not translate to task-scoped agent permissions. You either over-provision or build a parallel model.

The one that surprises people most is the help desk. Break-glass processes assume a human who can explain why they need access. An agent cannot do that. Modernize logging and provisioning orchestration first. Those bottlenecks show up immediately.

For teams mid-consolidation right now, does AI change the buying criteria?

It changes the criteria, but not in the way most vendors will tell you. Most platforms have AI features now, so asking about AI features filters out little.

The better question: does the platform expose its decision logic in a way an AI agent can query and act on? That means standards-based APIs, documented policy models, and consistent event streams. A platform that cannot participate in the Shared Signals Framework or expose decisions through AuthZEN will not age well in an agentic world.

Do not restart a consolidation because of AI. Do ask your vendor how the roadmap handles agentic access and which standards it supports. One red flag: a vendor who answers the AI question by describing their own AI features instead of their interoperability posture.

Back to top ↑

Non-human identities and the 50 to 1 problem

A quick definition, since the term carries weight in everything that follows. A non-human identity, or NHI, is any account or credential that acts without a person directly behind it. Think service accounts, API tokens, workload identities, bots, and now AI agents. The ratios floated in the room that week ran from 50 non-human identities for every human identity to well past 100. As we said on the night, whatever number you pick is already out of date.

Who actually owns a non-human identity when no single human is accountable for it?

Every non-human identity needs a human owner of record, even when that human did not create it. That is the principle we argue for, and the room seemed to want someone to say it.

Assign ownership to whoever benefits from the service the account supports, not to whoever provisioned it. When that is unclear, escalate: application owner, then system owner, then business unit head, until someone takes it. This matters because accountability has to land somewhere fast when a machine identity is compromised. “We do not know who owns it” is how incidents grow into larger ones. Resilience is built before the incident, not during it.

Practical step: add a mandatory owner field to your NHI inventory. Validate it quarterly. Treat unowned identities as your first priority. Zero standing privilege helps here too. When identities are ephemeral and task-scoped, the ownership window is short and the blast radius stays small.

What is the right credential lifecycle for an AI agent that can spin up new tasks?

Just in time, ephemeral, and scoped to the task. That was the consensus in the room, and we agree with it. The workload identity model is the right comparison: issue at task start, scope to the task, revoke at task end.

Avoid long-lived service accounts for agents, static API tokens, and credentials shared across agent instances. The hard part is velocity. Most privileged access and secrets tooling assumes credentials that live for days or months, not seconds. Look for tooling that issues and revokes dynamic credentials at machine speed.

When a task spawns subtasks, each subtask should receive its own scoped credential drawn from the parent’s permission set. Do not hand down a copy of the parent’s full access. That is the delegation model applied recursively: delegation, not impersonation. And log every issuance and revocation. That trail is your evidence when something goes wrong.

When a machine identity is the root cause of a breach, where does accountability land?

In practice it lands everywhere at once, and few organizations are ready for that conversation. The workable framework: accountability follows ownership, and ownership should exist before the breach.

The developer answers for how the credential was created and stored. A hard-coded secret is a development process failure. The platform owner answers for least privilege, rotation, and expiry. Security answers for whether the identity was inventoried, owned, and monitored for anomalies. A mature program documents all three accountabilities before anything goes wrong, not in the post-mortem.

This is a governance question, not a technology question, and governance is operational discipline. One move we would make this quarter: write machine identities into your incident response playbooks explicitly. Most playbooks still assume a human actor holding the credential.

After a basic NHI inventory, what are the first practical steps toward controlling service accounts?

Submitted by R.C., credit union sector.

Do not try to do everything at once. The order that works: classify it, own it, rotate the high-risk credentials, then decommission the unused. Six moves, in sequence.

Work the table top to bottom. The sequence matters more than the speed.

How are you solving for just-in-time access for non-human identities?

Submitted by K.R., IAM engineer, retail.

Just-in-time access for non-human identities is the right direction, and the gap is execution, not intent. The model: the agent or service account requests a credential at task start, and the credential lives for the task duration. Revocation is automatic at task end. Seconds to minutes, not days.

What makes it real: a secrets management layer that issues dynamic credentials, paired with a policy engine that evaluates request context. What makes it hard: most existing governance and privileged access tools carry human-paced workflows baked in. So start with the highest-privilege accounts and implement just-in-time access there, using the privileged access management tooling you already run. Accept longer-lived credentials at the low end for now.

The encouraging part: DevOps largely solved this for pipeline credentials with ephemeral tokens, workload identity, and certificate-based authentication. Apply those patterns to the wider non-human identity population. And watch the OAuth and agent protocol work now under way, because that is where the standards for AI-specific access are converging.

How do we manage risk at a 50 to 1 ratio of agents to humans in a transaction?

Submitted by R.D., banking.

The human-centric risk model breaks at that ratio. You cannot put a person in the loop for every agent transaction, so stop designing as if you can.

The shift is from human-supervised access to policy-supervised access, with anomaly detection as the mechanism that brings a human in. In practice: clear policies for what agents can and cannot do, automated enforcement at the policy decision point, and detection that surfaces deviations for review. The human does not leave the loop. They move up a level, governing the policy and reviewing exceptions instead of approving individual transactions.

At a high agent-to-human ratio, a compromised agent credential has a larger blast radius. That argues for tighter scoping and shorter-lived credentials, not for more human reviews. Have this conversation with your risk and audit teams now. Waiting for the audit community to catch up is not a strategy.

Back to top ↑

Audit reality: the conversation that actually happens

We never reached the audit topic on the night. These questions deserved better, so here is the full set.

What is getting flagged in 2026 audits that was not flagged two years ago?

Non-human identity scope tops the list. Auditors now ask for an NHI inventory as a line item. Two years ago they rarely did. They also ask how AI tools and agents are provisioned and deprovisioned, and most organizations do not yet have a good answer.

Four more items are drawing new scrutiny.

• Access decision evidence. Certifications with zero revocations read as rubber stamps, and auditors have started saying so.
• Cloud shared responsibility, especially privileged access to cloud control planes.
• Third-party and vendor access to production, especially vendors holding standing access rather than just-in-time access.
• Dormant privileged accounts. The bar for “recently used” keeps tightening.

Where is the widest gap between what your tools report and what auditors want to see?

Tools report access. Auditors want governance of access decisions. That is the gap.

A certification report shows a manager clicked approve. It does not show whether the manager had enough context to decide well. The evidence they saw, the business justification, the reason nothing was revoked: none of it appears. Most governance platforms produce a completion log, not a decision-quality log.

Two more gaps are worth closing. First, non-human identity coverage. Tools report on human identities by default, so machine identities land in a different system or nowhere. A unified view of privileged access becomes hard to produce. Coverage is the real benchmark here, not report count. Second, time to deprovision. Tools report state at a point in time. Auditors want the elapsed time between the trigger event and the removal.

The practical fix: augment access review exports with context fields, meaning reviewer role, basis for decision, and date of prior review. Then build a dedicated NHI report until your platform gives you one view of both populations.

How are auditors treating non-human and AI agent access? Are the frameworks even ready?

Mostly, no. Most auditors work from adapted human-identity frameworks, and most frameworks have not caught up. That is not a reason to wait.

SOC 2, ISO/IEC 27001:2022, and the NIST catalogs already contain privileged access and account lifecycle controls that apply to non-human identities. NIST SP 800-53 Revision 5 (updated August 2025) and NIST SP 800-190 both carry applicable controls, even though neither names AI agents. Organizations that apply them proactively sit in a stronger position than those waiting for NHI-specific guidance.

Document your NHI governance framework explicitly, even if it is imperfect. An auditor who sees defined owners, lifecycle stages, and review cadences treats you differently than one who sees no policy at all. Our expectation: within 12 to 18 months, the major frameworks will include explicit non-human and agentic access sections. Get ahead of it now.

What is the one piece of evidence that turns a routine audit into a problem if you cannot produce it?

A termination-to-deprovisioning timeline for a specific former employee, especially one who held privilege.

Auditors pull a random sample of recent terminations and ask three things. When did this person leave? When was their access removed? Show me the log. Auditors expect a timestamped trail from the HR termination event to the access removal in each system. That covers Active Directory, email, VPN, and privileged tools. Fall short, and expect an immediate escalation.

The second most dangerous gap: an admin-level service account with no documented owner and no review in over a year. If you cannot name the owner or the business justification, expect a finding.

The fix for the first is automated offboarding that logs each step with timestamps. Your identity governance and administration platform should generate that evidence on its own, with no one assembling it by hand. The fix for the second is the owned NHI inventory from the previous section. Run that cleanup before the next audit cycle, not after.

Where does compliance fit for non-technical, front-line employees?

Submitted by T.F., principal, consulting.

Front-line associates need security to be invisible. If they notice it, it is probably friction, and friction breeds workarounds.

The compliance burden belongs to the organization, not the associate. Design the program so compliance is the path of least resistance. Day-one provisioning that arrives correct removes the temptation to share credentials or work around missing access. Self-service password reset shrinks the “give me your password” social engineering vector that front-line environments attract. For multi-factor authentication, respect the actual environment. A warehouse associate on a shared device has different constraints than an office worker on a laptop.

For evidence, role-based provisioning is your friend. An audit trail showing that access flowed from role, not from one-off requests, simplifies both the governance and the audit story.

How do you bring your team along when modernizing an identity program?

Submitted by T.F., principal, consulting.

Start with why the change is happening, not what the change is. Teams that understand the risk context make better judgment calls during implementation.

Then, in rough order: give the team a safe place to experiment and break things without a mistake becoming a production incident. Budget for training. The team hired for the old world will have gaps in the new one, and that cost is part of modernization, not an extra. Involve them in vendor selection, since people support what they help build. And acknowledge what the change takes away, not just what it adds. Automating a process someone ran manually for years is a real loss, and it deserves an honest conversation.

Where training cannot close a gap, hire for aptitude. The community is a good sourcing channel: IDPro, Identibeers, and the Identity at the Center listenership itself.

Back to top ↑

The questions that stood alone

At what point does digital identity become critical public infrastructure?

Submitted by S.M., chief technology officer, county government.

There is a strong case that it already has. Healthcare, utilities, financial transactions, and government benefits all sit behind identity systems. When those systems fail, the failure is functionally a public infrastructure failure.

What has not happened is regulatory designation. Most jurisdictions do not classify identity infrastructure the way they classify power grids or financial systems. Designation would bring resilience requirements, auditability requirements, interoperability mandates, and likely public-sector oversight. Critical infrastructure should not depend on a single vendor to operate it.

Our view: formal designation is five to ten years out, and organizations building identity infrastructure at scale should design for that level of resilience now. The identity community should also be in that policy conversation early. IDPro and the standards bodies will influence it more than one vendor can.

If identity systems were designed around human trust instead of organizational risk, what would look different?

Submitted by S.M., chief technology officer, county government.

Friction would be engineered out rather than accepted as the price of security. The system would start from “make this trustworthy and effortless,” not from “prevent abuse.”

Access would follow demonstrated need and context rather than request-and-approval chains. The audit layer would be built for the person to understand. You could see and explain your own access history, not just produce it on request. Identity proofing would be stronger at the front door and less restrictive inside. And the password would probably be gone by now.

One engineering team in the room described this working at scale. Their program proposes revoking any access unused for 90 days, and people let it go willingly. The reason is trust: anyone can reclaim access the moment they need it, with no approval chain. Build the effortless path back first, and revocation stops feeling like a loss.

The encouraging part: passkeys, continuous access evaluation, and behavioral analytics all move in this direction. The trust model is slowly gaining ground on the gate model.

What happened to decentralized identity?

Submitted by D.S., vice president of identity governance, insurance.

It is not dead. It is in the gap between proof of concept and production.

The standards are mature. Decentralized identifiers, verifiable credentials, and the W3C frameworks are solid. What has not arrived is the ecosystem. Decentralized identity works when enough issuers, verifiers, and wallets exist to make credentials useful, and that scale is still forming. Government and regulated industries will move first: digital driver’s licenses, government ID credentials, and regulated financial verification. The EU Digital Identity Wallet is among the most visible live deployments. North America lags.

For enterprise identity programs, the honest answer is to watch it without building a program dependency on it yet. It cannot replace federated infrastructure at enterprise scale today. The most promising near-term application may actually be agentic. Picture a decentralized identifier as the root of an agent’s identity, owned by the human who instantiated it. The room raised that idea on the night, and it has stayed with us.

Why are banks still using SMS for one-time passcodes?

Submitted by an audience member on the night.

Legacy infrastructure, regulation written when SMS was the strongest available option, and customers who cannot uniformly run authenticator apps. That is the honest answer.

The technical case against SMS one-time passcodes is well established: SIM swapping, SS7 signaling weaknesses, and real-time phishing that captures and replays codes. NIST classified SMS as a restricted authenticator in the 2017 edition of Special Publication 800-63B. The current edition is NIST SP 800-63B-4, published July 31, 2025, and regulators increasingly expect stronger alternatives for banking.

Change is slow because forced migration is expensive. Banks that pushed mandatory authenticator adoption absorbed real customer friction and support cost. The direction is set, though. Passkeys and FIDO2 authentication are the path forward, and consumer banking adoption is under way. What a bank can do now: offer passkeys alongside SMS and reward adoption with fewer step-up challenges. Plan the SMS phase-out over 18 to 36 months rather than overnight.

Back to top ↑

Where Bravura Security fits in this conversation

We hosted this conversation, and we want to keep it a conversation rather than a pitch. So here is the short version of where we sit. Bravura Identity and Bravura Privilege are both part of the Bravura Security Fabric.

Most of the answers above come down to three disciplines.

Coverage: governance has to reach each identity, human and machine, across hybrid environments, because coverage is the real benchmark. Bravura Identity manages the lifecycles of identities, accounts, groups, and entitlements across on-premises and cloud systems, so reviews rest on current, complete data.

Governance enforcement: policy has to act, not aspire. Bravura Identity enforces policy on separation of duties, role-based access control, and risk scores. Its prebuilt reports and dashboards give auditors direct visibility into your compliance posture.

Operational resilience: Bravura Privilege enforces pre-authorized and one-time access policy to grant temporary access to privileged accounts. That shortens the life of exactly the credentials this mailbag keeps worrying about.

One objection worth naming before you go. “Our identity platform already runs access reviews, so machine identities are covered.” In our experience, that assumption fails the first time an auditor asks for the NHI inventory. Most review processes were scoped to human identities, and the gap only becomes visible when someone asks for the unified view. Check before the auditor does. No platform, ours included, closes that gap without the ownership and process discipline this mailbag describes.

When this does not apply

Not every answer here fits every organization.

If you run a small environment with a handful of service accounts, a spreadsheet inventory with named owners may serve you better than new tooling. Start there. If you operate under prescriptive regulatory frameworks, your regulator’s specific guidance overrides the general sequencing offered here. If AI agents are nowhere near your production environment, set the agent lifecycle sections aside for now. The inventory, ownership, and rotation work still applies, and it is the prerequisite for everything else. And if you already run mature just-in-time credentialing for machine identities, the marginal advice here is small. Your next frontier is decision evidence for auditors.

Back to top ↑

Frequently asked questions

What is a non-human identity?

A non-human identity is any account or credential that acts without a person directly behind it. Service accounts, API tokens, workload identities, bots, and AI agents all qualify. In most enterprises, they already far outnumber human identities. They need owners, lifecycles, and reviews just as human accounts do.

Where can I listen to the full Identity After Dark episode?

The episode published on August 19, 2026 on the Identity at the Center podcast. You can stream it there or on any major podcast platform. The audio, the video, and the recap are also collected on the Identity After Dark event page.

Why should service accounts be reviewed differently than human accounts?

Annual certifications suit human access because roles change slowly. Machine identities change at deployment speed, so usage-based triggers work better. A 90-day inactivity flag catches abandoned accounts faster than a yearly review, and it focuses reviewer attention on the accounts whose behavior actually changed.

Will there be another Identity After Dark?

The format earned more candor in ninety minutes than most conference stages produce in a week, and the room asked for a sequel. We are already working on the next edition. Follow us on LinkedIn, or subscribe to the Identity at the Center feed, and you will hear about the next one first.

Back to top ↑

A closing note

The questions this room asked deserved more time than one evening gave them. This page is our attempt to close that gap.

If any of these topics are live for you right now, we are glad to continue the conversation. That includes non-human identity governance, audit readiness, and what agentic identity means for your program. A conversation between people who work on the same problems.

The episode, the recap, and the contact details are all linked from the Identity After Dark event page.

The Bravura Security team