Short answer: Yes, if the approval was signed rather than logged. Where an app requires presence, AgentAdmit’s hosted consent page derives the passkey challenge from a cryptographic commitment to the exact grant on screen: the scopes, the duration, the app’s declared purpose, the user’s own intent words, and any call ceilings. The user’s passkey signs that commitment. The signed response, the authenticator’s public key, and the commitment preimage are all persisted and exported, so anyone holding the export can recompute the commitment and run standard WebAuthn verification without trusting AgentAdmit’s database.
Why isn’t a vendor’s consent log proof?
A log row that says “user approved read:workouts at 14:02” is a statement by the system about its own behavior. If you trust the operator, it is useful. If you are an auditor, a regulator, a customer’s security team, or the user in a dispute, it is exactly the thing you were asked to verify, restated. The operator could have written it, edited it, or written it late.
That problem gets sharper with AI agents. An agent that holds a token will act on it thousands of times. When one of those actions is questioned, the question is never “did the vendor record consent” but “did a person actually approve this grant, with these limits.” A log cannot answer the second question on its own. A signature can.
What does the passkey actually sign?
In an ordinary WebAuthn login, the server sends a random challenge and the authenticator signs it. The signature proves the user was present. It says nothing about what they were agreeing to.
AgentAdmit replaces the random challenge with a commitment. When the hosted consent page reaches the ceremony, the server freezes the grant selection into a canonical string: the app, the user, the scopes sorted, the duration, the declared purpose, the user’s intent in their own words, any call ceilings, the session id, and the time it was issued. The challenge is the SHA-256 hash of that string. The user confirms with Face ID, Touch ID, a device password, or a security key, and their passkey signs that hash.
The result is a signature over the decision itself. The server stores the signed response, the public key of the credential that signed it, and the preimage string, and copies the bundle onto the append-only consent trail as part of the presence event for that grant.
The binding is enforced. If the user changes scopes or duration after the ceremony, token generation refuses with a commitment mismatch and the page asks for a fresh ceremony. The evidence can only ever describe the grant that was issued.
How does someone verify it without trusting AgentAdmit?
Two checks, both standard, both offline.
- Recompute the commitment. Hash the stored preimage with SHA-256 and compare it to the challenge inside the signed clientDataJSON. A match means the ceremony signed a commitment to exactly these recorded grant parameters.
- Verify the signature. Run ordinary WebAuthn verification: the signature over the authenticator data and the hash of clientDataJSON, checked against the recorded public key. The authenticator flags inside the data show user presence and user verification.
Nothing in those two steps calls AgentAdmit. The bundle is available two ways: inside the consent export, and directly per connection at GET /api/v1/connections/{connection_id}/evidence with include_raw=true, under the app’s own live key. Test keys never read live evidence.
What are the three evidence tiers on a connection?
Not every connection has a signed commitment behind it, and the evidence endpoint says so rather than blurring the line. Each connection sits in exactly one tier.
- hosted_vce. A commitment-bound ceremony ran on the hosted page and the evidence bundle is persisted. Independently verifiable.
- presence_fact. A ceremony is recorded on the connection but no commitment evidence exists. This covers the legacy path, and it covers an app that ran its own passkey prompt and attested the fact at token issuance. The response labels who witnessed it, and it is labeled not independently verifiable. An app-attested fact never promotes to the hosted tier.
- none. The hosted service never witnessed a ceremony: a direct API token, a presence-off session, or an app-side prompt that was never attested.
An app can show these tiers to its users as they are. A connection that reads “no ceremony evidence” is the system being honest, not the system failing.
Are all passkeys equal?
No, and the evidence records the difference. An app chooses one of two assurance policies, and the policy is frozen into each session when it is staged.
Consumer accepts what people actually have: Face ID, Touch ID, a device password, or a passkey synced through iCloud or Google. Those credentials arrive without attestation, so the evidence records them as user-verified and unattested. One extra rule closes the obvious gap: a newly registered credential is never final evidence by itself. It must immediately sign an authentication assertion over the same persisted commitment before the grant can finalize, so registration alone never grants anything.
Trusted requires direct attestation from the authenticator, validated against the FIDO Metadata Service, with provenance rechecked on later assertions. An ordinary phone passkey does not qualify. It exists for the apps where the cost of a wrong approval justifies a hardware key.
The claim ceiling for the consumer tier, stated plainly: user-verified and signed over the exact commitment, not hardware-attested.
What does the evidence not prove?
It proves that a user-verified passkey ceremony signed a commitment to these recorded grant parameters. It does not prove what the user’s screen rendered, or that they read it. No cryptography can, and a vendor telling you otherwise is selling the log back to you with a signature on top.
It is also a review-time record, never an enforcement input. The live verification call that allows or refuses each agent request checks the grant, the scope, expiry, revocation, and the user’s ceilings. The evidence is what you reach for afterward, when someone asks whether the grant was real.
The trail it rides has its own honest ceiling. Every decision event carries a hash of its content and of the previous event, so an altered or deleted row breaks every fingerprint after it. That is tamper-evident, never tamper-proof. An operator rewriting and re-chaining history is caught by comparing two exports taken at different times, which is why the export exists on every plan.
Where is it running?
Commitment-bound evidence shipped on August 6, 2026 and the assurance tiers on August 28, 2026. TrainerTracer, the first production integration of AgentAdmit, runs its agent grants and its own consent-switch changes through hosted ceremonies, so its connections carry the hosted tier. We have run the offline verification ourselves on a real passkey ceremony, from export contents alone, using nothing but the two checks above.
FAQ: verifiable consent evidence for AI agents
Does the user’s biometric data leave their device?
No. Face ID and Touch ID stay on the device. The only thing recorded is the cryptographic signature and the public key of the credential, which is how every passkey login works.
Can the agent produce this evidence on the user’s behalf?
No. The ceremony runs on AgentAdmit’s hosted page with a user-verified passkey. An agent can carry the link to the user. It has no way to produce the signature.
What happens if the grant changes after the user signed?
Token generation refuses with a commitment mismatch and asks for a fresh ceremony. The evidence only ever describes the grant that was actually issued.
Is the evidence produced for every grant?
Only where the app requires or prefers presence on the hosted page. Direct API tokens and presence-off sessions produce no ceremony evidence, and the evidence endpoint reports them as such.
Is the consent trail tamper-proof?
No. It is tamper-evident. Each decision event carries a hash chain fingerprint, so alterations are detectable by anyone holding an export. The three checks are documented in the App Owner Guide and can be re-implemented from the export fields alone. The reference verifiers are public at github.com/PhoenixCo-Founder/agentadmit-verifiers.
Integration details are in the App Owner Guide and the MCP Server Operator Guide, the term is defined in the glossary, and the flow is identical with test keys at agentadmit.com.
Related reading: Can an AI agent’s grant carry the app’s declared purpose and the user’s own intent? | Can an AI agent be required to get human confirmation for one action? | Should an AI agent ever hold its own authority?