Delegation Audit Log¶
Accountability record — instantiates Principal-Bound Authority Mediation
Records each mediated action as a paired entry — who caused it and who executed it, under which delegated scope — so review can separate the originating principal from the deputy that acted.
The failure this guards against is subtle: a log that records only the deputy. When a service account performs a sensitive action, an ordinary access log dutifully notes the service account — and loses forever the question that matters, which is who induced it. Delegation Audit Log is the after-the-fact record that refuses to collapse cause and execution into one actor. Every mediated action becomes a paired entry that preserves both ends of the delegation — the originating principal and the executing deputy — plus the scope, freshness, and policy decision that justified spending the deputy's authority. Its defining trait is that it is retrospective and evidentiary: it does not decide, challenge, or block anything; it makes the causal chain reviewable so that accountability survives the handoff.
Example¶
A commercial bank runs a back-office payments desk where clerks and an automated settlement service both hold authority to release wire transfers. One afternoon a $2.3M transfer to a new vendor clears, and a week later the vendor turns out to be fraudulent. The ordinary system log says only: settlement-service executed transfer W-88421 at 14:07. That is a dead end — it names the deputy and nothing else.
The delegation audit log tells the real story. Its entry for W-88421 carries a pair: caused-by is analyst m.reyes, who submitted the payment instruction; executed-by is the settlement service acting under her approved scope; and attached is the delegation context — the approver (a supervisor's release), the budget authority, the vendor record, the amount ceiling, and the freshness window the approval was still inside. Reviewers can now reconstruct exactly whose intent flowed through the deputy, which approval covered it, and where the control should have caught an unvetted vendor. The log did not prevent the loss, but it is what makes the investigation — and the fix — possible.
How it works¶
- Log the pair, never the deputy alone. Every entry binds the causing principal to the executing deputy in the same record; a log that can name only one has failed the archetype.
- Attach the justifying context. Alongside the pair goes the delegation evidence in force at execution — scope, approver, tenant, channel, freshness window, and the policy decision — so the record shows not just that it happened but under what authority.
- Preserve the provenance chain. Where the request crossed hops (queue, proxy, mesh), the log threads the causal trail so a later reviewer can follow the request from origination to execution rather than seeing only the final leg.
- Write it to be trusted later. Entries are append-only and time-anchored, because their whole value is being credible evidence weeks after the fact.
Tuning parameters¶
- Retention window — how long paired entries are kept. Longer supports slow-burn fraud investigations but widens privacy exposure of principal-and-purpose metadata.
- Context richness — how much delegation detail each entry carries. Fuller records reconstruct more but store more sensitive metadata and cost more to hold.
- Tamper resistance — plain append-only versus cryptographically chained or externally anchored entries. Stronger integrity makes the log admissible in dispute but adds operational weight.
- Sampling vs. completeness — logging every mediated action or only sensitive classes. Complete logs miss nothing; sampling controls volume at the risk of the un-logged action being the one you needed.
- Correlation depth — how many upstream hops the provenance chain stitches together. Deeper chains survive multi-service paths but depend on every hop propagating a correlation identifier.
When it helps, and when it misleads¶
Its strength is accountability that outlives the request: it is what lets a bank, a hospital, or a cloud tenant answer who caused this long after the deputy has moved on, and it turns "a broad service account did something" into "this principal induced this action under this approval." It is also the honest backstop that keeps a mediation design from quietly rotting — reviewing real paired entries surfaces boundaries where context was being stripped.[n1]
Its central limit is that it is evidence, not prevention. The archetype is explicit that a log which records a service account after execution is not enough on its own; the classic misuse is to treat a rich audit trail as a control and skip the request-time checks that would have refused the action in the first place. It also fails quietly when an upstream hop drops the originating principal — the log then faithfully records a deputy with no cause, preserving the very ambiguity it exists to remove. The guarding discipline is to pair it with request-time mediation and to periodically test that the caused-by field is actually populated end-to-end, not silently defaulting to the deputy.
How it implements the components¶
accountability_binding_record— its core artifact: the paired caused-by / executed-by entry that keeps principal and deputy distinguishable after the fact.request_provenance_trace— it threads the causal chain across hops so the origination-to-execution path is reconstructable, not just the final leg.delegation_context_record— each entry carries the scope, approver, freshness, and policy decision that justified the action, preserving the delegation evidence as of execution time.
It does not proactively attack the boundary or assert safe verdicts — constructing forged and fallback probes is Confused-Deputy Abuse-Case Test's abuse_case_probe_set and deny_or_step_up_default; this log is the passive historian, its twin the active attacker.
Related¶
- Instantiates: Principal-Bound Authority Mediation — supplies the reviewable record that separates who caused an action from who executed it.
- Consumes: Signed Delegation Token and On-Behalf-Of Authorization Flow — the delegation evidence they carry is what each entry captures as context.
- Sibling mechanisms: Confused-Deputy Abuse-Case Test · Policy-Engine Subject Binding Check · Signed Delegation Token · On-Behalf-Of Authorization Flow · CSRF Token Challenge · Origin and Referer Gate · Object-Capability Reference · Scoped Service-Account Impersonation
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Delegation Audit Log operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it records each mediated action as a paired entry — who caused it and who executed it, under which delegated scope — so review can separate the originating principal from the deputy that acted.
Independent corroboration: The frozen evidence defines Delegation Audit Log as 'Records each mediated action as a paired entry — who caused it and who executed it, under which delegated scope — so review can separate the originating principal from the deputy that acted', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Security Studies & Intelligence Analysis
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Security audit practice is primary because the log preserves accountable identity across mediated action: who initiated, which delegate executed, under what authority, and with what outcome. Software provenance supplies the principal-delegate representation, while accounting audit supplies the evidentiary lineage.
Related originating lineages:
- Accounting & Auditing — Audit practice supplied durable authorization evidence, traceability, and separation of initiating and executing roles.
- Computer Science & Software Engineering — Distributed systems and provenance models supplied explicit principal, delegate, activity, and causal-link representations.
Review resolution: Security audit practice is primary because the log preserves accountable identity across mediated action: who initiated, which delegate executed, under what authority, and with what outcome. Software provenance supplies the principal-delegate representation, while accounting audit supplies the evidentiary lineage.
Attribution caveat: The paired principal/deputy record synthesizes security event logging with formal provenance and audit evidence.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Non-repudiation — the property that an actor cannot later credibly deny having caused an action, because the record binds the action to them with enough integrity to stand up to challenge. A delegation audit log extends the idea to mediated action: it must make both the causer and the executor non-repudiable, not just the one that ran. ↩