--- title: "Decision before or log after? Controlling agents" url: https://knowyouragent.ch/en/knowledge/comparison/decision-before-or-log-after lang: en updated: 2026-10-17 license: © Innopulse Consulting GmbH --- # Decision before or log after? Controlling agents The most common control for AI agents is the log: everything is recorded and analyzed when needed. That helps in investigation but prevents nothing. A decision before execution starts earlier. [Leutrim Miftaraj](https://knowyouragent.ch/en/about/leutrim-miftaraj), Founder, Innopulse Consulting GmbH Published 17 October 2026 ## Key points - A log afterwards shows what happened; a decision beforehand prevents what should not happen. - A log can be changed afterwards; a signed decision with a [receipt chain](https://knowyouragent.ch/en/knowledge/glossary/receipt-chain) cannot be changed unnoticed. - The reliable combination: decision before execution, signed receipt afterwards, both chained and timestamped. ## What this is about A log records which tools an agent called and which actions it carried out. It arises after the action and usually sits with the agent's operator. Whoever analyzes it detects mistakes and abuse, but only once the damage has occurred. A [decision](https://knowyouragent.ch/en/knowledge/glossary/decision-token) arises before the action: a decision service checks it against the mandate and allows or denies it. The decision is signed, and after execution a receipt records what actually happened. Receipts are chained in a [receipt chain](https://knowyouragent.ch/en/knowledge/glossary/receipt-chain). ## The comparison | Feature | Log afterwards | Decision before and receipt after | |---|---|---| | Timing | After the action | Before and after the action | | Effect | Investigation | Prevention and investigation | | Tamper protection | Depends on storage | Signature, chaining, timestamp | | Verifiable by third parties | Usually only with system access | With the public key | | Effort | Low | Decision service and gateway needed | | Statement | What happened | What was allowed and what happened | ## When to use what - **Log only** for read access and actions without significant consequences, where investigation afterwards is enough. - **Decision and receipt** for payments, orders, contract conclusions and changes to systems, where a mistake is expensive. - **Always in addition** an operational log for troubleshooting, which does not serve as proof of authority. ## How the two work together The decision says what was allowed; the receipt says what happened. If the two differ, that is a clear finding. If receipts are chained and the current hash is regularly secured with a [timestamp](https://knowyouragent.ch/en/knowledge/glossary/rfc-3161-timestamp), it can also be shown afterwards that nothing was deleted or altered. The operational log adds details for troubleshooting. ## Common misconceptions - **“A complete log is evidence.”** It shows what happened, not whether it was allowed. And without protection, it can be altered. - **“A decision beforehand slows everything down.”** A check against a mandate takes milliseconds; only exceptions go to people. - **“Only auditors need receipts.”** They also help in disputes with customers or partners who contest an action. ## The role of KYA KYA verifies decisions, receipts and receipt chains: whether execution matched the decision, whether the chain is complete and whether a timestamp secures it. KYA cannot verify a plain log, because it is neither signed nor bound to a mandate. More in the article [Proof for agent actions](https://knowyouragent.ch/en/knowledge/evidence-for-agent-actions). ## Decision guide in three questions - Can a mistake be expensive or hard to reverse? Then a decision before execution is needed. - Must third parties be able to verify the action later? Then signed receipts are needed instead of an internal log. - Must it be proven that nothing was deleted? Then chaining and timestamps are part of it. ## Frequently asked questions ### Is a log enough to control AI agents? For investigation afterwards, yes; for prevention, no. Actions with consequences should be checked against a mandate before execution. ### What is a decision before execution? A decision service's signed answer on whether a specific action lies within the mandate. Only then is it executed. ### Why is a log not reliable evidence? Because it usually sits with the operator, is not signed and can be altered afterwards. Signed, chained receipts with a timestamp cannot be changed unnoticed. ### What is a receipt chain? A sequence of receipts in which every entry contains the hash of its predecessor. A change or gap shows up during verification. ### Do I still need a log? Yes, for troubleshooting and operations. Proof of authority, however, comes from decision and receipt. ### How long must decisions and receipts be kept? As long as the underlying business records; the periods follow from the applicable law. Signed receipts remain verifiable for years if keys and anchors are kept. ### Can I secure existing logs afterwards? From a certain point, yes, by chaining new entries and timestamping them regularly. What happened before can no longer be proven afterwards. ### What does a decision service cost? Running a small service that evaluates rules and signs decisions. Compared with the possible damage from uncontrolled actions, the effort is small. ## Sources - NIST SP 800-207: Zero Trust Architecture: [https://csrc.nist.gov/pubs/sp/800/207/final](https://csrc.nist.gov/pubs/sp/800/207/final) - RFC 3161: Time-Stamp Protocol: [https://www.rfc-editor.org/rfc/rfc3161](https://www.rfc-editor.org/rfc/rfc3161) --- Quelle: https://knowyouragent.ch/en/knowledge/comparison/decision-before-or-log-after · KYA – Know Your Agent