the audit trail level nobody names but every AI product needs eventually
most audit trails answer 'did this action happen.' the ones that hold up under legal scrutiny answer something harder: 'would the reviewer who signed it still say yes if you asked them today.'
ive been calling this consent-of-record. not just reviewer id, but reviewer knew X at time of sign-off and stands behind it now. it sits above the usual forensic level (timestamp, user, action, immutable hash chain). that layer proves it happened. it doesnt prove the human is still endorsing it.
the pre-commit version of the same primitive: 'reach x signed-off-by.' if an agent action's blast radius exceeds a threshold AND no named human attached a signature in the last N seconds, pause. same primitive, different direction.
curious what other teams are doing.
1. for agent actions on customer data, do you require named human sign-off or rely on reversibility?
2. for compliance-heavy AI products, what does the reviewer artifact actually look like beyond 'ID + timestamp'?
3. anyone been asked for something beyond consent-of-record?
trying to name the shape of what enterprise buyers ask for that the industry hasnt named yet.
Replies
I think there's a layer beyond consent-of-record: decision-of-record. It's not just who approved an agent action, but what the AI proposed, what risks and policies were evaluated, what context the reviewer saw, and whether those conditions were still valid when the action executed. As a founder I believe enterprise AI governance requires continuous validation, not just proof that a human clicked "Approve," but deterministic evidence that the decision remained compliant at execution time.
@valosecurityai decision-of-record is the right expansion. consent-of-record answers 'who is on the hook.' decision-of-record answers 'was the decision well-formed at the moment it was made.' the two compose. consent without decision context means the reviewer signed under conditions you cant reconstruct. decision without consent means you can replay the situation but nobody agreed to be answerable for it. the useful atomic unit is probably a bundle: what was proposed, what the reviewer saw, what they knew about the policy state at the time, and their signature attached. that bundle is the trail that survives three years later when someone asks why.
Prefactor
Every agent should have an unique identifier, a human owner, timestamp and within Prefactor, we define an agent contract. Eg, what the agent is able to do, what the risk profile and quality profile of that agent is. Ultimately our contract says - What should an agent be doing in prod, and this is the way to measure it.
@matt_doughty the agent-contract framing is doing important work. its the ex ante scope: what can this agent do at all. consent-of-record is the runtime layer above it: who signed the specific instance that fell within the contract. contracts are policy. consent is instance-level accountability. both matter and they compose.
curious about prefactor specifically: when the agent operates within contract but produces an outcome the customer disputes, who becomes the human owner of record? the agent-owner from the contract, the person who approved the deployment, or the person who most recently touched the risk-profile? the contract answers 'was this allowed' cleanly. the 'who is answerable now' question is where teams i've talked to keep tripping.
Prefactor
@thenameisarian Ultimately, the owner of the agent is its parent/ engineer. If a piece of software broke because of bad engineering, the engineer would be responsible. There is no difference here.
What Prefactor does is allow you to define what good looks like, what bad looks like, and then catch drift when either of those outcomes are not lined up.
The idea of an agent not having an owner because its non-deterministic, is a get-out-of-jail free card for anyone who has built those agents. The person who added LLM into the agent workflow is responsible for adding the flow. You might not be able to engineer out every possible edge case, but you have nowhere to hide if you dont have a way to track it
@matt_doughty agree on the engineer as owner default. thats the right frame when the agent is a shipped artifact and the engineer chose the guardrails. where it splits is when the deployment includes a runtime reviewer (bank compliance analyst, healthcare doc reviewer, agency creative director). now the engineer owns 'was the agent capable of this class of failure' and the reviewer owns 'did i sign off on this specific instance.' two owners, different failure modes. thats not a get out of jail free, its specifying which human is answerable for which layer. the drift catching prefactor does sits on the engineer layer. consent of record sits on the reviewer layer. both need to exist, and if you collapse them into 'the engineer owns everything' you lose the ability to prove the reviewer paid attention on any specific transaction.
Prefactor