{"schemaVersion":"0.1","generatedAt":"2026-10-09T20:00:14.936Z","entry":{"knowledgeKey":"actor-identity","kind":"limitation","entityKey":"security-trust","locale":"en","primaryQuestion":"Does a Decision Receipt prove who took the action?","questionVariants":[{"question":"Does MeshQu verify the identity of the person who approved this?"},{"question":"Can I tell which AI agent acted?"},{"question":"What is bound about the actor?"},{"question":"Is the actor the approver?"}],"title":"What a receipt records about who acted","answer":"No. MeshQu records and cryptographically binds the actor identifier the calling application supplies. It does not check that identifier against an identity provider, and the record does not establish which model or agent implementation acted behind a credential. Binding an unverified claim is still worth doing, because it converts a mutable log line into something that cannot be edited after the outcome is known, but it is narrower than attribution.","explanation":"Two questions sit close together and have different answers. The authenticated API key identifies the calling system, and that identification is cryptographic. The actor field identifies the responsible party within that system, and that is a claim the calling system makes. MeshQu binds the claim so it cannot be altered afterwards, which is a real property, but binding is not authentication. Your application is responsible for ensuring the actor is accurate at the moment of the call, and your identity and permission controls remain necessary. A second boundary sits behind the first. The subject of a credential is a credential. The record does not say which model, version or agent implementation acted behind it, so a question about which system produced an output is not one the receipt answers. Describing what a receipt carries as attribution is the easiest way to overstate it.","applications":[{"value":"Answer an auditor who asks whether a receipt establishes the identity of the person named on it."},{"value":"Decide what your application must supply, and what it must continue to control, before a receipt is offered as evidence of responsibility."},{"value":"Separate the question of which system called from the question of who within that system was responsible."}],"limitations":[{"value":"Actor is the safe noun and approver is not. A receipt records who acted, not necessarily who approved."},{"value":"Actor attribution is optional. The documentation states that where decisions are fully automated and actor identity is not a compliance requirement, it need not be supplied."},{"value":"Storing names in the record has data-protection consequences MeshQu does not manage. The documentation advises against putting full names, email addresses or other personal data in the actor identifier."},{"value":"This entry does not quote the permitted values of the actor type field. The documentation states two different pairs on different pages, and the discrepancy is unresolved."},{"value":"Binding an actor identifier says nothing about whether the named party had authority to act. Authority is a separate question from identity."}],"nextStep":{"label":"Actor attribution guide","href":"https://docs.meshqu.com/guides/actor-attribution"},"claims":[{"claimKey":"binds-not-authenticates","statement":"MeshQu records and cryptographically binds whatever actor identifier the calling application supplies. It does not authenticate actor identities against an identity provider, and the calling application is responsible for the accuracy of the actor at call time.","qualification":"This is the compression the entry exists to prevent: binding an identifier is not verifying it."},{"claimKey":"only-actor-id-is-bound","statement":"Exactly one actor field is inside the proof. The actor identifier is included in the integrity hash, so altering it after the fact makes verification fail. The other actor fields are stored as audit-display metadata and are outside the cryptographic proof.","qualification":"This corrects an earlier reading in which no actor field was thought to be hashed. The binding is real; what it binds is a supplied identifier."},{"claimKey":"api-key-versus-actor","statement":"The authenticated API key and the actor field answer different questions. The key identifies the calling system and is cryptographically proven. The actor identifies the responsible party within that system and is a client-supplied claim resting on application trust.","qualification":"The two-layer split is the documentation's own, on the trust model page. Conflating the layers reads an authenticated fact onto an unauthenticated one."},{"claimKey":"narrower-than-attribution","statement":"A receipt evidences which actor the calling system claimed, bound so the claim cannot be altered afterwards. It does not evidence who or what actually acted. Binding an unverified claim is worth doing, and it is a narrower thing than attribution.","qualification":"The documentation names describing this as attribution the single easiest way to overstate a receipt."},{"claimKey":"not-which-model","statement":"The record does not establish which model or agent implementation acted. The subject of the credential is a credential, not a system implementation.","qualification":"The 17 July 2026 verified-claims register records the same absence at the schema level, stating that AI-actor identity bound into receipts is not yet true. The register has not been re-verified since that date."}],"statementKind":"product-description","availability":"not-applicable","evidenceStrength":"source-reported","publicSources":[{"title":"MeshQu docs - Actor attribution","url":"https://docs.meshqu.com/guides/actor-attribution","context":"Which actor fields are covered by the integrity hash, and the documentation owner's statement that MeshQu does not authenticate actor identities against an identity provider."},{"title":"MeshQu docs - Trust model","url":"https://docs.meshqu.com/security/trust-model","context":"The two-layer split between a client-supplied attestation and a cryptographically verified API-key identity."},{"title":"MeshQu docs - Responsible-AI evidence","url":"https://docs.meshqu.com/concepts/responsible-ai-evidence","context":"Why a bound but unverified actor claim is worth recording, and why calling it attribution overstates it."},{"title":"MeshQu docs - Receipt reference","url":"https://docs.meshqu.com/concepts/receipt-reference","context":"The statement that the subject of the record is a credential, not a model or agent implementation."}],"revision":"f4e133a6c20afa033f05ac8c88bd5de787cbc4386f5c0bf24394ec3a80d5c98b","updatedAt":"2026-09-11T13:39:16.530Z","canonicalUrl":null,"related":[{"key":"limits-of-verification","url":"https://www.meshqu.com/knowledge/limits-of-verification.json"},{"key":"decision-receipts","url":"https://www.meshqu.com/knowledge/decision-receipts.json"},{"key":"responsible-ai-evidence","url":"https://www.meshqu.com/knowledge/responsible-ai-evidence.json"}]}}