Approval as steps in the task

[MKaptein]

Hi all, here is an idea I would like your view on.

ACS handles approvals of specific actions with ask. However many approvals happen without a Guardian asking: a coding agent shows a permission prompt, a LangGraph workflow stops at an interrupt(), etc. As far as I can see there is no hook for these, so a Guardian cannot see approvals handled by the harness (or require one before an action).

Would it make sense to add a hook the harness emits when it has run an approval or a check itself? Something like steps/gate, with a kind (human_approval or guardrail), a result (pass or fail), and the step it belongs to.

This would sit next to ask, not replace it. What the harness reports is only its own claim, and the Guardian decides how much that is worth.

It seems related to #175 and #115. Apologies if I have missed an existing thread on this.

Background on where this comes from is here.

[victorm-hernandez]

What scenarios are you envisioning here? Specifically, what kind of information can the guardian retrieve from these events that would influence the decision-making process? Could you walk us through an example?

[MKaptein]

Happy to provide an example! We have multiple of this shape that we are actually working on, but a simple one would be:

1. An agent reads a customer record from a CRM (that would be encoded in the tool call so the guardian knows).
2. (same agent, same run, all in memory): the agent wants to send an email to an address outside the company.
3. Before sending a message to the outside world the agent executes a "PII check"; this is simply a tool that implements -- through regex, ML, or otherwise -- some scoring of the content of the planned email with a verdict on whether or not it contains personally identifiable information.
4. Next, the agent executes the send-email tool.

A guardian policy could blanket enforce that any message sent to the outside world when CRM data is in context needs a PII check with a certain response prior to it.

Currently in ACS (if my understanding is correct), step 2 would be an ask coming back from the guardian. However, this at least implies the guardian knows about the possible "gates" (the PII check) available, and it makes the guardian not just judge the task as is, but intervene in the task in ways that might become complex.

The way we have implemented it today is that step 3 is simply logged by the harness (whose logging we trust) as "just another step in the task with its own properties". The "guardian" simply checks whether the PII "gate" was added to the trace (again, with the desired properties) before deciding an allow on the email tool call.

In ACS today the guardian would potentially see step 3 as a tool call with some name, but it would not know that it was a check / gate, nor what its verdict was, so any policy enforcing such behavior would have to be written very specifically for specific tools. In addition, a permission prompt shown by the harness is not a tool call at all, so the guardian does not see it (but its approval can just be added to the trace as a passed gate, akin to the "approval" by an ML based PII check).

I guess within ACS it would not be hard to facilitate both:

• We can have the current ask mechanism as is.
• We can add a simple hook (or required properties) to add a "gate" to a trace. This is a small addition but it would make very expressive policies possible.

Does that make sense?

Note this might relate to earlier #175 as well. And, obviously it relates to #232; adding a "gate" as one of the kinds of action discussed there would satisfy the above.

[Val1-IT]

I like this, and I think the PII example shows one thing the gate record needs to carry, or the policy becomes easy to satisfy by accident.

If the gate only says kind: guardrail, result: pass, step: <id>, the Guardian can check that a PII check passed somewhere earlier in the trace, but not that it passed on the email that is actually being sent. A pretty normal run looks like this: the agent drafts the email, the PII check passes, the model then "improves" the text and pastes in a line from the CRM record, and the send goes out. The trace still has a passing gate before the send.

So I'd suggest the gate names what it judged: something like a subject holding a digest of the payload (or of the tool name plus canonicalized arguments of the call it is meant to unlock). The Guardian then only counts a gate whose digest matches the toolCallRequest it is deciding on. The same goes for human_approval: a permission prompt the user accepted for one command shouldn't count for a different command that comes up later in the same session.

Two smaller things that fall out of this. It would help to record who produced the gate (a human, a service, or the agent itself), so a policy can say "a human approval from the agent doesn't count". And it may be worth saying whether a gate can be used once or many times. For sends and deletes, one gate per action seems like the safe default.

For context, I hit this while building LedgerGuard (https://github.com/Val1-IT/Arvanta-Ledgerguard), a small pre-1.0 approval layer for agent writes to Postgres and ERPs. There, an approval is tied to a plan id and version, and an agent actor can't approve. It's experimental and much narrower than ACS, so I'm only offering it as one data point. I'd be interested to hear whether binding the gate to a digest seems too strict for the harnesses you're working with.

[MKaptein]

Thanks @Val1-IT, I agree, and I do not think it is too strict. A check should judge the actual content of the call, in most cases right before the call is made. In the PII example that would mean the body of the email is checked after the last model call (when it was generated) and before the send, whatever the agent read earlier and from wherever.

So to me it seems indeed reasonable for a gate to name the content it judged. However, the gate itself would not know which tool call will follow; the LLM decides that. Thus, in my view, when the "send email" call comes in, the Guardian can see whether a gate that judged that same content is on record prior to it, and allow the call on that basis. The Guardian then uses the gate to approve where it would otherwise return an ask.

What a gate record should carry besides the content it judged still needs working out. I would expect a name for the check, its properties (the result, and perhaps how reliable the check is), and who is accountable for it (which I guess is the main difference between human approvals and ML / rule based approvals). I do not have a schema to propose yet, because there are still some loose ends in my mind. However, if the general direction works for the maintainers, I am happy to help work it out into a well-scoped issue.

Note: the Partnership on AI report on agent observability describes the same gap for human review (https://partnershiponai.org/resource/the-observability-gap-in-ai-agents/).

[Val1-IT]

agreed on checking the content right before the call. the "gate doesn't know which tool follows" point is the sticky bit.

one shape that has worked for me when the model picks the next tool: the gate records contentDigest (of the payload it judged) plus optional unlocks hints (e.g. tool name class like send_email), and the Guardian on the later call requires both (a) a matching content digest for the args actually being sent and (b) that the tool is in the unlocks set if one was declared. if the model edits the body after the gate, (a) fails. if it tries to reuse a PII-pass on a different tool, (b) fails.

on accountability: producer: human | service | agent plus a reliability/confidence field for ML gates seems enough to start. humans and services can clear an ask; agent-produced gates shouldn't.

if you open that scoped issue, happy to leave a note on the digest + unlocks split from the db-write side. no need to wait on me though.