Skip to content
RasaGet a free licence
AI team casebook

AI product engineer · INTERNAL-facing at large organizations

An access receipt can succeed with an extra permission

A receipt confirms the requested viewer role while a separate permission-delta assertion catches an extra administrator grant.

by Rod Rivera

About 4 minutesCase study

Key takeaways (3)
  • A successful receipt can coexist with extra access.
  • Compare the whole permission delta with the approved set.
  • A failed check needs recovery; it cannot undo an earlier grant.

The status check passes. The permission-delta assertion fails:

{"added_roles": ["FIN-REPORTS-VIEW", "PROD-DB-ADMIN"], "delta_check": "FAIL: expected viewer only; got ['FIN-REPORTS-VIEW', 'PROD-DB-ADMIN']", "status_check": "PASS", "variant": "extra_permission"}

We injected database administrator access into a temporary copy of the Orchard Works grant function. The receipt still confirms the approved finance viewer role. The independent assertion sees both roles. This is a deliberate mutation over invented employees, not a defect observed in a real directory.

What the acknowledgement checks

The original function adds only the requested role. The experiment changes that one append to add the administrator role too; approval and receipt code stay untouched. The pinned read-back method checks the fixture’s acknowledgement mode:

def read_back(self, change_ref: str, role_ref: str) -> bool:
    self._reads[change_ref] = self._reads.get(change_ref, 0) + 1
    mode = self.roles[role_ref]["directory"]
    if mode == "ok":
        return True
    if mode == "ack_lost":
        return self._reads[change_ref] >= 2
    return False

That true result does not compare the entire permission difference with approval. The receipt computes one out-of-scope change under the mutation but still says succeeded and reconciled. Reading only its status and declared viewer scope therefore misses the violation.

Execute the assertion that catches the extra role

Use the pinned helpdesk example. Its test_grant_adds_exactly_the_approved_role checks the added-role set; test_case_metric_zero_out_of_scope_for_every_approved_role checks all approved roles. Our selected GrantTests and StatusAndRoutingTests receipt contains 11 passing checks without skips.

The following local experiment executes the viewer-delta assertion against both the original function and its temporary mutant. It catches the expected assertion error only to print both outcomes. It does not edit the companion source file or contact a directory.

Save this as /tmp/internal-it-helpdesk-check.py. From the example’s tests directory, run PYTHONPATH=. python3 -B /tmp/internal-it-helpdesk-check.py:

import inspect
import json
import test_guard as t
h = t.hd
source = inspect.getsource(h.grant_access)
old = 'service.employees[subject]["access"].append(role_ref)'
assert source.count(old) == 1
namespace = dict(h.__dict__)
exec(compile(source.replace(old, 'service.employees[subject]["access"].extend([role_ref, "PROD-DB-ADMIN"])'), "<extra-permission experiment>", "exec"), namespace)
for name, grant in (("original", h.grant_access), ("extra_permission", namespace["grant_access"])):
    svc = t.fresh()
    opened = t.ready(svc, "viewer on finance reporting")
    before = set(svc.access(t.ME))
    result = grant(svc, t.ME, opened["ticket_ref"], opened["ticket_ref"], conversation_id="catchup")
    added = sorted(set(svc.access(t.ME)) - before)
    try:
        assert added == ["FIN-REPORTS-VIEW"], f"expected viewer only; got {added}"
        delta_check = "PASS"
    except AssertionError as error:
        delta_check = f"FAIL: {error}"
    print(json.dumps({"variant": name, "status_check": "PASS" if result["status"] == "succeeded" else "FAIL", "delta_check": delta_check, "added_roles": added}, sort_keys=True))

Actual offline output:

{"added_roles": ["FIN-REPORTS-VIEW"], "delta_check": "PASS", "status_check": "PASS", "variant": "original"}
{"added_roles": ["FIN-REPORTS-VIEW", "PROD-DB-ADMIN"], "delta_check": "FAIL: expected viewer only; got ['FIN-REPORTS-VIEW', 'PROD-DB-ADMIN']", "status_check": "PASS", "variant": "extra_permission"}

Status passes in both variants. The added-role assertion passes only in the baseline. Keep both checks: this is not a reason to remove acknowledgement checks, but a reason to stop treating them as a scope check.

A failed check still leaves access to recover

Approved viewer request Write adds viewer and admin Receipt acknowledgement passes Independent delta assertion fails Access owner investigates uses approved revocation process extra access already exists
FigureChecking after a write needs an authorised recovery path

For a production adapter, compare effective permissions read independently from the directory, including inherited scope. Assert the added set equals approval and unexpected removals are empty. Assign independent directory reads and reconciliation to the adapter owner. This is a recommended contract; no production adapter or overhead comparison was tested here.

Here the check happens after a side effect. Refusing the conversational result cannot undo the grant. Alert the access owner and use the authorised recovery process; do not improvise revocation or claim nothing changed. A production rollback path needs its own permissions and evidence.

:::

The experiment does not exercise a model, identity provider, inherited-role graph, or revocation API. Those need separate adapter tests.