An AI agent that can request identity verification raises a sharper version of a question every consent architecture has to answer: who actually approves it? Get this wrong and an agent that was only supposed to orchestrate ends up making a decision that was never its to make.
Here's the boundary we built, and why it holds regardless of what asked for the verification in the first place.
The agent creates the request. It cannot approve it.
Over MCP, an agent can create a consent-gated verification request the same way a human operator would — but from that point on, the agent is out of the loop. The holder receives the request on their own device, sees who is asking and why, and approves or declines it themselves. There is no code path by which an agent call turns into an approved grant; the human step is not a formality sitting next to the automation, it's the only thing that can actually authorise it.
What the agent sees back is your organisation's own setting
Once a grant exists, what an agent can read from it is controlled by your organisation, not by the agent and not widened by the fact that a machine asked. The default is status-only: the agent sees a grant's lifecycle state and a deep link back to the platform — active, expired, revoked — and nothing about the holder's identity. If your organisation has explicitly opted in to a lighter disclosure mode, an agent can also see the specific fields the holder already chose to share when they consented — never more, and never fields outside that original consent.
Why this is a customer-set choice, not a platform default
We deliberately didn't pick one disclosure mode and ship it as the only option. A back-office reconciliation agent may only ever need to know a grant is active; a support-workflow agent handling an already-consented case may legitimately need the fields the holder shared. Rather than guess which one your organisation needs, the setting lives in your own consent configuration — you turn it on if and when it fits your workflow, and status-only remains the default until you do.
The same boundary, whoever's asking
This isn't a special rule for AI agents layered on top of the platform — it's the same consent model every credential-sharing flow on AssureLocker already runs on, extended to a new caller. A human operator, a REST integration and an MCP-connected agent all hit the identical consent gate. The holder's device is where "yes" gets decided, every time.
Honest status
Consent-gated verification requests and both disclosure modes are live today. What we haven't claimed: that this makes an agent an autonomous verifier, or that any disclosure mode changes what a holder originally agreed to share — it never does.
Walk through the flow yourself in the guided MCP simulation, or read the full model on the developer overview.