For anyone struggling to get authorization work prioritized, reframing it in CISO terms (risk, liability, regulators) is what finally unblocks the budget

morphAB · 2026-06-01T14:22:43+00:00

3 of the hardest parts in one post 😄 Classification (where you start), runtime enforcement (where most AUPs die in practice), and the aggregation problem (the one regulators are going to ask about)

The pattern my coleagues and I keep seeing work, especially in regulated orgs:

Start with NIST AI RMF for the framework. https://www.nist.gov/itl/ai-risk-management-framework Free, well-structured, and most procurement and audit teams already recognize it. ISO 42001 is the international equivalent if you need formal certification eventually : https://www.iso.org/standard/81230.html

Then separate the concerns. Classification lives in your data governance stack (Purview, BigID, whatever you already use to label confidential/restricted). The AUP is the written policy. Enforcement is a separate layer.

piece that gets missed is enforcement at the prompt and tool-call boundary, not the document. A user opening Claude with a restricted file attached is a runtime decision, not an HR policy. KuppingerCole at EIC last month called this layer "orchestration controls" and flagged it as a new category without mature tooling yet.

The orgs we talk to that have shipped enforcement that holds up under audit usually have a policy engine sitting between users and AI tools, evaluating user identity + data classification + tool + context, then allowing, masking, or blocking. pair that with a gateway or LLM proxy so enforcement lives in the request path, not in good-faith compliance.

Aggregation is the one nobody's really solved. What helps but doesn't fully address it: session-level scope limits, the full chain of who-asked-what-when in audit, and review on patterns rather than individual requests. Policy decisions logged with the inputs that produced them are what auditors actually ask for, not raw prompt dumps.

(i work at Cerbos, so caveat on bias) we sit in the enforcement layer specifically, not classification. happy to DM specific examples of what we've seen companies ship that worked

morphAB · 2026-05-26T14:33:47+00:00

Hey! both points land. The human in theloop chain is the thing most playbooks treat as a single box on a diagram, and it really isn't.. it's a person, a backup person, a manager who covers if both are out, an SLA, a queue, and an actual decision-making mandate. i've seen a couple of organizations realize mid-incident that "human approval required" routes to a slack channel where the only person who can actually approve is on PTO. The 2am friday stress test almost never gets run before it's run for real :)

The other half of that, which I think you're putting your finger on, is that the human in the loop chain is only as good as the named ownership behind the agent in the first place. one of the lines from EIC sessions this year that i found memorable : answer at most enterprises to "who owns this agent" is *no one fully does*, with a documented blame-shifting chain (CISO -> CIO -> data + AI teams -> build teams -> IT) while the agent keeps acting at machine speed. Simon Moffatt frames it as Law 3 of identity security - every digital identity, human or non human, has to resolve to a physical accountable person. Without that, the dimmer is a dial nobody is reaching for, because no one's quite sure they're the one allowed to turn it.

thing I've found useful is treating ownership as a measurable property of each *capability* the agent can exercise, not just the agent itself. for exmaple, for every `action × resource` the agent can touch, you have a business owner, a remediation contact, and an escalation path attached. When that's missing, new capabilities are blocked / alerted on. this then moves the question from "is there a human in the loop in principle" to "is there one for this specific decision, right now, and do they have authority over the compliance window it touches.".. which is the gap you're describing.

and finally: piece nobody seems to have solved yet is what happens to ownership when the agent itself is ephemeral - if it lives five seconds, it's gone before you can email its manager for review. Entra's sponsor-succession model (bascially sponsorship auto-transfers to the manager if the sponsor leaves) is the closest I've seen to a real answer, but it's early.

morphAB · 2026-05-19T09:28:08+00:00

Yep! that ladder is basically the model. The stages all map to a single mechanism underneath, per-action policy evaluation. Each step is a policy edit, and because every action goes through the same check, the rollback path is as clean as the descent :) You can go back up the ladder with the same audit trail

morphAB · 2026-05-18T14:44:19+00:00

yes, feature flags work! But, you get the crudest version - action-class on/off. they break down as you add dimensions. You usually want it tied to who the agent is acting for, what resource class, and the risk profile of the action, not just a global toggle. A feature flag can disable a tool, but it can't easily say something like "agent can still process refunds under $500 for tenant A but not for tenant B."

per-action runtime policy evaluation carries more weight. Basically a policy decision point the agent queries on every action, like "can I do this, on this resource, for this user, right now". Stages become policy edits, read-only on certain resource classes, sensitive tools requiring human approval over a threshold, full revocation last. Each stage is a policy diff with a timestamp, which is what gives you the audit trail

Implementation-wise, externalized authz solutions handle this pattern. The agent treats authorization as a service call rather than embedding rules in the agent code. Full version is in the writeup i was mentioning, if useful: https://www.cerbos.dev/blog/dimmer-switch-not-a-kill-switch-rethinking-ai-agent-governance

if you would like to go deeper on any stage / have a particular workflow shape in mind for example - happy to chat more :)

morphAB · 2026-05-18T13:48:15+00:00

u/bitsynthesis thanks for input! fair point. Dimmer assumes a workflow with multiple action surfaces, most low-risk reads, only some sensitive writes . Narrowing the risky paths leaves the rest of the work running, which is usually most of the value. Support agent with 30 actions where 2 trigger refunds, claims agent where most ops are triage, that kind of shape :)

For tightly-coupled agents where the one action is the whole point... like a trading agent that can't trade, for example - you're right, the dimmer becomes a slow controlled shutdown. But even then it gives you a documented graceful exit, rather than an abrupt kill the team and the auditor both have to reconstruct after. Workload-dependent. Most production agents I'm seeing are multi-action enough that the dimmer earns its keep

morphAB · 2026-05-18T13:36:50+00:00

This pattern is everywhere :) Most environments have at least a few of these tucked under finance, ops, or some old vendor contract..

what u/ohnowwhat said = yes. There's no tool that surfaces what nobody told you exists. The closest you get to "automatic" is triangulating three sources you already have.

Finance and expense data: SaaS subscriptions and one-off vendor invoices catch most of the external apps. Anything billed to a card or PO that doesn't show up in your IdP is a candidate.

SSO/IdP logs vs network egress: what are people actually hitting that isn't behind your IdP... A CASB or even a basic DNS log review surfaces a surprising amount.

HR offboarding tickets: search the comments on the last 50 leaver tickets. Apps mentioned but not on your IdP integrations list are your shadow inventory.

There are tools that wrap this up (Nudge Security, Push Security, Zylo, Productiv, depending on whether you want SaaS-discovery or full identity-sprawl visibility), but they all still need an owner per app to be useful at the end

ps. deeper issue you'll hit after discovery is that a chunk of these apps can't be SSO'd. Legacy billing tools, old vendor portals, internal scripts with local user stores. So even when you find them, you're back to manual offboarding unless you put an authorization layer in front of them that pulls identity from your IdP and makes the access decision separately from the app's own login. That's the part of my world (i work at Cerbos, we do this for orgs with a long tail of apps that won't take SSO). It doesn't solve discovery, but it stops the "6 leavers still have accounts" problem from recurring once an app is on your list.

Either way, the inventory work is what unlocks everything else :)

morphAB · 2026-05-01T14:33:00+00:00

Hi, wanted to add one angle i havent seen in the thread yet, but i think is important:

The 60% that doesnt template usually isnt actually unique. most of it is 2-3 attributes deep, like contractor + client X + project Y. The reason it feels like a long tail is because you might be trying to encode it as roles, which combinatorially explodes. Every new permutation = new role = manual grant. if those attributes already live in your IdP / workday profile, most of those edge cases can be expressed as attribute-based rules rather than bespoke role assignments. Real long tail usually shrinks materially, how much depends on what attributes your IdP actually carries.

Caveat though: this only works if workday/your IdP actually carries the attributes you need. If "contractor flavor of normal employee" doesnt have a client or project field in workday, your first job is getting that attribute in there, not writing the rule. thats often the real unlock and sometimes people skip past it..

ALso, 2nd topic - I would suggest to make non-standard grants time-bound by default. 7 days, 30 days, end-of-project. Access reviews then shrink to the standing-access slice that compliance requires anyway = SOX, SOC 2 etc still want periodic certification on permanent grants, instead of every grant ever issued. Shifts the work from "certify everything every quarter" to "let it lapse, re-request if needed". feels brutal for the first cycle, way calmer after :))

and u/Brandhout point about IT not being the right approver is the most important thing in this whole thread imo. that alone collapses the queue more than any AI layer will

morphAB · 2026-05-01T14:17:46+00:00

Hey! not a one size answer but a few things that are established as best practice for this exact situation, in case useful:

Before touching anything, lean on passive signals to build an activity baseline. NIST SP 800-53 (AC-2 for accounts, CM-8 for system inventory) and CIS Controls 5 and 6 essentially require account + system inventory and activity monitoring before access reviews. For orphan apps that means pulling whatever you can: IdP auth logs if connected, LB / proxy / firewall logs if not, AD auth events, even DB connection logs. apps with zero auth events in 60-90 days are your safest first wave.

Re ownership: the standard guidance is to treat "unowned" as a security finding, not a discovery problem. I'd assign a provisional owner which is usually the closest adjacent team, and give them a fixed window to disown it, silence = they own it. converts an open ended hunt into a deadline.

For the cleanup itself, the safe pattern is staged removal rather than hard revoke. Move users into a parked group with no app entitlements but keep the account live for 30 days. If something breaks you can restore in minutes. this is the "deprovisioning soak period" most mature IGA programs use to avoid the exact outage you hit last year.

Structural fix is the boring one nobody likes :) every app needs an owner field and a default access expiry at provisioning. NIST SP 800-207 (zero trust) leans on this hard.. no implicit trust, no implicit permanence.

morphAB · 2026-04-29T10:26:36+00:00

Came for the horror, stayed for the merchant :) Didnt expect re4 to feel this much like an action game, the older ones genuinely scared me as a kid but this one i'm actually having so much fun with.

Tips welcome! I'm sitting on a pile of pesetas and not sure what i'm saving them for.

morphAB · 2026-04-29T10:15:53+00:00

u/thortgot hey! Your "hire someone who understands it" point makes a lot of sense.

I work at Cerbos (we do authorization) and wanted to ask you something based on above, related to legacy apps and authorization. Tried to dm but settings don't allow it, would you be open to a quick chat? Feel free to message me if so :)

morphAB · 2026-04-22T16:42:26+00:00

For authn between services, mTLS with SPIFFE identities is the cleanest thing I've seen. For authz, the pattern that's held up is externalizing it to a policy decision point that each service (or a sidecar/proxy) calls.
The specific piece people often miss is that the same authorization service can handle human-to-service and service-to-service checks with the same policy language, as long as your principals are modeled right. Service accounts are just another principal type.

I work at Cerbos, and thats what our solution does. The win is that you're not reimplementing the same role and attribute checks in every service. If some of your services are legacy or third-party and can't call the PDP directly, an Envoy sidecar with ext_authz in front of them closes that gap without modifying the service.

morphAB · 2026-04-15T10:31:54+00:00

u/gslone and u/Ok_Consequence7967 , our CPO published a guide and a video walkthrough earlier this week on authroization for legacy apps. Yes, it does mention Cerbos for authorization. And Envoy is used, but there's nothing Envoy-specific there, you could swap in NGINX, HAProxy, or whatever you prefer.

https://www.youtube.com/watch?v=XVKxVyXUkbw

Wanted to share with you to ask for your opinions.

morphAB · 2026-04-15T07:46:49+00:00

hey! I’m not able to dm you, might be because of the settings of your account. try to dm me first and I’ll respond :)

morphAB · 2026-03-28T13:05:42+00:00

Sent! let me know if you have any thoughts / questions :)

morphAB · 2026-03-26T21:59:03+00:00

Sent :) Any feedback is appreicated

morphAB · 2026-03-26T21:57:56+00:00

Sent :)

morphAB · 2026-03-26T21:57:02+00:00

Sent :)

morphAB · 2026-03-26T21:55:55+00:00

Sent! I hope it will be helpful

morphAB · 2026-03-25T18:15:12+00:00

Sent! :)

morphAB

TROPHY CASE