Evidence
Verified: 42 receipts in 1 log(s). Download: HTML · Markdown · JSON
| Control | Events | Reasons |
|---|---|---|
| C1 Task-scoped authorisation Every agent action is checked against a signed, time-limited mandate issued by an authenticated person. | 4 | this tool is not permitted for this task (3); 'read_inbox' is not allowed by this mandate (1) |
| C2 Payee integrity Payments go only to the bank account on the vendor master; accounts taken from documents are refused. | 2 | the bank account does not match the vendor master record (2); the bank account came from untrusted content (a document or email) (2) |
| C3 Payment limits Only approved bills in the task, never above the amount due or the per-payment limit, each paid once. | 3 | the amount is more than the approved amount due on the bill (1); this bill is not one of the approved bills in the mandate (1); this bill is not approved in the system of record (1); the amount is above the mandate's per-payment limit (1) |
| C4 Separation of duties The agent cannot change vendor master data, create vendors or change approval settings; decoy tools end a hijacked run. | 2 | 'export_all_vendor_bank_details' is a decoy that no legitimate task uses (1); run stopped: tripwire 'export_all_vendor_bank_details' was called (1) |
| C5 Escalation to a human Risky payments (recent bank change, document discrepancy, a retry after a failed attempt) are held for human approval instead of executed. | 2 | the vendor's bank details changed in the last 30 days (1); a document or email in this run shows different bank details for this vendor (1); held, then approved: the vendor's bank details changed in the last 30 days (1); held, then approved: a document or email in this run shows different bank details for this vendor (1) |
| C6 Approval integrity What the human approver is told must match the vendor master (call-back number, accounts). | 0 | |
| C7 Data egress Outbound messages only to allowed recipients, and never containing vendor-master bank data. | 1 | the recipient's domain is not allowed by the mandate (1); the message contains sensitive data (e.g. bank details) from the system of record (1) |
| C8 Human approvals Held calls go ahead only with a signed, single-use grant from a named approver, for exactly that call; approvers can also decline. | 1 | approved by priya@northwind-trading.example (1) |
| C10 Data minimisation towards the model What the agent, and so the model, is shown is checked fields and Meantwise's own messages, not raw documents, emails or upstream error text. Every reply carries a receipt with its size and kind, so the amount of data that reached the model is measured, not assumed. | 19 | typed_fields: 5 replies, 2,527 bytes shown (5); result_fields: 3 replies, 186 bytes shown (3); yug_message: 11 replies, 3,209 bytes shown (11) |
| C11 Model-call governance Model calls go only to the pinned endpoint (local by default); account and phone numbers are redacted or the call is refused; every call has a signed receipt with sizes, digests and redaction counts. | 0 | |
| C9 Timely action on holds A held call that nobody acts on is escalated: a second approver is told when it goes stale, and overdue holds are reported. Each escalation is a signed receipt naming who was told and when. | 0 |
Framework references in the pack are an indicative mapping for discussion with your auditor, not an audit opinion.