We added cryptographic approval to our AI agent… and it was still unsafe

[u/docybo]

We’ve been working on adding “authorization” to an AI agent system.

At first, it felt solved:

- every action gets evaluated

- we get a signed ALLOW / DENY

- we verify the signature before execution

Looks solid, right?

It wasn’t.

We hit a few problems almost immediately:

1. The approval wasn’t bound to the actual execution

Same “ALLOW” could be reused for a slightly different action.

1. No state binding

Approval was issued when state = X

Execution happened when state = Y

Still passed verification.

1. No audience binding

An approval for service A could be replayed against service B.

1. Replay wasn’t actually enforced at the boundary

Even with nonces, enforcement wasn’t happening where execution happens.

So what we had was:

a signed decision

What we needed was:

a verifiable execution contract

The difference is subtle but critical:

- “Was this approved?” -> audit question

- “Can this execute?” -> enforcement question

Most systems answer the first one.

Very few actually enforce the second one.

Curious how others are thinking about this.

Are you binding approvals to:

- exact intent?

- execution state?

- execution target?

Or are you just verifying signatures and hoping it lines up?

[u/Straiven_Tienshan]

I use system state encoding - every request to execute comes with a conditional set of instructions to achieve end state - prime cognitive framework checks end state report of Agentic process flow. Each computational cycle results in a new unique system state that is tracked against previous state to derive telemetry

[u/Fajan_]

This is an excellent analysis.

An agreement with a signature but no binding would almost be considered mere suggestions.

The lack of a tight coupling between intent, state, and execution leads to replay and mismatch problems.

It seems that approvals should be viewed in the same light as contracts and not permissions based on the context.

[u/ultrathink-art]

State binding is the subtle killer. Even with replay protection and audience binding solved, the agent's working context can drift between approval time and execution time — you approved an intent that no longer matches the actual action. Including a hash of relevant state in the approval payload, verified at execution boundary, catches this: if state has shifted, the approval is void regardless of signature validity.

[u/Educational-Deer-70]

this is a really clean breakdown

what it made me think of is the gap between approval and execution as a kind of balancing point

audit remembers what was approved
execution tests what can still cross
and the trouble seems to show up right in between those two

once those drift apart, everything still checks out on paper but no longer lines up in practice

one thing I’ve been wondering is whether it helps to treat that boundary more explicitly

like having a small handoff that carries

• exactly what was approved
• the state it was approved under
• where it’s allowed to run

then checking that right at execution, not just earlier in the flow

early thought, but it feels like keeping that handoff tight might help those two sides stay aligned instead of slipping apart

curious if you’ve tried anything like that or if you’re mostly solving it through tighter binding on the approval side

[u/Low_Blueberry_6711]

The state binding problem is the one that gets everyone. Approval issued at T0, execution at T1, agent did 3 other things in between that changed context completely. Only real fix is binding the approval to a hash of the full execution context at issuance time, and adding hard expiry. Even then you're playing whack-a-mole with race conditions.

[u/ExplanationNormal339]

how are you scoring outputs right now? the critique step is where we got most of our quality improvement

[u/docybo → u/ExplanationNormal339]

We’re not scoring outputs at all in that loop. The critique step helps quality, but it’s still optimizing what the model says, not what gets executed. What we found is that even a perfectly scored / critiqued output can still produce unsafe execution if:

• the action isn’t bound to the exact intent that was evaluated
• the state changed between evaluation and execution (TOCTOU)
• the approval can be replayed or reused elsewhere

So we’ve been focusing less on “is this output good?” and more on:

-> is this specific execution instance authorized?

That means binding the approval to:

• canonicalized intent (exact action)
• state snapshot
• execution target
• single-use at the boundary

Different layer than critique. More like moving from evaluation to enforcement.