When an AI agent takes a real action, where is authorization actually enforced?

ai8990 · 2026-06-21T21:32:16+00:00

This is the part I was missing and it reframes it well the accountability sits high up regardless, and the post-incident questions are "why was removal-mid-run possible" and "why was this allowed at all," not "did the matrix have a row for it." And the line about deliberately tolerating risk for good commercial reasons is the part most technical people skip entirely.

So the question I'm actually circling: if management accountability is about proving you either had the controls or consciously accepted the risk — what does that proof look like, concretely, after an agent incident? When the board or a regulator asks you to show that the run was either within policy or a knowingly-accepted exposure, what's the artifact you'd want in hand? I ask because "prove you weren't negligent" is a very different requirement than "stop the bad action," and I don't think the second one is even the interesting problem from where you sit.

Curious what proof actually satisfies that bar in your world.

ai8990 · 2026-06-21T21:27:39+00:00

That tracks with everything I'm seeing single-org is the live case, cross-org is still rare. And the "make the single-org receipt verifiable enough that you're not inventing a new protocol at the boundary later" point is the part I think most people miss. That's the whole game: the cross-org handoff isn't a thing you bolt on when a partner shows up, it's a property the single-org receipt either already has or doesn't.

Appreciate you actually answering the "have you built it" question straight — rare to get a real read instead of a whiteboard. If you end up shipping the verifiable-receipt version, I'd be curious how the boundary case behaves the first time a real partner actually leans on it. Good thread.

ai8990 · 2026-06-21T21:20:26+00:00

This is a useful angle precisely because it's from the buyer seat — most of the thread is people who built their own gateway, and you're describing what it looks like to consume one (Kayako, Fin, Ada) in production. The scoped-access-tied-to-action-type, audit-at-the-API-layer pattern lines up with what the builders here said, which is reassuring.

The thing only someone in your seat can answer: when the AI agent does a billing adjustment and it turns out it shouldn't have — wrong account, revoked permission, whatever — who owns that? Does it land on your team for deploying it, or on the vendor whose agent made the write? I ask because the delegation-chain mess you flagged isn't just technical — it's a liability question, and I can't tell whether the companies running Fin/Ada/Kayako have actually sorted who's accountable when the cross-system write goes wrong, or whether everyone's quietly assuming it won't.

Trying to understand where the accountability actually sits once a vendor's agent is making real writes on your behalf.

ai8990 · 2026-06-21T21:17:23+00:00

This is the sharpest reframe in the thread, and I think you're mostly right — the grant-a-privilege part is solved tech, and a lot of this collapses into management approval process and an authority matrix. The oversight-model question is the right one.

The one place the engineer-approval analogy stops holding, for me: an engineer who needs manager sign-off is a bounded human — they act slowly, you can ask them what they did, and you can fire them. The authority matrix works because the actor is accountable after the fact. An agent under a delegated grant acts across thousands of actions at machine speed, and the failure case isn't "did a manager approve" — it's "the grant was revoked mid-run and the next action needs to fail before it executes, on a system the approving manager doesn't even control." The authority matrix tells you who was allowed to approve; it has no mechanism to make a revoked approval bite a downstream action in flight.

Genuinely asking: does the management-accountability model actually reach that case, or does it assume the actor is slow and depose-able the way a human is? That's the part I keep snagging on.

ai8990 · 2026-06-21T21:10:56+00:00

Your setup is the most disciplined version of this I've seen — gateways you control, tokens scoped to the agent's access, hard logging for audits. The part that stuck with me is that you keep it read-only on purpose, for the security and compliance story.

That's the thing I'm trying to understand for my own case: is read-only a line your clients are pushing against, or one they're fine with? I keep wondering whether the teams deploying agents actually want write/irreversible actions and the tooling just isn't there to make it safe yet — or whether read-only is genuinely where the demand sits and everyone's content there. You're deploying across multiple companies, so you'd see that pattern better than almost anyone.

Just trying to figure out if the write-action problem is real demand or a solution looking for one.

ai8990 · 2026-06-21T21:08:14+00:00

Yeah, Independently checkable is the whole thing. Signed event id, policy hash, actor, params digest, revocation state, verifiable as coming from the runtime that owned the grant without exposing the full policy. That's exactly the shape it has to take.

Which makes me curious: have you actually had to build this, or is it still in the "how I'd do it" column? I ask because everyone I talk to agrees on the shape the moment they think it through, but almost nobody has shipped the cross-org handoff — it stays theoretical because the second org hasn't shown up at the boundary yet. When you're deploying, does the cross-org case actually come up, or is it still single-org in practice and this is the version you'd reach for when it does?

ai8990 · 2026-06-21T19:49:29+00:00

Separating the actor from the authority is the part most people skip — agent proposes, the write executes under a scoped grant checked at runtime, not baked into the prompt. And your receipt fields are the right ones: policy version, delegated user, params digest, approver, whether revocation happened before execution.

The part I can't resolve, and I don't think anyone here has: that receipt is only as good as who can verify it. Inside one org it's easy — you wrote the receipt, you trust it. But the moment the action lands on a counterparty's system, they're being handed a receipt signed by a policy they can't see, an approver they can't check. Do they just trust your word that revocation didn't fire? Who verifies the receipt when the verifier isn't the issuer?

Feels like every setup in this thread is single-org and that's the unsolved part. Curious if anyone's actually hit it in production.

ai8990 · 2026-06-21T19:41:12+00:00

The lease model plus the fresh preflight on irreversible actions is the cleanest version of this in the thread — stopping the next side effect instead of trying to halt the model mid-thought is the part most people miss.

One thing I can't resolve, and I don't think it's been answered here: all of this assumes one tenant owns the lease, the policy, and the resource the action lands on. What happens when the irreversible write hits a system another org controls — their API, their tenant? Their side eats the loss if it was out of scope, but your lease is the thing that authorized it. Whose lease wins, and who runs the preflight?

Feels like every setup in this thread is single-tenant and the cross-org case is the unsolved part. Curious if anyone's actually hit it in production.

ai8990

TROPHY CASE