Apparitor: authorization executor for A2A (checks agent.invoke against your existing policy engine)

[jhawlwut]

There's a lot here on authenticating who an agent is, but less on whether an agent is allowed to make a given agent.invoke call. Different question.

So I built an executor that checks every agent.invoke before it runs. Subject is the authenticated peer, and it denies if the check fails or the policy service is down. You don't write new policy: it speaks AuthZEN, so it asks whatever you already run (OpenFGA, Cedar, OPA) and maps the answer to allow / block / send-to-human.

It's one of four enforcement points in apparitor and I'd appreciate your feedback and testing.

https://github.com/jhawlwut/apparitor

[chopmob-cloud]

This is the right question to be asking, and splitting "is this agent allowed to do this" from "who is this agent" is exactly the distinction most of the thread skips. Checking every agent.invoke against your existing PDP and failing closed when it is unreachable is the correct default.

One thing that composes cleanly on top, since you already hold the decision at the enforcement point: make each allow / block / human_review outcome a recomputable receipt, not just a log line. A short content-addressed reference, a hash over the canonical decision inputs (the authenticated subject, the target invoke, the policy version, and the verdict; canonicalised with RFC 8785 JCS then SHA-256), lets an auditor or counterparty re-derive and confirm after the fact that this decision was made, on that policy, for that call, without trusting the enforcer's logs or calling the PDP back. It turns the observability layer into evidence.

It sits beside apparitor rather than inside it: apparitor decides and enforces, the reference records the decision so it stays provable later. We publish that layer open under Apache-2.0 (the same construction for an allow and for a deny) if it is useful to test against. Nice work, and fail-closed by default is the right call.

[msaleme]

This is the right question to be asking, and splitting 'is this agent allowed to do this' from 'who is this agent' is exactly the distinction most threads skip. Checking every agent.invoke against your existing PDP and failing closed when it is unreachable is the correct default.

One thing that composes cleanly on top, since you already hold the decision at the enforcement point: make each allow / block / human_review outcome a recomputable receipt, not just a log line. A short content-addressed reference—a hash over the canonical decision inputs (the authenticated subject, the target invoke, the policy version, and the verdict; canonicalised with RFC 8785 JCS then SHA-256)—lets an auditor or counterparty re-derive and confirm after the fact that this decision was made, on that policy, for that call, without trusting the enforcer's logs or calling the PDP back. It turns the observability layer into evidence.

It sits beside apparitor rather than inside it: apparitor decides and enforces, the reference records the decision so it stays provable later. The harness tests forged approval headers (PRV-001), self-signed attestations (PRV-002), and modified descriptions with preserved signatures (PRV-005), and the pattern that consistently fails is 'the server logged it, so I trust it.' A recomputable receipt is the minimal repair.

[chopmob-cloud]

What we said, six days ago on this same thread: #1944 (comment)

[eriknewton]

Right split, identity is a different question from authorization, and Apparitor as the PDP for agent.invoke is the missing middle. The piece I'd add underneath it: a policy decision only holds if the agent can't route around it. Sanctuary is that enforcement point, a per-uid kernel egress wall enforcing a signed operator policy (clean allow/deny, proven to survive reboot), so a destination Apparitor denies stays unreachable even if the agent ignores the verdict. PDP decides, the kernel enforces, the agent can't opt out. Happy to sketch the Apparitor-deny to wall-rule handoff if that composition is useful.

[msaleme]

This is the right shape — decoupling the check from the policy engine so the verdict is one fail-closed allow/block/human-review on every invoke.

The natural companion is adversarial: does that verdict hold when the invoke is actively trying to slip past it? We maintain an open A2A + authorization test corpus that exercises the cases an executor like this has to survive — authority impersonation on handoff (MAG-002), unauthorized task access/cancel (A2A-004), task-state manipulation (A2A-006), HITL approval forgery (AUTHZ-003), and re-authorization when the agent's context changes mid-flow (AUTHZ-004). Least-privilege and "on behalf of" delegation are covered too (AUTHZ-001/002).

Might make a useful conformance target for Apparitor's allow/block decisions. Repo: https://github.com/msaleme/red-team-blue-team-agent-fabric

[eriknewton]

@msaleme That corpus is a good complement to Apparitor's PDP role, though worth separating two layers it would test. Most of those cases (MAG-002, A2A-004, AUTHZ-003/004) are identity and authority-decision checks, which is Apparitor's layer. The enforcement claim I made above is narrower: once a verdict lands, does the destination stay unreachable regardless of what the agent does next. That's a kernel-egress question, not an authorization-logic one, and what I can say for Sanctuary today is a clean per-uid allow/deny demo plus reboot survival, not a per-rule adversarial audit yet. Interested in whether the subset of your corpus that resolves to a concrete network destination maps onto that layer.

[msaleme]

Agreed on the split. In this corpus, MAG-002, A2A-004, and AUTHZ-003/004 are primarily authorization-logic cases. Only the smaller subset that resolves to a concrete network destination reaches kernel egress. Keeping those enforcement layers separate avoids implying that either one covers the whole corpus.

[eriknewton]

Agreed, and thanks for narrowing it. Keeping "did the agent have authority" and "was the destination reachable anyway" as separate claims is what keeps either layer honest about what it actually covers. Useful boundary to have on the record.