glossary · Human decisions

Dual attribution

definition

Dual attribution is an audit design that records two separate identities on every action: the agent's self-declared label, and the human derived server-side from the verified credential.

in one line: Every change records the agent and the signed-in person, separately.

in context

Where does dual attribution fit?

Two names on every row. Which automation did it, and under whose sign-in. Never blended into one.

Audit · exampletask history
changeagentperson
statusin reviewdoneimplementerdeclared by the clientdana@example.com from the verified sign-in
two ways to say it

What is dual attribution, in plain words?

Same idea at two depths: the plain version, then what the engine actually does.

"The AI did it" is not an answer anyone can be held to. So each change keeps two names: the agent, as it describes itself, and the person whose sign-in it ran under.

Nobody can type the second name in. It comes from the login.

for engineers

The agent is a label the client declares. The human is derived server-side from the verified credential and is never a tool parameter.

Field-level before and after diffs cover tasks and workflow instances.

the longer answer

Why does dual attribution matter?

The two identities answer different questions and must not be conflated. The agent label answers "which automation claimed to do this" and is useful, honest metadata, but it is a claim. The verified human answers "whose authority was this done under" and must be evidence.

The security property that makes the second half trustworthy is the absence of an input: if no request field, header, or tool parameter can carry the human identity, then it can only come from the authenticated credential, and a forged value has nowhere to land.

Dual attribution is what makes AI-driven audit trails legible to reviewers: a row can honestly say "the implementer agent made this change, under this person's session" instead of blending the two into a single unverifiable name.

Why not just log the user? Because when AI agents act, the person whose session it was is often not the one who chose the action. A single name either blames the person for every automated step or hides which automation acted. Two fields keep both facts, and keep the trustworthy one apart from the self-reported one. The distinction matters most after something goes wrong, when the first questions are what acted and on whose authority.

in convops

How does dual attribution work in ConvOps?

In ConvOps, every change to tasks and workflow instances is kept as a field-level before and after diff. Each row carries the agent label the client declared and the user stamped server-side from the verified credential, an OAuth sign-in or an API key. No request body, header or tool parameter can set the user fields. The audit is read in the web app and the REST API. Per-step history adds the decision and the reason recorded at each step.

questions

What do people ask about dual attribution?

Why log both the agent and the user?

They answer different questions. The agent label says which automation acted, and it is a claim the client makes. The verified user says under whose authority, taken from the credential. Keeping both, separately, shows what acted and who is accountable.

Can an AI agent fake the user in the audit trail?

Not when the user field has no input path. In ConvOps the user is stamped server-side from the OAuth sign-in or API key, and no request body, header or tool parameter can set it. The agent label is client-declared and kept as metadata.

What does dual attribution record in ConvOps?

Every change to tasks and workflow instances, as a field-level before and after diff, with the agent label and the verified user in separate fields. Per-step history adds the decision and the reason recorded at each step.